du -k | sort -n | perl -ne 'if ( /^(\d+)\s+(.*$)/){$l=log($1+.1);$m=int($l/log(1024)); printf ("%6.1f\t%s\t%25s %s\n",($1/(2**(10*$m))),(("K","M","G","T","P")[$m]),"*"x (1.5*$l),$2);}'

выглядит безопасно ?

весь диск стирает или только кластер?

та вроде принты одни...

отображает иерархию по размерам из текущей дирректории

мне хватает du -h | sort -rh

du -k | sort -n | perl -ne 'if ( /^(\d+)\s+(.*$)/){$l=log($1+.1);$m=int($l/log(1024)); printf ("%6.1f\t%s\t%25s %s\n",($1/(2**(10*$m))),(("K","M","G","T","P")[$m]),"*"x (1.5*$l),$2);}'

"P" реально у кого-то есть или это до кучи?)

джаст ин кейс)

Всем доброго времени суток. Коллеги подскажите как правильно и в каком месте указывается отметка (безопасное распараллеливание - PARALLEL SAFE) у функции CREATE OR REPLACE FUNCTION "Engineering"."listBall"( OUT "ID" integer, OUT "firmName" character varying, OUT "modelName" character varying, OUT "firmNum" character varying, OUT "invNum" character varying, OUT "localNum" character varying, OUT "createDate" date, OUT "inDate" date, OUT "tsName" character varying, OUT weight numeric, OUT "workPressure" numeric, OUT "ispPressure" numeric, OUT capacity numeric, OUT "lastUpdate" timestamp with time zone) RETURNS SETOF record AS $BODY$ select sb.idball, sf."firmName", sm."modelName" as model, sb."firmNum", sb."invNum", sb."localNum", sb."createDate", sb."inDate", st."tsName", sb.weight, sb."workPressure", sb."ispPressure", sb.capacity, sb."lastUpdate" from "Engineering"."sprBalloon" as sb, "Engineering"."sprModel" as sm, "Engineering"."sprTechStat" as st, "Engineering"."sprFirm" as sf where sm.idmodel=sb.idmodel and st.idts=sb.idts and sf.idfirm=sm.idfirm; $BODY$ LANGUAGE sql VOLATILE COST 100 ROWS 1000; ALTER FUNCTION "Engineering"."listBall"() OWNER TO user;

в конце. Там же где косты

спс

Коллеги, а никто не пилил мастер-мастер на pglogical?

в этом чате уже много раз обсуждалось, что мастер-мастер на постгре - пока что не существующая штука

Да, спасибо

Ждём 10

двунаправленная репликация: http://plumqqz.livejournal.com/486621.html Курить до полного просветления.

ну да, ну да. "мультимастер — это шарлатанство". но это только до тех пор, пока в постгресе её нет. а как только она появится, это будет объявлено величайшей победой, самой долгожданной фичей релиза и вообще непонятно, как мы раньше жили

как с логической репликацией, например было. годами объясняли, что физическая репликация — наше всё. и вдруг пожалуйста, pglogical — самая долгожданная фича в 10-ке, оказывается

Мультимастер и BDR как говорят в Одессе 2 большие разницы

Мультимастер и BDR как говорят в Одессе 2 большие разницы

И что хужее - совершенно непраздный вопрос.

как с логической репликацией, например было. годами объясняли, что физическая репликация — наше всё. и вдруг пожалуйста, pglogical — самая долгожданная фича в 10-ке, оказывается

рукалиТСо.жЫпег. pglogical - это slony, засунутый в постгрес. Но если слоников теоретически есть возможность запустить по количеству баз, то pglogical обслуживает только одну базу. Страдайте.

рукалиТСо.жЫпег. pglogical - это slony, засунутый в постгрес. Но если слоников теоретически есть возможность запустить по количеству баз, то pglogical обслуживает только одну базу. Страдайте.

Бред

слони на тригерах

pglogical на других принципах

триггеры слоника пуляют запросы на ведомого из очереди, а вал_сендер в пглогике сначала вычитывает вал, затем преобразует его в запросы и уже эти запросы пуляет на ведомого. Если у кто-то считает себя бессмертным и может позволить себе заниматься ерундой, то потестируйте, где какой оверхед будет. Это вот как оно внутри.

Ну и производительность заодно. Особенно на транзакциях, обрабатывающих внутри себя приличное (несколько миллионов) количество строк.

ну да, ну да. "мультимастер — это шарлатанство". но это только до тех пор, пока в постгресе её нет. а как только она появится, это будет объявлено величайшей победой, самой долгожданной фичей релиза и вообще непонятно, как мы раньше жили

(spoiler alert) ее и не будет

Встроенная пг репликация логическая -- это попытка скрестить бинарный лог с буфером логических изменений -- крайне спорное архитектурное решение, например потому что лог изменений более не в шареных буферах ну и ещё ряд замечаний есть конечно

