эта утилита нужна для поиграть и создание иллюзии благополучия. для серьезного восстановления только бекапы

часть данных могла остаться в памяти часть записаться консистентности по тем же fk может уже не быть в таких данных если например был креш

А кто-нибудь настраивал pglogical? Если да, можно пару вопросов? https://2ndquadrant.com/it/resources/pglogical/

Всем привет. Информация для тех кто интересовался работой #pg_pathman с приложением на джанге. Как и обещал проверил работу на приложении с джангой. Всё работает как нужно. Вставка идёт сразу в партицию. И для джанги результат записи id возращает.

Всем привет. Информация для тех кто интересовался работой #pg_pathman с приложением на джанге. Как и обещал проверил работу на приложении с джангой. Всё работает как нужно. Вставка идёт сразу в партицию. И для джанги результат записи id возращает.

ура! :)

ура! :)

Статейку накрапали про различия партицирования в 10 и pg_pathman? ?

Статейку накрапали про различия партицирования в 10 и pg_pathman? ?

пока еще нет, как будет время - сделаем

Как-то так я и понял. Слава богам, удалось получить пару не таких древних бекапов)

+ как минимум отсутвует clog, данные уже треш и можно закапывать.

Добрый день! Может есть какие-то исследования или рекомендации, что на новых ядрах postgresql 9.6 работает быстрее? Выбираю между centos 7 или свежей ubuntu, например. Вот думаю, стоит экспериментировать с ubuntu последней или, как и раньше, взять centos и разницы не будет?

используй не быстрые а стабильные ядра, ядра el - пронебойные <сарказм>если нужно быстро - то fsync = off</сарказм>

а у кого-нить fsync=off в проде был?

а у кого-нить fsync=off в проде был?

приходили с просьбой востановить данные ;)

можно еще CachedBadBBU если хочется больше экстрима

Ненене, только в рамках разрешённой магии

используй не быстрые а стабильные ядра, ядра el - пронебойные <сарказм>если нужно быстро - то fsync = off</сарказм>

или oracle unbreakable kernel

Буду немного предвзят... но на centos (и кстати OL тоже) ловил вот такое https://i.gyazo.com/2a3965fa74ae783731dd55b459541a15.png несколько раз. На ubuntu - ни разу.

Такая ошибка "приносит много радости"

Причина вероятнее в ЦОДе, но факт, что в том же ЦОД с ubuntu такого не происходит

Может у вас убунта банально не видит этих ошибок. И вы сидите с битой БД и думаете, что всё ок?

Ну по итогу этих ошибок - БД ушла в recovery

Поэтому как минимум - бд там в recovery не уходит

Поэтому как минимум - бд там в recovery не уходит

pg в рековери уходит только если стартанет с грязным control data или упадет процесс который заморал shb

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

Всем привет! Мы работаем над внедрением поддержки foreign key для партицированных таблиц в pg_pathman. Есть рабочий прототип, который позволяет референсить партицированную таблицу из обычных (сейчас реализовано поведение ON DELETE RESTRICT ON UPDATE RESTRICT). Если кому интересно это потестировать, велкам в ветку rel_future_ri на гитхабе (см. функцию create_foreign_key())

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

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

Так это же вроде вызвано отсутствием глобальных уникальных индексов. Собираетесь их запилить?

Ребят очень важен ваш совет помогите пожалуйста : http://www.sql.ru/forum/1257948-a/sovet-po-vysokoy-dostupnosti

Так это же вроде вызвано отсутствием глобальных уникальных индексов. Собираетесь их запилить?

можно обойтись без индексов. В постгресе reference integrity реализовано через триггеры. Мы создаем свои триггеры, которые знают где искать нужный ключ и подставляем их вместо стандартных

можно обойтись без индексов. В постгресе reference integrity реализовано через триггеры. Мы создаем свои триггеры, которые знают где искать нужный ключ и подставляем их вместо стандартных

скажем так, работать это будет для ключа партицирования

не для произвольных колонок

триггеры конечно написаны на C и работают не хуже стандартных

Парни почему может долго висеть запрос такого вида ?

state | idle in transaction query | DEALLOCATE pdo_stmt_0000003f

elapsed | 00:06:02.149565 datid | 16426 datname | processing pid | 107393 backend_start | 2017-04-21 12:29:02.121415+00 xact_start | 2017-04-21 12:29:02.430436+00 query_start | 2017-04-21 12:49:27.617382+00 state_change | 2017-04-21 12:49:27.617395+00 waiting | f state | idle in transaction query | DEALLOCATE pdo_stmt_0000003f

Всем привет! Мы работаем над внедрением поддержки foreign key для партицированных таблиц в pg_pathman. Есть рабочий прототип, который позволяет референсить партицированную таблицу из обычных (сейчас реализовано поведение ON DELETE RESTRICT ON UPDATE RESTRICT). Если кому интересно это потестировать, велкам в ветку rel_future_ri на гитхабе (см. функцию create_foreign_key())

О! А разве этого сейчас нет?

elapsed | 00:06:02.149565 datid | 16426 datname | processing pid | 107393 backend_start | 2017-04-21 12:29:02.121415+00 xact_start | 2017-04-21 12:29:02.430436+00 query_start | 2017-04-21 12:49:27.617382+00 state_change | 2017-04-21 12:49:27.617395+00 waiting | f state | idle in transaction query | DEALLOCATE pdo_stmt_0000003f

Приложение просто держит транзакцию.

О! А разве этого сейчас нет?

nope, в мастере пока нет

