Резервное копирование компонентов Платформы
В этом разделе описан процесс резервного копирования компонентов Платформы, что необходимо для обеспечения бесперебойной работы системы в случае отказа одного из серверов.
Резервное копирование компонентов происходит с помощью программно-технических решений и настраивается на подготовительном этапе. Резервируются следующие компоненты:
компоненты сервера приложений (frontend, backend, pg-explain, pg_configurator);
компоненты сервера NATS;
компоненты баз данных (operdb, tensordb).
Резервирование сервера приложений происходит путём дублирования основных компонентов (frontend, backend, pg-explain, pg_configurator) и соответствующей настройки утилиты NGINX, выступающей в качестве reverse proxy, то есть посредником между клиентом и сервером. В случае отказа одного из физических серверов все запросы перенаправляются на работающий сервер. Все сессии, которые были на отказавшем сервере, считаются незавершёнными и отклоняются. Все дальнейшие сессии поступают к рабочему серверу. При восстановлении работоспособности вышедшего из строя узла дополнительных действий со стороны пользователя не требуется - восстановление служб и включение сервера для принятия запросов происходит при помощи NGINX в автоматическом режиме.
При количестве узлов более 3 (рекомендуется использовать нечётное число, равное или превосходящее 3) компоненты сервиса NATS объединяются в кластер. Каждый узел осведомлён о соседних узлах. При количестве узлов, равном 3, неисправность одного узла не ведёт к общей деградации сервиса. После восстановления неработоспособного узла происходит автоматическое добавление этого узла в кластер. После восстановления узла и включения службы дополнительных действий со стороны пользователя не требуется - NATS будет добавлен в кластер и продолжит работу в штатном режиме.
Компоненты баз данных (operdb, tensordb) работают в режиме репликации (master-replica). Платформа не поддерживает установку продвинутых решений для оркестрации PostgreSQL и обеспечения высокой доступности (auto-failower) кластеров конфигурации Leader-Followers. Отказ узла, имеющего роль master, приводит к переводу БД в режим чтения (read-only). В данном режиме СУБД будет отвечать только на читающие запросы и не будет принимать новые транзакции. В случае аварии необходимо:
ручное повышение роли реплицирующего узла до уровня мастера;
восстановление работоспособности master-узла с последующей настройкой его в качестве реплицирующего узла.
Для выполнения пунктов a и b, находящихся выше, воспользуйтесь следующими командами:
на узле, являющемся репликацией, сделайте повышение приоритета до мастера (замените <PGDATA_folder> на путь к каталогу данных PostgreSQL, содержащему файл конфигурации postgresql.conf и подкаталоги баз данных и журналов):
su - postgres pg_ctl promote -D <PGDATA_folder>
на репликации добавьте в файл pg_hba.conf строку, разрешающую подключения пользователя replicator с отключённого мастер-сервера (замените <old_postgresql_master_ip> на IP-адрес отключённого мастер-сервера PostgreSQL):
host replication replicator <old_postgresql_master_ip>/32 md5
на узле, который был мастер-сервером, создайте файл .pgpass, содержащий информацию о доступе к серверу баз данных PostgreSQL в формате хост:порт:база_данных:пользователь:пароль (замените <new_postgresql_master_ip> на IP-адрес нового мастер-сервера PostgreSQL):
vim /var/lib/postgresql/.pgpass <new_postgresql_master_ip>:5432:replication:replicator:password
на бывшем мастер-сервере смените права для файла .pgpass:
chmod 0600 /var/lib/postgresql/.pgpass chown postgres:postgres /var/lib/postgresql/.pgpass
на узле, который был мастером запустите pg_basebackup (замените <new_postgresql_master_ip> на IP-адрес нового мастер-сервера PostgreSQL):
su - postgres # для БД operdb pg_basebackup -h <new_postgresql_master_ip> -p 5432 \ -D <PGDATA_folder> \ -U replicator \ -P -v -w -R \ -X stream \ -C \ -S operdb_1 # для БД tensordb /opt/tantor/db/15/bin/pg_basebackup -h <new_postgresql_master_ip> -p 5432 \ -D <PGDATA_folder> \ -U replicator \ -P -v -w -R \ -X stream \ -C \ -S tensordb_1