Там просто удобно что есть разделение на Worker / Coordinator Node.

Там просто удобно что есть разделение на Worker / Coordinator Node.

Coordinator Node не является Single Point Of Failure?

Coordinator Node не является Single Point Of Failure?

Обычно используется Streaming Replication для них - ставлю 4 шт с RAID'ом 10ткой, в принципе норм.

Я использую Citus расширение для потоковой репликации и failover'a - работает нормально.

а есть в open source?

Он OpenSource

есть

https://www.citusdata.com/product/community

Недавно зарелизили ...

я тогда не понял, где сам файловер? он с ванилой не работает?

Пока использую до выхода pg10.

я тогда не понял, где сам файловер? он с ванилой не работает?

Он работает "поверх" ванильной потоковой реплизации...

https://docs.citusdata.com/en/stable/aboutcitus/introduction_to_citus.html

ПАНИКА: не удалось открыть файл "pg_xlog/0000000100000484000000E2": Input/output error Это значит поздно пить боржоми?

нет, он может: - ещё не прилететь с мастера - улететь в archive

нет, он может: - ещё не прилететь с мастера - улететь в archive

у меня нет реплик, это один сервак

тогда посмотреть ошибки по диску

я хотел удалить одну БД, а он вот так ругнулся

ПРЕДУПРЕЖДЕНИЕ: could not remove file or directory "base/829987": Input/output error ПРЕДУПРЕЖДЕНИЕ: в старом каталоге базы данных "base/829987" могли остаться ненужные файлы

и ещё вот так

dmesg [-T] | tail -n20

ага как сервак поднимется, он походу ушёл в нирвану, весь ))

Как там ноду фенсите? Что бы избежать split brain?

не понял синтаксиса

Коллеги, добрый день.

Подскажите пожалуйста, настраиваю потоковую репликацию на 9.4

Не взлетает Постгрес на слейве с recovery.conf

Если recovery.conf убрать, то все ок.

Если recovery.conf убрать, то все ок.

?

Как переживает нетсплиты?

За состав кластера и его лидера отвечает etcd или другая DCS. Именно от ее состояния и зависит работоспособность patroni. Например у вас 3 ДЦ. Кластер etcd из 5 нод. В таком случае можно потерять один ДЦ. Те ноды patroni, которые будут в отвалившемся ДЦ увидят, что etcd сломался и перейдут в read-only

?

?

Если у тебя нет recovery.conf - то это не slave

Без этого файла реплика не работает

Не взлетает Постгрес на слейве с recovery.conf

Замечательное описание! Только вот проблема в том, что телепатиев всех давным давно повывели к такой-то матери. Поэтому без озвучивания ошибки никто и ничем помочь не сможет.

Прошу прощения, тупая ошибка, hotstandby в самом конфиге был выключен.

господа, а подскажите плиз хорошую документацию по кластеризации сабжа

официальная дока несколько скупа на детали

господа, а подскажите плиз хорошую документацию по кластеризации сабжа

А такой в природе не существует. ПАтАмуШтА кластеризация - только и исключительно по через иное стороннее ПО.

И этого ПО - есть некоторое количество. Причём совершенно разное.

А такой в природе не существует. ПАтАмуШтА кластеризация - только и исключительно по через иное стороннее ПО.

ок, извините, я несколько неправильно выразился. Кластеризация это не то, что мне надо. Имелась в виду репликация

есть типичная задача восстановления мастера после того, как слейв ушёл вперёд

Репликация описана достаточно подробно и обстоятельно в официальной документации.

можно ли её как-нибудь решить помимо копирования БД или включения режима жёсткой репликации (транзакция не завершится, пока лог не отреплицируется)?

есть типичная задача восстановления мастера после того, как слейв ушёл вперёд

Есть pg_rewind, который умеет откатывать базу назад. Возможно это то что вам нужно.

Есть pg_rewind, который умеет откатывать базу назад. Возможно это то что вам нужно.

о, возможно

большое спасибо!

отлично, да, то, что надо. У меня сервер 9.3 (так исторически сложилось), на 9.5 и выше просто не смотрел. Спасибо!

буду обновляться :)

буду обновляться :)

так себе занятие

В Avito скрестили PostgreSQL с CTF-ом! Хотите посмотреть на результат? Приходите на #PGHACK! Где регистрироваться? На TimePad до 25 августа включительно: https://goo.gl/7Wv1yj. Что это? Чемпионат по управлению базами данных с практическими задачами. Реализован на разработанной с нуля платформе. Получилось интересно. Протестировано на внутреннем соревновании. Зачем? Решать амбициозные задачи, общаться и соревноваться с коллегами-профессионалами в Postgres в атмосферном офисе Avito. Когда и где? Финал пройдет 2 сентября в московском офисе Avito. Будут задачи на восстановление работоспособности базы данных, понимание механизмов её работы, выявление ошибок и недостатков эксплуатации. Результаты будут определяться автоматической проверочной системой в режиме реального времени одновременно у всех участников. Кто победит? Если у вас есть базовые знания по работе с Linux, понимаете, что такое MVCC, как работают триггеры, как база данных обеспечивает валидность данных, которые хранятся в таблице — то вы уже на пути к победе! Что там с призами? Чемпиону достанутся квадрокоптер и билет на PG Day Russia 2018. ТОП-10: наборы с Arduino, гаджеты, мини-коптеры. Всех участников финала ждут приличные запасы пиццы, пива и сувениры от Avito.