триггеры слоника пуляют запросы на ведомого из очереди, а вал_сендер в пглогике сначала вычитывает вал, затем преобразует его в запросы и уже эти запросы пуляет на ведомого. Если у кто-то считает себя бессмертным и может позволить себе заниматься ерундой, то потестируйте, где какой оверхед будет. Это вот как оно внутри.

из какой очереди? как в этой очереди данные появляются? В общем в таком lor стиле не вижу смысла продолжать дискуссию

Вот как работает слоник: http://www.slony.info/documentation/2.2/advanced.html

Используем slony несколько лет, ни разу не было проблем по логике. На нескольких миллионах строк бывает лаг репликации небольшой, но быстро рассасывается. Зависит конечно от сети между нодами.

Вот как работает слоник: http://www.slony.info/documentation/2.2/advanced.html

А сами то пробовали разобраться внутри как это все происходит? Сколько на один update записи в таблице под slony репликой, происходит скрытых действий (инсертов) во всей slony_backend кухне?

А сами то пробовали разобраться внутри как это все происходит? Сколько на один update записи в таблице под slony репликой, происходит скрытых действий (инсертов) во всей slony_backend кухне?

Просмотрел - несмертельно. Ну и опыт таки есть эксплуатации на хитровывернутой конфигурации, когда изменения из одной пары табличек триггерами переливаются в две другие. А эти две другие уже улетают по через слоников в куда им положено.

ну вот теперь вернемся к твоему утверждению: "pglogical - это slony, засунутый в постгрес."

я не собираюсь тут спорить что лучше, что хуже

я просто сказал, что это утверждение - бред

ну вот теперь вернемся к твоему утверждению: "pglogical - это slony, засунутый в постгрес."

Я, каяться не буду, написал провокационное сообщение. "pglogical - это slony засунутый в postgres" - фраза относится к настройке. Вот pglogical: https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/ Вот slonik: http://www.slony.info/documentation/2.2/concepts.html Найдите существенную разницу. Лично я такой разницы в концепцях не вижу.

Люблю почитать вот такие споры - много интересных ссылок )

@aggeisoft ссылки на официальную документацию - интересные?! o_O

Ну я slony не использовал. Тут прочитал - по чату вкратце понял - о чем... заинтересовался... - а тут и ссылок завезли - чудесно )

@Komzpa в новом клиенте можно гибко бан настраивать. Я уже заценил. И просматривать список ранее забаненных

ещё бы сделали, что по дефолту юзер без голоса

ещё бы сделали, что по дефолту юзер без голоса

А ты из России?

да

Ребят подскажите, как делается перенос базы с одного сервера на другой. Оба сервера отличаются: пользователями, настройками и т. п. пытаюсь при помощи pgadmin 4. Устанавливаю метки не писать владельцев, привилегии и т. п. Но все равно ошибка. сервера одной версии 9.6.2

о. руководство 25.1.2. Сейчас по пробую

у меня получилось )))) pg_dumpall

привет! Хочу развернуть постгрес в докере. Обычно я разворачивал его в обычной виртуальной машине. В чем профит поставить его в докере? Проект домашний, так что больше для самообучения

По ресурсам требования меньше? можно будет с компьютера на компьютер перенести?

возьми готовый образ с хаба для начала

есть возможность его расширить

готовый образ это такой файл? https://github.com/docker-library/postgres/blob/master/9.6/Dockerfile

Вроде. Фильтр по официалтному поставь, он там один будет

Вот почитал я вас и подумал. Сейчас у меня sql код размазан по питоновскому классу-интерфейсу к базе. Правда ведь правильно будет вынести его во внешний .sql файл и скрыть за функциями которые и дёргать из питона? Какие ещё есть варианты? Эктеншон может? Как я понял там как минимум обновления удобно сделаны.

Orm

Sqlalchemy прсмотри

Да, алхимия очень подойдёт. Стоит смотреть в этом направлении

Не сильно понимаю как орм поможет. По мне так оно только для тривиальных запросов типа записать объект/сделать выборку, а у меня представления, with recursive и в планах триггеры

Не сильно понимаю как орм поможет. По мне так оно только для тривиальных запросов типа записать объект/сделать выборку, а у меня представления, with recursive и в планах триггеры

ну как это зачем? лишний уровень абстракции со своим характером! </sarcasm-mode>

Во-во, еще и запросы переписывать

Вот почитал я вас и подумал. Сейчас у меня sql код размазан по питоновскому классу-интерфейсу к базе. Правда ведь правильно будет вынести его во внешний .sql файл и скрыть за функциями которые и дёргать из питона? Какие ещё есть варианты? Эктеншон может? Как я понял там как минимум обновления удобно сделаны.

SQL в одном файле - это, по моему глубокому убеждению - правильное пиво. :) Я в одной наколенной поделке так делаю, только не ф-ии вызываю, а сам запрос из массива запросов

