Pull to refresh

Comments 45

Вы забыли дописать главное:
+ контроль через telegram

В статье есть скрипт для отправки в телеграмм. Он запускается с аргументом сообщения.
Например так
Скрытый текст
sh /etc/postgresql/telegram.sh тест 


В самом скрипте указываем userid получателей, и добавляем его в код скриптов.
В секции «Как отключить автозапуск»
nano /etc/postgresql/9.1/main/start.conf
заменяем auto на manual

путь видимо не верно указан, обычно же по версии postgresl назвается директория, т.е должно быть так:
/etc/postgresql/9.6/main/start.conf
Вспоминается старый анекдот: «и вот теперь со всей этой… мы попытаемся взлететь».

У вас есть опыт эксплуатации этого скажем года два? Какой уровень доступности получили? Были ли за это время проблемы с железом? Что делали, если понимали, что мастер упал на долго и неизвестно все ли изменения приехали?
Дело в том, что при падении мастера автоматически происходит включение нового мастера(через промежуток времени, указанный в конфигах), соответственно существует риск того, что не все данные успели попасть на standby. Есть несколько вариантов решения данной проблемы:
— синхронная репликация( мастер будет ждать подтверждения insert’ов от standby);
— включать старый мастер (без ввода в кластер) и проверять, попали ли последние данные с мастера в кластер.
Определенный риск есть всегда, но в данной конфигурации мы имеем сценарий реализации HA. Придется с чем то мириться.
Проблем с железом не было.
Нет не пробовали, мультимастер показывает худшую производительность при update и insert, чем данная схема c асинхронной репликацией или чем standalone Postgresql, хотя тоже имеет право на существование для определенных сервисов.
> худшую производительность
А меряли сами, или можно почитать какие там ограничения и подводные камни?
У нас работает мультимастер на BDR, но там не сильно большая нагрузка по вставкам.
Сейчас планируем новый сервис где нагрузка будет значительно больше.

Не очень понял, как организован роутинг запросов (чтение-запись) — не проясните подробнее?

Все запросы на запись-чтение должны идти через master ноду (haproxy+pgbouncer или просто pgbouncer), остальные standby ноды необходимо прописать на ноде с haproxy в режиме балансировки (roundrobin). Сами режимы(на какой ip только чтение, на какой чтение/запись) у нас реализованы на уровне приложений, т.е в коде приложений.
А еще завернуть это все в puppet/chef/ansible/salt/etc и вообще лафа начнется…

А так — интересно, спасибо.
Да! Вот теперь всё стало просто и интуитивно понятно! Спасибо!
Спасибо за статью!
Не смотрели в сторону Patroni от Zalando?
Они как раз таки решают на базе etcd проблему split brain и автоматического failover.
В презентации указывали что у них сотни серверов работают через эту систему.
В данной системе Split Brain проблемы нет, если все грамотно настроено. На за совет насчет Patroni от Zalando спасибо, обязательно попробую.
Я не уверен в том что проблема Split Braint решена :)

Отвечает за выбор мастера — Witness. Честно не искал информацию по поводу него (игры в Steam на первой странице Google :) ) и не могу ничего сказать, но вы выделяете целую ноду для него. А если эта нода упадет и паралелльно упадет мастер? Что тогда делать?
Для этого требуется хранить данные о мастере распределенно — для этого используются etcd, zookeeper, consul. Вы ставите каждый элемент данной систем на каждую ноду и у вас кластер хранения конфигурации. Благодаря этой системе существует кворум требуемый для выбора мастера.
А в вашей конфигурации может случится, что мастер просто потеряет связть с другими (частью) слейвами и Witness и начнется переконфигурирование кластера.

Я думаю вам понравится Patroni, потому что это как надстройка над Postgres, управляющая всеми этими скриптами копирования.
Они решают проблему хранения информации и выбора мастера за счет etcd.
Они только не сделали поддержку слейв сервера, на которого нельзя переключать мастер, но вроде уже начинают делать.
Тестировали у себя 1 месяц, а потом перешли в продакшн на эту систему. Полет хороший :)
За ansible версию этой статьи готов был бы даже заплатить.
Вопрос насчёт бэкапа. В статье мы получаем дамп базы. Это лучше чем ничего, но нужен-то непрерывный бэкап, то есть что-то вроде barman или любой способ собирать логи. Вопрос — как это делать? Простейший случай — после миграции начинать новый архив, тогда у нас будет по одному архиву на миграцию. Нельзя ли это как-то прооптимизировать, чтобы 1) полный бэкап делался быстро, 2) при архивировании как-то использовались ранее собранные логи. То есть цель — снизить нагрузку системы на бэкапирование и по производительности, и по занимаемому месту.