В Avito скрестили PostgreSQL с CTF-ом! Хотите посмотреть на результат? Приходите на #PGHACK! Где регистрироваться? На TimePad до 25 августа включительно: https://goo.gl/7Wv1yj. Что это? Чемпионат по управлению базами данных с практическими задачами. Реализован на разработанной с нуля платформе. Получилось интересно. Протестировано на внутреннем соревновании. Зачем? Решать амбициозные задачи, общаться и соревноваться с коллегами-профессионалами в Postgres в атмосферном офисе Avito. Когда и где? Финал пройдет 2 сентября в московском офисе Avito. Будут задачи на восстановление работоспособности базы данных, понимание механизмов её работы, выявление ошибок и недостатков эксплуатации. Результаты будут определяться автоматической проверочной системой в режиме реального времени одновременно у всех участников. Кто победит? Если у вас есть базовые знания по работе с Linux, понимаете, что такое MVCC, как работают триггеры, как база данных обеспечивает валидность данных, которые хранятся в таблице — то вы уже на пути к победе! Что там с призами? Чемпиону достанутся квадрокоптер и билет на PG Day Russia 2018. ТОП-10: наборы с Arduino, гаджеты, мини-коптеры. Всех участников финала ждут приличные запасы пиццы, пива и сувениры от Avito.

Вы тоже забыли начать объявление с города, молчу про страну?

Россия, Москва, Лесная 7

Лесная - эт не на белорусской часом?

Лесная - эт не на белорусской часом?

На ней.

Россия, Москва, Лесная 7

3-я планета от Солнца ))

Кластер то какой, кластер!

ММО

Простите, а кто использует mamonsu?

ERROR: S client not available

Стоит ли, надо ли?

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

может кто сталкивался с такой необходимостью

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

Видимо в тех местах где его сертифицировали

Ага. Прямо в ФСТЭК/ФСБ обращайтесь :)

%)

надо просто кой чего пофиксить, то что лечится только пересборкой

надо просто кой чего пофиксить, то что лечится только пересборкой

Так потом сертификация вроде не действительна

Орёл - это коммон едишн. Сертифицирован - Смоленск

просто они в сборке орла оставили NAMEDATALEN = 64, а в сертифицированной версии 255

разработка спотыкается

Всем привет. Какие могут быть подводные камни у pg_advisory_lock? Баунсера нет. Лок будет браться в джобке в рельсах, потом будет две транзакции, потом сниматься. Нужен на случай запуска второй подобной джобки - она должна дождаться завершения первой. Я до этого использовала только транзакционные локи, а тут возникла необходимость сделать вместо одной долгой надежной транзакции одну быструю (для пользователей) и одну долгую (для надежности). Где-то попадалась инфа, что с сессионными могут быть непонятные проблемы, с которыми сложно будет потом разбираться.

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

С этими локами нужно еще быть осторожнее если они используются в конструкциях типа WHERE try_pg_advisory_lock LIMIT

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

А чем можно заменить в подобной ситуации? Коллега предлагает выполнить короткую транзакцию в отдельном треде в параллельном коннекте (видимо, после взятия транзакционного лока в длинной транзакции), но я не уверена, что это нормальное решение

а как нужно разруливать фейлы на каждом этапе?

что будет, если упадёт первая транзакция, вторая транзакция, приложение между ними?

Всем привет. Какие могут быть подводные камни у pg_advisory_lock? Баунсера нет. Лок будет браться в джобке в рельсах, потом будет две транзакции, потом сниматься. Нужен на случай запуска второй подобной джобки - она должна дождаться завершения первой. Я до этого использовала только транзакционные локи, а тут возникла необходимость сделать вместо одной долгой надежной транзакции одну быструю (для пользователей) и одну долгую (для надежности). Где-то попадалась инфа, что с сессионными могут быть непонятные проблемы, с которыми сложно будет потом разбираться.

Может быть два SQL-connect'а? Один исключительно для лока, а второй собственно рабочий для транзакций. Тогда вся логика взаимолоков будет на стороне приложения

можно завести маленькую табличку с unique constraint, и если в ней есть строка с локом - не начинать транзакцию

Обычно в локах для распрделенных решений используют оптимистичную блокировку с записью по одному ключу для всех, кто хочет взять лок на задачу. Есть какая-нибудь таблица application_locks (id string, expires_at datetime, version int), при попытке захватить лок приложение пытается записать по уникальному айдишнику запись с expires_at = текущее время + некоторый безопасный интервал. Если запись уже существует и expires_at < текущего времени, он пытается ее обновить, указывая в WHERE текущую версию, а в обновленных данных - версию + 1, повторяя операцию, пока либо не захватит лок, либо не увидит, что его захватил кто-то другой. Во время выполнения задачи запись постоянно обновляется приложением. Плюсы: отсутствие дедлоков, минусы: необходимость писать на диск, выбирать правильный интервал и находить доказательства того, что во время выполнения задачи лок будет обновляться в фоне, увеличивая expires_at.

а как нужно разруливать фейлы на каждом этапе?

О, привет ) Ну, это такая, штучная операция, бывает пару раз в пару недель, и оно никогда не падало, так что в таком случае всяко полезем разбираться сами.

@etkee всё в деталях расписал, даже добавить нечего

Спасибо!

у pgpro есть автономные транзакции, там можно посреди одной транзакции открыть новую, закоммитить и пойти дальше по родительской

Всем доброе утро.

Вчера обновились до 9.6 через pglogical.

Прив