Приложение просто держит транзакцию.

А можно понять со стороны базы понять по какой причине держится транзакция ? , это незакрытвый коннект c базой , или некрытый BEGIN ?

или еще что моежт быть ?

статусы разные, у незакрытой транзакции idle in transaction

state | idle in transaction

тоесть в коде ошибка ? транзакции незакрываются должным образом ?

скорее всего, надо закрывать транзакции )

просот вручную както стремно это делать :) ща разрабов пойду мучить , сегодня после деплоя это началось

пятница вечер, самое время )

Деплой по пятницам ??

гвозди бы делать из этих людей.

пятничное: насколько плохо из pl/perl или pl/python генерить PDF на лету из базы ?

Я понимаю что пятница вечер но очень нужен совет http://www.sql.ru/forum/1257948-a/sovet-po-vysokoy-dostupnosti

пятничное: насколько плохо из pl/perl или pl/python генерить PDF на лету из базы ?

Лучше бы сбоку от базы - масштабируется и дебажится лучше.

это я понимаю

но вдруг кто-то подобное уже делал :)

пятничное: насколько плохо из pl/perl или pl/python генерить PDF на лету из базы ?

на лету из базы - зависит от того, куда надо писать, одно дело в stdout, а совсем другое - в файл. Для файла, скорее всего, нужны будут права на запись в соответствующий каталог. С последующим чтением из-под ну совсем других аккаунтов.

выкинуть пользователю в веб

Лучше бы сбоку от базы - масштабируется и дебажится лучше.

А масштабируется-то чем лучТше? А так - вполне себе задача. Прикольно было бы на выхах поразвлечься, жаль времени нет и неизвестно. :(

выкинуть пользователю в веб

лично я серьезных минусов не вижу - вполне себе задача...

но вдруг кто-то подобное уже делал :)

Делал в Oracle + Java. Когда эта вешь в себе ломается с лаконичной ошибкой ORA-XXXXX совершенно непонятно как с этим справляться.

спс за отзыв

надо заплатить, чтобы тебе ORA-xxx расшифровали))

Делал в Oracle + Java. Когда эта вешь в себе ломается с лаконичной ошибкой ORA-XXXXX совершенно непонятно как с этим справляться.

платный софт он такой

Делал в Oracle + Java. Когда эта вешь в себе ломается с лаконичной ошибкой ORA-XXXXX совершенно непонятно как с этим справляться.

Кто мешает написать ф-ию с вменяемыми сообщениями об ошибках?

кто не в курсе поясню - в ораксе специально спрятана инфа по ошибкам. за денюжку тебе ее расшифруют. придется заплатить за все время с начала использования

ERROR: S client not available

если у тебя уже не куплен оракл

лично я серьезных минусов не вижу - вполне себе задача...

Если по какой-то причине процессу не хватит памяти (очень большой файл, например) процесс может упасть и потащить за собой postmaster.

а он разве не начнет свапиться на диск ?

Свопа может и не быть )

Я нехватку памяти привел для примера. Может ещё стек закончиться или null pointer exception какой-нибудь во внешней либе )

Я просто к тому, что так конечно делать можно, но очень осторожно.

@pensnarik, @dezconnect, коллеги, зачем писать в файл? Сразу гнать вывод клиенту.

да про файл никто и не говорит.

тут скорее интересует что будет с менеджментом памяти при всем этом

@dezconnect select * from verybigtable же не падает. Просто ждать замордуешься.

ну, я вот и удивляюсь что что-то должно сломаться по out of memory

разве что в ф-ии что-нибудь при формировании вывода...

Но, по моему скромному мнению, в пг вполне себе возможно и отловиить, и отладить такое безобразие.

Я понимаю что пятница вечер но очень нужен совет http://www.sql.ru/forum/1257948-a/sovet-po-vysokoy-dostupnosti

А что, постгрес разве уже научился пользоваться одним хранилищем для нескольких инстансов?

@Chuguniy к сожалению еще нет (

А стало быть, верхняя схема не имеет права на существование.

да получается так, мне на посоветовали вот такю схему : Postgresql + Repmgr + Barman кто-нибудь использовал ?

да

Да

При использовании barman в момент бэкапа, канал под 2гбит/с забирал на себя ... и начинались лаги у всех пользователей ... пришлось интерфейс на доступ пользователей делать отдельный, а репликация и барман через отдельный шуровал ... в принципе это единственный затык был ... а так, дельная связка ...

Размер базы ~ 22 gb

При использовании barman в момент бэкапа, канал под 2гбит/с забирал на себя ... и начинались лаги у всех пользователей ... пришлось интерфейс на доступ пользователей делать отдельный, а репликация и барман через отдельный шуровал ... в принципе это единственный затык был ... а так, дельная связка ...

у бармана шейпер есть

у бармана шейпер есть

Да!) об этом мы как-раз и узнали после момента затыка ... !)

Для истории bandwidth_limit

для репликации сейчас модно слоты использовать

Да! Мы их и используем, каскадная потоковая репликация ...

например у меня есть клиент у кого на депозите лежит 10к , он заплатил что-нибудь например за 1к мастер закомитил транзакцию и рухнул, реплика не успела забрать данные при failover у меня на реплике депозит будет 10к вместо 9к это уже проблема , интересно как другие решают такие проблемы при асинхронной реплике, для меня единственный вариант чтоб такой проблемы не было это синхронная реплика.

используют CP-системы

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

Ну или при невозврате приложением сообщения об успехе до тех пор, пока оно не прочтет нужное значение с реплики