Комментарии 45
Вы забыли дописать главное:
+ контроль через telegram
В секции «Как отключить автозапуск»
nano /etc/postgresql/9.1/main/start.conf
заменяем auto на manual
путь видимо не верно указан, обычно же по версии postgresl назвается директория, т.е должно быть так:
/etc/postgresql/9.6/main/start.conf
nano /etc/postgresql/9.1/main/start.conf
заменяем auto на manual
путь видимо не верно указан, обычно же по версии postgresl назвается директория, т.е должно быть так:
/etc/postgresql/9.6/main/start.conf
Да, все верно, исправил. Спасибо.
Вспоминается старый анекдот: «и вот теперь со всей этой… мы попытаемся взлететь».
У вас есть опыт эксплуатации этого скажем года два? Какой уровень доступности получили? Были ли за это время проблемы с железом? Что делали, если понимали, что мастер упал на долго и неизвестно все ли изменения приехали?
У вас есть опыт эксплуатации этого скажем года два? Какой уровень доступности получили? Были ли за это время проблемы с железом? Что делали, если понимали, что мастер упал на долго и неизвестно все ли изменения приехали?
Дело в том, что при падении мастера автоматически происходит включение нового мастера(через промежуток времени, указанный в конфигах), соответственно существует риск того, что не все данные успели попасть на standby. Есть несколько вариантов решения данной проблемы:
— синхронная репликация( мастер будет ждать подтверждения insert’ов от standby);
— включать старый мастер (без ввода в кластер) и проверять, попали ли последние данные с мастера в кластер.
Определенный риск есть всегда, но в данной конфигурации мы имеем сценарий реализации HA. Придется с чем то мириться.
Проблем с железом не было.
— синхронная репликация( мастер будет ждать подтверждения insert’ов от standby);
— включать старый мастер (без ввода в кластер) и проверять, попали ли последние данные с мастера в кластер.
Определенный риск есть всегда, но в данной конфигурации мы имеем сценарий реализации HA. Придется с чем то мириться.
Проблем с железом не было.
Мультимастер не пробовали?
Нет сами не измеряли, но на оф. вики postgres есть раздел. Данные оттуда.
Не очень понял, как организован роутинг запросов (чтение-запись) — не проясните подробнее?
Все запросы на запись-чтение должны идти через master ноду (haproxy+pgbouncer или просто pgbouncer), остальные standby ноды необходимо прописать на ноде с haproxy в режиме балансировки (roundrobin). Сами режимы(на какой ip только чтение, на какой чтение/запись) у нас реализованы на уровне приложений, т.е в коде приложений.
А еще завернуть это все в puppet/chef/ansible/salt/etc и вообще лафа начнется…
А так — интересно, спасибо.
А так — интересно, спасибо.
Да! Вот теперь всё стало просто и интуитивно понятно! Спасибо!
Спасибо за статью!
Не смотрели в сторону Patroni от Zalando?
Они как раз таки решают на базе etcd проблему split brain и автоматического failover.
В презентации указывали что у них сотни серверов работают через эту систему.
Не смотрели в сторону Patroni от Zalando?
Они как раз таки решают на базе etcd проблему split brain и автоматического failover.
В презентации указывали что у них сотни серверов работают через эту систему.
В данной системе Split Brain проблемы нет, если все грамотно настроено. На за совет насчет Patroni от Zalando спасибо, обязательно попробую.
Я не уверен в том что проблема Split Braint решена :)
Отвечает за выбор мастера — Witness. Честно не искал информацию по поводу него (игры в Steam на первой странице Google :) ) и не могу ничего сказать, но вы выделяете целую ноду для него. А если эта нода упадет и паралелльно упадет мастер? Что тогда делать?
Для этого требуется хранить данные о мастере распределенно — для этого используются etcd, zookeeper, consul. Вы ставите каждый элемент данной систем на каждую ноду и у вас кластер хранения конфигурации. Благодаря этой системе существует кворум требуемый для выбора мастера.
А в вашей конфигурации может случится, что мастер просто потеряет связть с другими (частью) слейвами и Witness и начнется переконфигурирование кластера.
Я думаю вам понравится Patroni, потому что это как надстройка над Postgres, управляющая всеми этими скриптами копирования.
Они решают проблему хранения информации и выбора мастера за счет etcd.
Они только не сделали поддержку слейв сервера, на которого нельзя переключать мастер, но вроде уже начинают делать.
Тестировали у себя 1 месяц, а потом перешли в продакшн на эту систему. Полет хороший :)
Отвечает за выбор мастера — Witness. Честно не искал информацию по поводу него (игры в Steam на первой странице Google :) ) и не могу ничего сказать, но вы выделяете целую ноду для него. А если эта нода упадет и паралелльно упадет мастер? Что тогда делать?
Для этого требуется хранить данные о мастере распределенно — для этого используются etcd, zookeeper, consul. Вы ставите каждый элемент данной систем на каждую ноду и у вас кластер хранения конфигурации. Благодаря этой системе существует кворум требуемый для выбора мастера.
А в вашей конфигурации может случится, что мастер просто потеряет связть с другими (частью) слейвами и Witness и начнется переконфигурирование кластера.
Я думаю вам понравится Patroni, потому что это как надстройка над Postgres, управляющая всеми этими скриптами копирования.
Они решают проблему хранения информации и выбора мастера за счет etcd.
Они только не сделали поддержку слейв сервера, на которого нельзя переключать мастер, но вроде уже начинают делать.
Тестировали у себя 1 месяц, а потом перешли в продакшн на эту систему. Полет хороший :)
За ansible версию этой статьи готов был бы даже заплатить.
Вопрос насчёт бэкапа. В статье мы получаем дамп базы. Это лучше чем ничего, но нужен-то непрерывный бэкап, то есть что-то вроде barman или любой способ собирать логи. Вопрос — как это делать? Простейший случай — после миграции начинать новый архив, тогда у нас будет по одному архиву на миграцию. Нельзя ли это как-то прооптимизировать, чтобы 1) полный бэкап делался быстро, 2) при архивировании как-то использовались ранее собранные логи. То есть цель — снизить нагрузку системы на бэкапирование и по производительности, и по занимаемому месту.
Насчёт patroni — это монстр на питоне, жёстко привязанный к древним версиям etcd и конкретным версиям модулей pyton, и сделан с учётом работы на амазоновском кластере. На Debian 8 так у меня и не заработал, надо ориентироваться на ту ОС которая прописана в документации. Мне тоже интересно почитать удастся ли его запустить.
Насчёт 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.
Он не привязан к 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 наворачиваем. Затяжная миграция с мускуля.
Вы не опенсорсили свои докерфайлы?
Опенсорсили.
https://github.com/lastbackend/devops-patroni
Но patroni уже ускакал вперед на сотню коммитов, поэтому может быть что нибудь изменилось.
https://github.com/lastbackend/devops-patroni
Но patroni уже ускакал вперед на сотню коммитов, поэтому может быть что нибудь изменилось.
"pg_dumpall dbname > gzip > filename.gz"
в место ">" должно быть "|"
На сегодняшний день процедура реализации «failover» в Postgresql является одной из самых простых и интуитивно понятных.
Спасибо, посмеялся :) однажды приходилось восстанавливать похожий кластер, ничего не интуитивно, если не сам разворачивал его.
archive_command = 'cd .'А зачем на мастере такой костыль? Если хотелось ничего не делать, то правильнее было бы вставить
/bin/true. Но это лишает вас возможности восстанавливать состояние базы по WAL сегментам. Оверхед не большой, а удобство бекапа и восстановления повышает, да и полный слепок базы можно делать гораздо реже. Слепок данных на репликах вас не спасёт от случайных drop database ;).У меня на боевых серверах полный бекап с реплики раз в неделю, а история изменений в WAL логах хранится за 10 дней.
В догонку.
Так то оно так, но на больших и динамичных базах объём WAL сегменов может с лёгкостью в десятки раз превысить объём базы, сожрать всё место и похоронить сервер. А большое число сегментов совсем не гарантирует достаточный временной интервал для восстановления состояния. Тут-то как раз и сократить бы количество сегментов, да с умом использовать возможности archive_command.
wal_keep_segments = 3000 # чем больше, тем длиннее будет журнал тем проще будет standby ноде догнать master’a.Так то оно так, но на больших и динамичных базах объём WAL сегменов может с лёгкостью в десятки раз превысить объём базы, сожрать всё место и похоронить сервер. А большое число сегментов совсем не гарантирует достаточный временной интервал для восстановления состояния. Тут-то как раз и сократить бы количество сегментов, да с умом использовать возможности archive_command.
Непонятно. С одной стороны указано значение для wal_keep_segments, с другой используются слоты репликации. Нет ли тут какого-то противоречия?
wal_keep_segments — задаёт минимальное число файлов прошлых сегментов журнала, которые будут сохраняться в каталоге pg_xlog, чтобы резервный сервер мог выбрать их при потоковой репликации. Источник
wal_keep_segments, насколько я понимаю, альтернативный слотам метод.
Цитата из документации:
«Слоты репликации автоматически обеспечивают механизм сохранения сегментов WAL, пока они не будут получены всеми резервными и главный сервер не будет удалять строки, находящиеся в статусе recovery conflict даже при отключении резервного.
Вместо использования слотов репликации для предотвращения удаления старых сегментов WAL можно применять wal_keep_segments, или сохранять сегменты в архиве с помощью команды archive_command. Тем не менее, эти методы часто приводят к тому, что хранится больше сегментов WAL, чем необходимо, в то время как слоты репликации оставляют только то количество сегментов, которое необходимо. Преимущество этих методов состоит в том, что они чётко задают объёмы места, необходимого для pg_xlog; в то время как текущая реализация репликационных слотов не представляет такой возможности.»
Цитата из документации:
«Слоты репликации автоматически обеспечивают механизм сохранения сегментов WAL, пока они не будут получены всеми резервными и главный сервер не будет удалять строки, находящиеся в статусе recovery conflict даже при отключении резервного.
Вместо использования слотов репликации для предотвращения удаления старых сегментов WAL можно применять wal_keep_segments, или сохранять сегменты в архиве с помощью команды archive_command. Тем не менее, эти методы часто приводят к тому, что хранится больше сегментов WAL, чем необходимо, в то время как слоты репликации оставляют только то количество сегментов, которое необходимо. Преимущество этих методов состоит в том, что они чётко задают объёмы места, необходимого для pg_xlog; в то время как текущая реализация репликационных слотов не представляет такой возможности.»
Как я понимаю, то нет. Данные параметры используются совместно. Эти моменты хорошо описаны на сайте.
Я привёл выдержку из документации на том же сайте, из которой следует что совместно они не используются. Откуда следует, что используются?
Можете посмотреть здесь. Тут точно описано, что они используются вместе.
Как я понимаю, то нет. Данные параметры используются совместно. Эти моменты хорошо описаны на сайте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кластер высокой доступности на postgresql 9.6 + repmgr + pgbouncer + haproxy + keepalived + контроль через telegram