Насчёт patroni — это монстр на питоне, жёстко привязанный к древним версиям etcd и конкретным версиям модулей pyton, и сделан с учётом работы на амазоновском кластере. На Debian 8 так у меня и не заработал, надо ориентироваться на ту ОС которая прописана в документации. Мне тоже интересно почитать удастся ли его запустить.
Спасибо за подсказку, я думаю что надо посмотреть в сторону интеграции barman в данную структуру, тем более что сами разработчики предлагают использование barman как один из вариантов.
Я бы не сказал что это монстр по сравнению с тем, что описано в этой статье :)
Он не привязан к etcd. Можно выбрать еще consul или zookeeper. А версия etcd 3.0 вышла пару месяцев назад, так что etcd 2.3 не древняя.

Для работы на amazon они сделали Spilo построенный на patroni. Но у нас Azure, и мы спокойно запустили в Azure.
Для решения проблем запуска в какой ОС, мы использовали Docker. Делали Dockerfile на базе postgres, в котором устанавливался patroni. Возможно можно запустить patroni (в Docker) вообще отдельно от postgres (на Host), не пробовал. К контейнеру монтируем папку с бд на машине и нормальная работа.
Наверняка если есть какая то специфика (БД больше 10 Гб к примеру) это решение может не подойдет. Но мне кажется это хороший способ запуска кластера HA AF PostgreSQL.

Интересно. Мы как раз сейчас круги около patroni наворачиваем. Затяжная миграция с мускуля.
Вы не опенсорсили свои докерфайлы?

Спасибо, интересно почитать. Будет что добавить, скину PR.

Пожалуйста :)
Можете скинуть, но я к сожалению уже больше не поддерживаю данный репозиторий :)
На сегодняшний день процедура реализации «failover» в Postgresql является одной из самых простых и интуитивно понятных.

Спасибо, посмеялся :) однажды приходилось восстанавливать похожий кластер, ничего не интуитивно, если не сам разворачивал его.
Ну статья предполагает, что ты сам разворачиваешь)
Но не предполагает, что ты же будешь чинить:)
archive_command = 'cd .'
А зачем на мастере такой костыль? Если хотелось ничего не делать, то правильнее было бы вставить /bin/true. Но это лишает вас возможности восстанавливать состояние базы по WAL сегментам. Оверхед не большой, а удобство бекапа и восстановления повышает, да и полный слепок базы можно делать гораздо реже. Слепок данных на репликах вас не спасёт от случайных drop database ;).
У меня на боевых серверах полный бекап с реплики раз в неделю, а история изменений в WAL логах хранится за 10 дней.
В догонку.
wal_keep_segments = 3000 # чем больше, тем длиннее будет журнал тем проще будет standby ноде догнать master’a.
Так то оно так, но на больших и динамичных базах объём WAL сегменов может с лёгкостью в десятки раз превысить объём базы, сожрать всё место и похоронить сервер. А большое число сегментов совсем не гарантирует достаточный временной интервал для восстановления состояния. Тут-то как раз и сократить бы количество сегментов, да с умом использовать возможности archive_command.
Спасибо за комментарий.
archive_command = 'cd .' — ни критичен.
wal_keep_segments = 3000 — да можно сократить, я привел это как пример. Необходимо настроить под себя.
Непонятно. С одной стороны указано значение для wal_keep_segments, с другой используются слоты репликации. Нет ли тут какого-то противоречия?
wal_keep_segments — задаёт минимальное число файлов прошлых сегментов журнала, которые будут сохраняться в каталоге pg_xlog, чтобы резервный сервер мог выбрать их при потоковой репликации. Источник
wal_keep_segments, насколько я понимаю, альтернативный слотам метод.

Цитата из документации:

«Слоты репликации автоматически обеспечивают механизм сохранения сегментов WAL, пока они не будут получены всеми резервными и главный сервер не будет удалять строки, находящиеся в статусе recovery conflict даже при отключении резервного.

Вместо использования слотов репликации для предотвращения удаления старых сегментов WAL можно применять wal_keep_segments, или сохранять сегменты в архиве с помощью команды archive_command. Тем не менее, эти методы часто приводят к тому, что хранится больше сегментов WAL, чем необходимо, в то время как слоты репликации оставляют только то количество сегментов, которое необходимо. Преимущество этих методов состоит в том, что они чётко задают объёмы места, необходимого для pg_xlog; в то время как текущая реализация репликационных слотов не представляет такой возможности.»
Как я понимаю, то нет. Данные параметры используются совместно. Эти моменты хорошо описаны на сайте.
Я привёл выдержку из документации на том же сайте, из которой следует что совместно они не используются. Откуда следует, что используются?
«здесь» точно не описано. 1) слова «slot» на странице нет; описаны версии 9.0 и 9.1 как будущие, но слоты появились только в версии 9.4.
Всё верно, исправил. max_replication_slots предоставляет возможность больше не использовать wal_keep_segments, просто сделаем данное значение минимальным — 0.
Как я понимаю, то нет. Данные параметры используются совместно. Эти моменты хорошо описаны на сайте.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.e-soft.org
Employees
101–200 employees
Registered