А разве представления и триггеры не нужны как раз для того чтобы потом запросы были тривиальные? Всю сложность логики упрятал во вью и делаешь простой SELECT ... WHERE

имеет ли смысл делать STONITH на 3-х узловом кластере, при чем бд постгре только на 2 узлах, третий для кворума?

кластер посгри через стрим реплику, общего шаред диска нет

ERROR: S client not available

Посигис 2.3.3 затегировали

имеет ли смысл делать STONITH на 3-х узловом кластере, при чем бд постгре только на 2 узлах, третий для кворума?

Конечно нет https://github.com/blog/1364-downtime-last-saturday Пытаться пристрелить сервак, который уже себя ведет неадекватно или плохо слышен и надеяться, что это сработает - так себе идея.

SQL в одном файле - это, по моему глубокому убеждению - правильное пиво. :) Я в одной наколенной поделке так делаю, только не ф-ии вызываю, а сам запрос из массива запросов

Ну да. Я еще вспомнил, правда, что у меня много где запросы генерятся, так что не факт что получится прям всё вынести

здравствуйте! у кого-то есть опыт работы с ddrescue? я хочу знать, почему при создании копии с устройства в документации рекомендуется его отмонтировать, даже в случае, если оно смонтировано readonly

@AMDmi3 дальняя дорога начинается с первого шага. И я думаю, что готовые и генерируемые запросы (спасибо за идею, однако!) имеет смысл разнести по разным файлам. А ОРМ-ы... Ну посмотрел я на результаты алхимии. Показал разрабам косяки в запросах. Те преисполнились грусти, печали, тлена, тоски и безысходности. ПАтАмуШтА ОРМ. Но это было на прошлой работе.

здравствуйте! у кого-то есть опыт работы с ddrescue? я хочу знать, почему при создании копии с устройства в документации рекомендуется его отмонтировать, даже в случае, если оно смонтировано readonly

Почему нужно отмонтировать rw должно быть очевидно. А ro может просто чтобы лишней нагрузки не было

вот я тоже задумался. может ли быть такое, что монтирование в ro режиме может привести к неконсистентному состоянию копии? для dd просто та же рекомендация

В ro я думаю не может

а вообще делать копии через dd/ddrescue со смонтированных в ro разделов кому-то приходилось? при условии, что в разделы будут периодически приходить запросы

@AMDmi3 дальняя дорога начинается с первого шага. И я думаю, что готовые и генерируемые запросы (спасибо за идею, однако!) имеет смысл разнести по разным файлам. А ОРМ-ы... Ну посмотрел я на результаты алхимии. Показал разрабам косяки в запросах. Те преисполнились грусти, печали, тлена, тоски и безысходности. ПАтАмуШтА ОРМ. Но это было на прошлой работе.

Просто тут подход совсем разный. Статический то просто .sql файл, а если генерить то нужно в питоне оставлять, тогда и выносить ничего во внешний файл смысла нет. Я думал может какие best practices есть на эту тему, помимо orm

> Вот почитал я вас и подумал. Сейчас у меня sql код размазан по питоновскому классу-интерфейсу к базе. Правда ведь правильно будет вынести его во внешний .sql файл и скрыть за функциями которые и дёргать из питона?

@AMDmi3

есть вот такой пример

http://tapoueh.org/blog/2017/06/how-to-write-sql/#integrating-sql-code-in-python-with-anosql

anosql

идея: ".. your SQL in a query.sql file and then expose your queries as functions. .."

на первый взгляд симпотично: надо еще критически взглянуть на рефактокринг при таком подходе -- удоббно ли пойдет и все ли завсимсости будут легко находится

ну и не забываем: планы в параметризированных запросах в общем виде могут зависеть от конкретных их занечний на входе

Фонтейн, прикольный тип конечно

Хм, посмотрю, спасибо

скажите пожалуйста если я хочу сделать pg_dump базы 390Гб, а в хоме есть лишь 300Гб то как лучше поступить? и как вообще оценить какого размера будет бекап?

скажите пожалуйста если я хочу сделать pg_dump базы 390Гб, а в хоме есть лишь 300Гб то как лучше поступить? и как вообще оценить какого размера будет бекап?

Используйте сжатие

$ pg_dumpall | gzip > /var/lib/pgsql/9.6/backups/osm_int.gz процесс идёт. в один поток. и никак не проконтролировать

-1 Гб

вот бы распараллелить

55 ядер простаивает

pg_dump -f /backup/<db_name> -Fd -j 8

дамполл хочу )

хотя

$ pg_dumpall | gzip > /var/lib/pgsql/9.6/backups/osm_int.gz процесс идёт. в один поток. и никак не проконтролировать

1 гиг уходит за чуть больше чем 2 минуты. на все 300 10 часов. но вей )

никогда не мог понять причин существования pg_dump и pg_dumpall в виде двух различных утилит. функционал-то на 90% пересекается