[PostgreSQL] Автоматический failover базы данных Moodle в PostgreSQL с помощью ClusterControl (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Один из ключевых моментов в обеспечении высокой доступности — быстрая реакция на сбой. Хотя нередко можно встретить ручное управление базами данных и систему мониторинга, которая следит за их состоянием и отправляет предупреждения дежурному персоналу. А это означает, что кому-то, возможно, придется проснуться среди ночи, добраться до компьютера, войти в систему и посмотреть логи — то есть до начала восстановления может пройти довольно много времени. В идеале весь этот процесс должен быть автоматизирован.В этой статье мы рассмотрим, как развернуть полностью автоматизированную систему, которая детектируют отказ первичной базы данных, и инициирует failover, изменяя роль (promote) вторичной базы данных. Для реализации автоматического failover базы данных Moodle PostgreSQL мы будем использовать ClusterControl.Преимущество автоматического failover
- Уменьшается время на восстановление базы данных
- Увеличивается время uptime
- Уменьшается зависимость от DBA или администраторов, настраивающих высокую доступность баз данных
Архитектура
На текущий момент у нас есть один первичный сервер Postgres и два вторичных — все за балансировщиком нагрузки HAProxy, который отправляет трафик Moodle на первичный узел PostgreSQL. Для настройки автоматического failover в ClusterControl есть важные параметры восстановления кластера (cluster recovery) и узла (node auto recovery).
На какой сервер переключатьсяВ ClusterControl есть белый и черный списки серверов, с помощью которых вы можете настраивать участие в failover.В конфигурации cmon это две переменные:
- replication_failover_whitelist — список IP-адресов или имен вторичных серверов, которые должны использоваться в качестве потенциальных кандидатов на роль первичного сервера. Если эта переменная установлена, то будут рассматриваться только эти хосты.
- replication_failover_blacklist — список хостов, которые никогда не будут рассматриваться в качестве кандидата на роль первичного сервера. Вы можете использовать этот список для указания вторичных серверов, которые используются для резервного копирования или аналитических запросов. Если аппаратная конфигурации вторичных серверов отличаются, то здесь вы можете указать более медленные сервера.
Процесс автофайловера (auto failover)Шаг 1Начинаем загрузку данных на первичном сервере (192.168.33.14) с помощью sysbench.
[root@centos11 sysbench]# /bin/sysbench --db-driver=pgsql --oltp-table-size=100000 --oltp-tables-count=24 --threads=2 --pgsql-host=****** --pgsql-port=6543 --pgsql-user=sbtest --pgsql-password=***** --pgsql-db=sbtest /usr/share/sysbench/tests/include/oltp_legacy/parallel_prepare.lua run
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)
Running the test with following options:
Number of threads: 2
Initializing random number generator from current time
Initializing worker threads...
Threads started!
thread prepare0
Creating table 'sbtest1'...
Inserting 100000 records into 'sbtest1'
Creating secondary indexes on 'sbtest1'...
Creating table 'sbtest2'...
Шаг 2После этого остановим первичный сервер Postgres (192.168.33.14). Так как в ClusterControl включен параметр enable_cluster_autorecovery, то на роль первичного будет выбран первый подходящий сервер.
# service postgresql-12 stop
Шаг 3ClusterControl обнаружит сбой в работе первичного узла и переключит один из вторичных серверов на роль первичного. Также он изменит настройки на других вторичных серверах таким образом, чтобы они реплицировались с нового первичного сервера.
В нашем случае 192.168.33.13 становится новым первичным сервером, а вторичные сервера теперь реплицируются с него. И HAProxy направляет трафик базы данных с серверов Moodle на новый первичный сервер. 
Запуск на 192.168.33.13
postgres=# select pg_is_in_recovery();
pg_is_in_recovery
-------------------
f
(1 row)
Запуск на 192.168.33.15
postgres=# select pg_is_in_recovery();
pg_is_in_recovery
-------------------
t
(1 row)
Текущая топология
HAProxy автоматически обнаруживает недоступность узлов и перестает отправлять на него трафик. Эта проверка выполняется сценариями проверки работоспособности, которые настраиваются во время развертывания ClusterControl.После того как ClusterControl повысит роль вторичного сервера до первичного, HAProxy помечает, что старый первичный сервер в оффлайне и переводит новый первичный узел в онлайн.Когда старый первичный сервер снова заработает, то он не синхронизируется автоматически с новым первичным сервером. Мы должны вернуть его обратно в топологию и сделать это можно через интерфейс ClusterControl. Это позволит избежать потери или несогласованности данных, например, если нужно выяснить причину выхода из строя сервера.
ClusterControl передаст резервную копию с нового первичного сервера и настроит репликацию.ЗаключениеАвтоматический failover — важная часть любой продуктивной базы Moodle. Благодаря ему можно сократить время простоя при отказе сервера, а также при выполнении задач по обслуживанию и миграции. Важно все настроить правильно, чтобы программное обеспечение автоматического failover могло принять правильные решения.
Перевод статьи подготовлен в преддверии старта курса "PostgreSQL".Также приглашаем всех желающих на демо-урок «Проблемы миграции данных». В рамках урока:
— поговорим о видах миграции и способах их реализации;
— разберем основные проблемы, связанные с миграцией данных и пути их устранения;
— рассмотрим несколько реальных практических кейсов и порассуждаем над эффективностью их решения;
— вспомним программные средства, позволяющие автоматизировать процесс миграции данных. ЗАПИСАТЬСЯ НА ВЕБИНАР
===========
Источник:
habr.com
===========
===========
Автор оригинала: Pon Suresh Pandian
===========Похожие новости:
- [Программирование, Java] Java: передача параметров по значению или по ссылке (перевод)
- [Настройка Linux, Информационная безопасность] Настройка уязвимых машин через Vagrant
- [Информационная безопасность, PostgreSQL, Администрирование баз данных] Обеспечение безопасности базы данных PostgreSQL (перевод)
- [Разработка мобильных приложений, Управление продуктом] Как сократить стоимость мобильной разработки
- [Настройка Linux, Сетевые технологии] Настройка сетевого стека Linux для высоконагруженных систем (перевод)
- [PostgreSQL] Postgresso 30
- [Программирование, Алгоритмы, Интервью] Архитектор современных алгоритмов (перевод)
- [Программирование микроконтроллеров, Интернет вещей] 10 плат для начала разработки IoT в 2021 (перевод)
- [Тестирование IT-систем, Gradle] Запускаем Gatling из Gradle — Полное руководство для начинающих (перевод)
- [Информационная безопасность, Софт] Детектирование эксплуатации уязвимостей в ОС
Теги для поиска: #_postgresql, #_clustercontrol, #_postgresql, #_migratsija_dannyh (миграция данных), #_blog_kompanii_otus (
Блог компании OTUS
), #_postgresql
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:53
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Один из ключевых моментов в обеспечении высокой доступности — быстрая реакция на сбой. Хотя нередко можно встретить ручное управление базами данных и систему мониторинга, которая следит за их состоянием и отправляет предупреждения дежурному персоналу. А это означает, что кому-то, возможно, придется проснуться среди ночи, добраться до компьютера, войти в систему и посмотреть логи — то есть до начала восстановления может пройти довольно много времени. В идеале весь этот процесс должен быть автоматизирован.В этой статье мы рассмотрим, как развернуть полностью автоматизированную систему, которая детектируют отказ первичной базы данных, и инициирует failover, изменяя роль (promote) вторичной базы данных. Для реализации автоматического failover базы данных Moodle PostgreSQL мы будем использовать ClusterControl.Преимущество автоматического failover
 На текущий момент у нас есть один первичный сервер Postgres и два вторичных — все за балансировщиком нагрузки HAProxy, который отправляет трафик Moodle на первичный узел PostgreSQL. Для настройки автоматического failover в ClusterControl есть важные параметры восстановления кластера (cluster recovery) и узла (node auto recovery).  На какой сервер переключатьсяВ ClusterControl есть белый и черный списки серверов, с помощью которых вы можете настраивать участие в failover.В конфигурации cmon это две переменные:
[root@centos11 sysbench]# /bin/sysbench --db-driver=pgsql --oltp-table-size=100000 --oltp-tables-count=24 --threads=2 --pgsql-host=****** --pgsql-port=6543 --pgsql-user=sbtest --pgsql-password=***** --pgsql-db=sbtest /usr/share/sysbench/tests/include/oltp_legacy/parallel_prepare.lua run
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2) Running the test with following options: Number of threads: 2 Initializing random number generator from current time Initializing worker threads... Threads started! thread prepare0 Creating table 'sbtest1'... Inserting 100000 records into 'sbtest1' Creating secondary indexes on 'sbtest1'... Creating table 'sbtest2'...  Шаг 2После этого остановим первичный сервер Postgres (192.168.33.14). Так как в ClusterControl включен параметр enable_cluster_autorecovery, то на роль первичного будет выбран первый подходящий сервер. # service postgresql-12 stop
 В нашем случае 192.168.33.13 становится новым первичным сервером, а вторичные сервера теперь реплицируются с него. И HAProxy направляет трафик базы данных с серверов Moodle на новый первичный сервер.  Запуск на 192.168.33.13 postgres=# select pg_is_in_recovery();
pg_is_in_recovery ------------------- f (1 row) postgres=# select pg_is_in_recovery();
pg_is_in_recovery ------------------- t (1 row)  HAProxy автоматически обнаруживает недоступность узлов и перестает отправлять на него трафик. Эта проверка выполняется сценариями проверки работоспособности, которые настраиваются во время развертывания ClusterControl.После того как ClusterControl повысит роль вторичного сервера до первичного, HAProxy помечает, что старый первичный сервер в оффлайне и переводит новый первичный узел в онлайн.Когда старый первичный сервер снова заработает, то он не синхронизируется автоматически с новым первичным сервером. Мы должны вернуть его обратно в топологию и сделать это можно через интерфейс ClusterControl. Это позволит избежать потери или несогласованности данных, например, если нужно выяснить причину выхода из строя сервера.   ClusterControl передаст резервную копию с нового первичного сервера и настроит репликацию.ЗаключениеАвтоматический failover — важная часть любой продуктивной базы Moodle. Благодаря ему можно сократить время простоя при отказе сервера, а также при выполнении задач по обслуживанию и миграции. Важно все настроить правильно, чтобы программное обеспечение автоматического failover могло принять правильные решения. Перевод статьи подготовлен в преддверии старта курса "PostgreSQL".Также приглашаем всех желающих на демо-урок «Проблемы миграции данных». В рамках урока:
— поговорим о видах миграции и способах их реализации; — разберем основные проблемы, связанные с миграцией данных и пути их устранения; — рассмотрим несколько реальных практических кейсов и порассуждаем над эффективностью их решения; — вспомним программные средства, позволяющие автоматизировать процесс миграции данных. ЗАПИСАТЬСЯ НА ВЕБИНАР =========== Источник: habr.com =========== =========== Автор оригинала: Pon Suresh Pandian ===========Похожие новости:
Блог компании OTUS ), #_postgresql |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:53
Часовой пояс: UTC + 5