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