Релизы
Помощь

YMatrix

Начало работы

Развёртывание

Использование данных

Управление кластерами

Безопасность

Лучшие практики

Технические принципы

Расширенные функции

Графовая база данных

Руководство

SQL-команда

Часто задаваемые вопросы

Руководство пользователя YMatrix 6.8 по аварийному восстановлению

В этом документе описаны развертывание, проверка, мониторинг, переключение и восстановление функции аварийного восстановления YMatrix 6.8.

Внимание!

Способ развертывания аварийного восстановления в YMatrix 6.8 изменился по сравнению с прежними версиями и не является обратно совместимым. При развертывании и эксплуатации используйте этот документ как основной источник. Не применяйте старую схему, в которой на стороне основного кластера развертывается только Subscriber, а на стороне резервного кластера только Publisher.

1 Описание функции

1.1 Функция аварийного восстановления

Аварийное восстановление (Disaster Recovery, DR) означает способность восстановить доступность и функции IT-инфраструктуры после аварийного события.

В YMatrix аварийное восстановление означает, что при аварии основного кластера YMatrix резервный кластер YMatrix принимает на себя обслуживание приложений, обеспечивая непрерывную доступность данных и сервиса базы данных.

YMatrix 6.8 DR является решением аварийного восстановления на уровне кластера базы данных и имеет следующие характеристики:

  • Репликация данных в реальном времени.
  • Горячее резервное копирование данных.
  • Поддержка развертывания между дата-центрами.
  • Объектом защиты является кластер базы данных YMatrix.

1.2 Основные понятия

Кластер базы данных YMatrix

Кластер с полноценными функциями базы данных, включая компоненты высокой доступности и компоненты базы данных.

Основной кластер

Кластер базы данных YMatrix, который хранит данные, защищаемые DR, и в нормальном режиме предоставляет сервисы базы данных.

Резервный кластер

Кластер базы данных YMatrix, который получает резервные данные из основного кластера и может восстановить и предоставить сервис базы данных после аварии.

Резервный кластер является полноценным кластером YMatrix. В резервной роли он копирует все данные из основного кластера и может выполнять некоторые операции только для чтения. После переключения DR резервный кластер становится обычным сервисным кластером YMatrix.

Внимание!

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

Компоненты DR

Компоненты, реализующие резервное копирование данных основного кластера и переключение сервиса при аварии. Основные компоненты: Subscriber и Publisher.

Subscriber

Компонент DR для подключения к основному кластеру. Он принимает запросы резервного копирования от Publisher на стороне резервного кластера и отправляет их в основной кластер. Он также получает резервные данные из основного кластера и отправляет их Publisher на стороне резервного кластера.

Publisher

Компонент DR для подключения к резервному кластеру. Он принимает запросы резервного копирования на стороне резервного кластера и отправляет их Subscriber на стороне основного кластера. Он также получает резервные данные от Subscriber основного кластера и отправляет их в резервный кластер.

В YMatrix 6.8 для двусторонней передачи между основным и резервным кластерами Subscriber и Publisher должны быть развернуты на обеих сторонах. Subscriber и Publisher одной стороны могут находиться на одном pubsub-хосте. Обычно в один момент времени работает только один из двух компонентов на одной стороне кластера.

2 Подготовка к развертыванию

2.1 Требования к версии, архитектуре и ресурсам

Перед развертыванием убедитесь, что выполнены требования:

  • Версия YMatrix, используемая для развертывания DR, полностью совпадает с версией YMatrix основного кластера.
  • Машины для DR имеют ту же CPU-архитектуру, что и машины основного кластера.
  • Машина Subscriber имеет достаточно памяти. Один поток данных shard в Subscriber использует около 100 MiB памяти.
  • Машина Publisher имеет достаточно памяти. Один поток данных shard в Publisher использует около 200 MiB памяти.
  • В резервной роли резервный кластер потребляет меньше CPU и памяти, но после переключения в обычную сервисную роль его потребление похоже на основной кластер. Ресурсы резервного кластера следует планировать с учетом возможного обслуживания нагрузки основного кластера после переключения.

Внимание!

Оценки памяти на один shard для Subscriber и Publisher основаны на тестировании релизной версии и могут измениться в будущих версиях. Резервируйте ресурсы с учетом фактического числа shard и бизнес-нагрузки.

2.2 Настройка параметров основного кластера

При развертывании DR параметр GUC synchronous_commit основного кластера поддерживает только следующие значения:

  • off
  • local
  • remote_write
  • on, рекомендуется

Не задавайте remote_apply.

На master основного кластера выполните от имени mxadmin:

gpconfig -c synchronous_commit -v <одно из допустимых значений>

Перезагрузите конфигурацию:

mxstop -u

2.3 Проверка matrixmgr

Перед развертыванием на стороне основного кластера убедитесь, что база данных matrixmgr существует и расширение matrixmgr загружено.

Если в поставочной среде есть стандартный скрипт проверки matrixmgr или SQL, выполните проверку согласно локальному стандарту. До подтверждения состояния базы данных и расширения продолжать развертывание не следует.

2.4 Подготовка сети

Следующие инструкции в основном применимы, когда резервный кластер развертывается в другом дата-центре. В других сценариях настройте сеть по фактическому плану.

На стороне основного кластера:

  1. Подготовьте pubsub-хост для Subscriber и Publisher и добавьте его в подсеть основного кластера.
  2. Убедитесь, что pubsub-хост доступен для всех машин основного кластера в этой подсети.
  3. Запишите IP pubsub-хоста в подсети основного кластера как внутренний IP pubsub основного кластера.
  4. Подключите этот pubsub-хост к подсети связи с резервным кластером.
  5. Убедитесь, что он доступен с pubsub-хоста резервного кластера в междатацентровой подсети.
  6. Запишите IP pubsub-хоста в междатацентровой подсети как внешний IP pubsub основного кластера.

На стороне резервного кластера:

  1. Подготовьте pubsub-хост для Subscriber и Publisher и добавьте его в подсеть резервного кластера.
  2. Убедитесь, что pubsub-хост доступен для всех машин, на которых будет развернут резервный кластер.
  3. Запишите IP pubsub-хоста в подсети резервного кластера как внутренний IP pubsub резервного кластера.
  4. Подключите этот pubsub-хост к подсети связи с основным кластером.
  5. Убедитесь, что он доступен с pubsub-хоста основного кластера в междатацентровой подсети.
  6. Запишите IP pubsub-хоста в междатацентровой подсети как внешний IP pubsub резервного кластера.

Для связи между сторонами проверьте:

  • Внешний IP pubsub основного кластера доступен с внешнего IP pubsub резервного кластера.
  • Внутренний IP pubsub каждой стороны доступен со всех узлов базы данных той же стороны.
  • Пропускная способность и задержка сети соответствуют объему данных и требованиям резервного копирования.

3 Развертывание Subscriber и Publisher на стороне основного кластера

В командах этого документа <db_cluster_id>, <COUNT>, <shard_id> и {{...}} являются заполнителями. Замените их фактическими значениями кластера перед выполнением.

3.1 Добавление pubsub-хоста в основной кластер

  1. На pubsub-хосте стороны основного кластера установите ту же версию YMatrix, что и в основном кластере.

  2. На всех узлах основного кластера от имени root настройте /etc/hosts, добавив имя pubsub-хоста с IP стороны основного кластера.

  3. На master основного кластера от имени root создайте каталог конфигурации:

    mkdir ~/pubsub

  4. На master основного кластера от имени root выполните команды, чтобы добавить pubsub-хост в физический кластер:

    # Инициализация expand
/opt/ymatrix/matrixdb6/bin/mxctl expand init    > ~/pubsub/expand.init

# Добавление pubsub-хоста
cat ~/pubsub/expand.init |    /opt/ymatrix/matrixdb6/bin/mxctl expand add --host {{имя pubsub-хоста или IP стороны основного кластера}}    > ~/pubsub/expand.add

# Проверка сетевой связности
cat ~/pubsub/expand.add |    /opt/ymatrix/matrixdb6/bin/mxctl expand netcheck    > ~/pubsub/expand.nc

# Генерация plan
cat ~/pubsub/expand.nc |    /opt/ymatrix/matrixdb6/bin/mxbox deployer expand --physical-cluster-only    > ~/pubsub/expand.plan

# Выполнение plan
cat ~/pubsub/expand.plan |    /opt/ymatrix/matrixdb6/bin/mxbox deployer exec

  5. Отредактируйте pg_hba.conf на всех узлах базы данных основного кластера, включая master, standby, primary и mirror. Перед #user access rules, желательно перед первым правилом не trust, добавьте:

    host        all,replication        mxadmin        {{внутренний IP pubsub основного кластера}}/32        trust

  6. На master основного кластера от имени mxadmin перезагрузите конфигурацию:

    /opt/ymatrix/matrixdb6/bin/mxstop -u

3.2 Настройка и запуск Subscriber на стороне основного кластера

  1. На pubsub-хосте основного кластера от имени root создайте каталог конфигурации:

    mkdir -p /etc/matrixdb6/pubsub

  2. На pubsub-хосте основного кластера от имени root создайте /etc/matrixdb6/pubsub/subscriber.conf:

    # /etc/matrixdb6/pubsub/subscriber.conf
module      = 'subscriber'
perf_port   = 5587 # HTTP-порт диагностики производительности; pprof по умолчанию выключен, см. раздел эксплуатации
verbose     = true # Уровень логирования по необходимости
debug       = false # Уровень логирования по необходимости

[[receiver]]
type                                    = 'db'
cluster_id                              = ''              # cluster_id основного кластера
host                                    = ''              # Имя хоста или IP master основного кластера
port                                    = 4617            # Порт supervisor master основного кластера

# Необязательные параметры: если опущены, используются системные значения по умолчанию
# dbname    = 'template1'
# username  = 'mxadmin'
# restore_point_creation_interval = '60s' # Согласованность данных обеспечивается restore point. По умолчанию 60s.

[[sender]]
type        = 'socket'
port        = 9320    # Порт прослушивания Subscriber

  3. На pubsub-хосте основного кластера от имени root создайте /etc/matrixdb6/service/subscriber_<db_cluster_id>.conf:

    # /etc/matrixdb6/service/subscriber_<db_cluster_id>.conf
[program:subscriber_<db_cluster_id>]
  process_name=subscriber_<db_cluster_id>
  command=%(ENV_MXHOME)s/bin/mxdr -s <COUNT> -c /etc/matrixdb6/pubsub/subscriber.conf
  directory=%(ENV_MXHOME)s/bin
  autostart=true
  autorestart=true
  stopsignal=TERM
  stdout_logfile=%(ENV_MXLOGDIR)s/subscriber_<db_cluster_id>.log
  stdout_logfile_maxbytes=50MB
  stdout_logfile_backups=10
  redirect_stderr=true
  user=mxadmin

<COUNT> — число shard основного кластера. Получить его можно SQL-запросом на master основного кластера:

SELECT count(1) FROM gp_segment_configuration WHERE role='p';

  1. На pubsub-хосте основного кластера от имени root выполните:

    /opt/ymatrix/matrixdb6/bin/supervisorctl update
/opt/ymatrix/matrixdb6/bin/supervisorctl start subscriber_<db_cluster_id>

  2. Проверьте состояние Subscriber:

    /opt/ymatrix/matrixdb6/bin/supervisorctl status

Проверьте, что процесс subscriber_<db_cluster_id> существует, находится в состоянии Running, а журналы supervisor не содержат ошибок.

3.3 Настройка и запуск Publisher на стороне основного кластера

  1. На pubsub-хосте основного кластера от имени root создайте /etc/matrixdb6/pubsub/publisher.conf:

    # /etc/matrixdb6/pubsub/publisher.conf
module      = 'publisher'
perf_port   = 6698 # HTTP-порт диагностики производительности; pprof по умолчанию выключен, см. раздел эксплуатации
verbose     = true # Уровень логирования по необходимости
debug       = false # Уровень логирования по необходимости

[[receiver]]
type        = 'socket'
host        = '<нужно заполнить>' # IP соответствующего Subscriber, то есть внешний IP pubsub резервного кластера
port        = 9320                # Порт прослушивания соответствующего Subscriber

[[sender]]
type        = 'db'
host        = '<нужно заполнить>' # Хост прослушивания Publisher, то есть внутренний IP pubsub основного кластера
listen      = 6432                # Базовый порт Publisher, диапазон зависит от числа shard

# Необязательные параметры: если опущены, используются системные значения по умолчанию
# username  = 'mxadmin'
# dbname    = 'template1'

  2. На pubsub-хосте основного кластера создайте /etc/matrixdb6/service/publisher_<db_cluster_id>.conf:

    # /etc/matrixdb6/service/publisher_<db_cluster_id>.conf
[program:publisher_<db_cluster_id>]
  process_name=publisher_<db_cluster_id>
  command=%(ENV_MXHOME)s/bin/mxdr -s <COUNT> -c /etc/matrixdb6/pubsub/publisher.conf
  directory=%(ENV_MXHOME)s/bin
  autostart=true
  autorestart=true
  stopsignal=TERM
  stdout_logfile=%(ENV_MXLOGDIR)s/publisher_<db_cluster_id>.log
  stdout_logfile_maxbytes=50MB
  stdout_logfile_backups=10
  redirect_stderr=true
  user=mxadmin

  3. Выполните:

    /opt/ymatrix/matrixdb6/bin/supervisorctl update
/opt/ymatrix/matrixdb6/bin/supervisorctl start publisher_<db_cluster_id>

  4. Проверьте состояние Publisher:

    /opt/ymatrix/matrixdb6/bin/supervisorctl status

Убедитесь, что процесс publisher_<db_cluster_id> существует, находится в состоянии Running, а журналы не содержат ошибок.

4 Развертывание Subscriber, Publisher и резервного кластера на стороне резервного кластера

4.1 Подготовка машин резервного кластера и каталога pubsub

  1. На pubsub-хосте резервного кластера и машинах резервного кластера установите ту же версию YMatrix, что и на основном кластере, и установите зависимости. Подготовка аналогична развертыванию основного кластера.

  2. На pubsub-хосте резервного кластера от имени root создайте каталог конфигурации:

    mkdir -p /etc/matrixdb6/pubsub

  3. Создайте рабочий каталог:

    mkdir ~/pubsub

4.2 Генерация и изменение mapping-конфигурации

Mapping-конфигурация задает соответствие shard основного кластера primary-экземплярам резервного кластера.

  1. На master основного кластера от имени mxadmin выполните SQL, чтобы создать шаблон /tmp/mapping.tmp:

    COPY (
SELECT content, hostname, port, datadir
FROM gp_segment_configuration
WHERE role='p'
ORDER BY content
) TO '/tmp/mapping.tmp' DELIMITER '|';

  2. Измените созданный файл:

  • Первый столбец — content id основного кластера, его менять не нужно.
  • Последние три столбца — информация резервного кластера, их нужно изменить по фактической среде.
  • Последние три столбца обозначают имя хоста primary резервного кластера, порт primary и каталог данных.

  1. Просмотреть описание конфигурации можно командой:

    mxbox deployer dr pub config

  2. После изменения перенесите файл в каталог ~/pubsub пользователя root на машине Publisher резервного кластера и используйте как mapping.conf.

4.3 Создание конфигурации Publisher на стороне резервного кластера

На pubsub-хосте резервного кластера от имени root создайте /etc/matrixdb6/pubsub/publisher.conf:

# /etc/matrixdb6/pubsub/publisher.conf
module      = 'publisher'
perf_port   = 6698 # HTTP-порт диагностики производительности; pprof по умолчанию выключен, см. раздел эксплуатации
verbose     = true # Уровень логирования по необходимости
debug       = false # Уровень логирования по необходимости

[[receiver]]
type        = 'socket'
host        = '<нужно заполнить>' # IP соответствующего Subscriber, то есть внешний IP pubsub основного кластера
port        = 9320                # Порт прослушивания соответствующего Subscriber

[[sender]]
type        = 'db'
host        = '<нужно заполнить>' # Хост прослушивания Publisher, то есть внутренний IP pubsub резервного кластера
listen      = 6432                # Базовый порт Publisher, диапазон зависит от числа shard

# Необязательные параметры: если опущены, используются системные значения по умолчанию
# username  = 'mxadmin'
# dbname    = 'template1'

4.4 Создание конфигурации Subscriber на стороне резервного кластера

На pubsub-хосте резервного кластера от имени root создайте /etc/matrixdb6/pubsub/subscriber.conf:

# /etc/matrixdb6/pubsub/subscriber.conf
module      = 'subscriber'
perf_port   = 5587 # HTTP-порт диагностики производительности; pprof по умолчанию выключен, см. раздел эксплуатации
verbose     = true # Уровень логирования по необходимости
debug       = false # Уровень логирования по необходимости

[[receiver]]
type                                    = 'db'
cluster_id                              = ''              # cluster_id резервного кластера; здесь можно оставить пустым
host                                    = '<нужно заполнить>' # Имя хоста или IP master резервного кластера
port                                    = 4617            # Порт supervisor master резервного кластера

# Необязательные параметры: если опущены, используются системные значения по умолчанию
# dbname    = 'template1'
# username  = 'mxadmin'
# restore_point_creation_interval = '60s' # Согласованность данных обеспечивается restore point. По умолчанию 60s.

[[sender]]
type        = 'socket'
port        = 9320    # Порт прослушивания Subscriber

4.5 Развертывание резервного кластера и запуск резервного копирования

Следующие команды выполняются на pubsub-хосте резервного кластера от имени root.

  1. Соберите информацию о машинах pubsub, master и segment:

    # Сбор информации о pubsub-машине
/opt/ymatrix/matrixdb6/bin/mxctl setup collect --host localhost > ~/pubsub/collect.0

# Сбор информации о master
cat ~/pubsub/collect.0 |    /opt/ymatrix/matrixdb6/bin/mxctl setup collect --host {{IP машины master резервного кластера}}    > ~/pubsub/collect.1

# Сбор информации о других segment-машинах
cat ~/pubsub/collect.1 |    /opt/ymatrix/matrixdb6/bin/mxctl setup collect --host {{IP другой машины резервного кластера}}    > ~/pubsub/collect.2

...

# Сбор информации о других segment-машинах
cat ~/pubsub/collect.n-1 |    /opt/ymatrix/matrixdb6/bin/mxctl setup collect --host {{IP другой машины резервного кластера}}    > ~/pubsub/collect.n

  2. Выполните проверку сетевой связности:

    cat ~/pubsub/collect.n |    /opt/ymatrix/matrixdb6/bin/mxctl setup netcheck    > ~/pubsub/plan.nc

  3. Сгенерируйте план развертывания:

    /opt/ymatrix/matrixdb6/bin/mxbox deployer dr pub plan    --wait    --collect-file ~/pubsub/plan.nc    --mapping-file ~/pubsub/mapping.conf    --publisher-file /etc/matrixdb6/pubsub/publisher.conf    --subscriber-file /etc/matrixdb6/pubsub/subscriber.conf    > ~/pubsub/plan

Если на стороне резервного кластера нужно развернуть дополнительные mirror-копии, добавьте в команду plan параметр --with-mirror. При использовании этого параметра резервный кластер будет развернут со standby и mirror.

  1. Выполните план развертывания:

    /opt/ymatrix/matrixdb6/bin/mxbox deployer dr pub setup    --plan-file ~/pubsub/plan

Этот шаг развертывает Subscriber, Publisher и резервный кластер, подключает Publisher и запускает резервное копирование.

5 Проверка результата развертывания

5.1 Проверка ключевых процессов

5.1.1 Проверка walsender основного кластера

На каждой машине primary основного кластера выполните от имени root:

ps aux | grep postgres | grep walsender

Должен существовать процесс, подключенный к Subscriber, в состоянии streaming.

5.1.2 Проверка Subscriber и Publisher на стороне основного кластера

На pubsub-хосте основного кластера выполните от имени mxadmin:

/opt/ymatrix/matrixdb6/bin/supervisorctl status

Должны существовать процессы subscriber_<db_cluster_id> и publisher_<db_cluster_id> в состоянии Running. Проверьте журналы на отсутствие ошибок.

5.1.3 Проверка Subscriber и Publisher на стороне резервного кластера

На pubsub-хосте резервного кластера выполните от имени mxadmin:

/opt/ymatrix/matrixdb6/bin/supervisorctl status

Должны существовать процессы subscriber_<db_cluster_id> и publisher_<db_cluster_id> в состоянии Running. Проверьте журналы на отсутствие ошибок.

5.1.4 Проверка walreceiver резервного кластера

На каждой машине резервного кластера выполните от имени root:

ps aux | grep postgres | grep walreceiver

Должны существовать процессы, подключенные к Subscriber, в состоянии streaming. Общее число walreceiver-процессов, подключенных к Publisher в резервном кластере, должно совпадать с числом shard исходного кластера.

5.1.5 Дополнительно: проверка внутренних процессов репликации резервного кластера

Если резервный кластер развернут со standby и mirror, репликация master-to-standby и primary-to-mirror внутри резервного кластера также использует walsender и walreceiver.

На каждой машине резервного кластера выполните от имени root:

ps aux | grep postgres | grep walsender
ps aux | grep postgres | grep walreceiver

Убедитесь, что соответствующие процессы walsender и walreceiver существуют, и проверьте связи репликации master-to-standby и primary-to-mirror согласно плану развертывания.

5.2 Проверка синхронизации данных

  1. Подключитесь к master основного и резервного кластера и выполните от пользователя с правом запроса:

    SELECT * FROM gp_segment_configuration ORDER BY content, dbid;

Сравните результаты.

  1. Подключитесь к master основного кластера и создайте тестовую базу:

    CREATE DATABASE test_dr;

  2. Подключитесь к базе test_dr основного кластера и создайте таблицу:

    CREATE TABLE test_1(c int) DISTRIBUTED BY (c);

  3. Вставьте данные:

    INSERT INTO test_1 SELECT * FROM generate_series(0,999);

  4. Подключитесь к базе test_dr основного и резервного кластера и выполните:

    SELECT gp_segment_id, count(1) FROM test_1 GROUP BY gp_segment_id;

Сравните результаты.

5.3 Наблюдение применения restore point

restore_point_creation_interval задает интервал создания restore point, по умолчанию 60s. При анализе журналов оценивайте интервал по явному значению или значению по умолчанию. Во время наблюдения можно продолжать вставлять данные в базу.

  1. Проверьте записи создания global restore point в журнале Subscriber.

Путь к журналу соответствует stdout_logfile в /etc/matrixdb6/service/subscriber_<db_cluster_id>.conf. Выполните:

grep "Created global restore point" <subscriber_log_file>

Должен быть вывод, а интервал записей должен совпадать с настроенным интервалом restore point.

  1. В каталоге log каждого primary основного кластера проверьте записи создания restore point:

    grep "restore point" *.csv | grep "created at"

Должен быть вывод, показывающий, что основной кластер периодически создает restore point под управлением Subscriber.

  1. В каталоге log master резервного кластера проверьте записи воспроизведения WAL до restore point:

    grep "cluster wide WAL replayed to global restore point" *.csv

Должен быть вывод, показывающий, что резервный кластер воспроизвел WAL до restore point.

  1. Проверьте прогресс воспроизведения WAL на резервном кластере. Подключитесь к master и каждому primary резервного кластера в utility mode с PGOPTIONS='-c gp_role=utility' и выполните на каждом экземпляре:

    SHOW mx_redo_stop_pit;
SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();

Ожидаемые результаты:

  • pg_last_wal_replay_lsn всегда меньше или равен mx_redo_stop_pit.
  • pg_last_wal_receive_lsn больше или равен mx_redo_stop_pit.

Это означает, что резервный кластер через Subscriber и Publisher получил restore point, созданный основным кластером, и он вступил в силу.

6 Операционный мониторинг

6.1 Просмотр состояния через SQL

System catalog основного кластера:

  • pg_catalog.gp_replication_slots
  • pg_catalog.gp_stat_replication

Имя replication slot, используемого DR:

internal_disaster_recovery_rep_slot

На основном кластере выполните запрос replication slot от пользователя с нужными правами, например mxadmin:

SELECT *
FROM pg_catalog.gp_replication_slots
WHERE slot_name = 'internal_disaster_recovery_rep_slot'
ORDER BY gp_segment_id;

Запрос состояния replication:

SELECT *
FROM
    pg_catalog.gp_replication_slots s
LEFT JOIN
    pg_catalog.gp_stat_replication r
ON
    s.gp_segment_id = r.gp_segment_id AND s.active_pid = r.pid
WHERE s.slot_name = 'internal_disaster_recovery_rep_slot'
ORDER BY s.gp_segment_id;

System catalog резервного кластера:

  • pg_catalog.gp_stat_wal_receiver

На резервном кластере выполните запрос состояния walreceiver от пользователя с нужными правами, например mxadmin:

SELECT *
FROM pg_catalog.gp_stat_wal_receiver
WHERE slot_name = 'internal_disaster_recovery_rep_slot'
ORDER BY gp_segment_id;

7 Дополнительные операции

7.1 Динамическое включение и выключение pprof

Диагностический интерфейс Subscriber и Publisher слушает порт perf_port, но путь pprof по умолчанию выключен.

На машине Subscriber или Publisher отправьте целевому процессу SIGUSR2, чтобы включить или выключить /debug/pprof:

kill -USR2 <pid>

Правила переключения:

  • Первый SIGUSR2: включает /debug/pprof.
  • Второй SIGUSR2: выключает /debug/pprof.

Примеры доступа:

  • Subscriber: http://<host>:5587/debug/pprof/
  • Publisher: http://<host>:6698/debug/pprof/

Внимание!

Рекомендуется включать pprof только временно при диагностике. Не оставляйте диагностический интерфейс открытым постоянно.

7.2 Обработка отказов внутренних копий резервного кластера

В этом разделе описана обработка отказов внутренних копий резервного кластера, когда резервный кластер все еще работает как DR-кластер. Цель — сохранить способность непрерывно получать и воспроизводить WAL из основного кластера.

Примеры команд выполняются на master резервного кластера от имени mxadmin. Если локальный стандарт поставки требует иного порядка, следуйте ему.

Команда Назначение
mxdr failover Если каталог данных текущего DR master или DR primary необратимо поврежден и не может продолжать резервное копирование, повышает standby или mirror того же shard до нового DR master или DR primary.
mxdr rebuild Перестраивает standby или mirror из текущей здоровой копии, если каталог данных поврежден, либо после восстановления старого master или primary после failover.
mxdr rebalance После failover и rebuild восстанавливает распределение ролей согласно плану, если текущие роли отличаются от preferred role и состояние кластера OK_UNBALANCED.

7.2.1 Процесс аварийный, но каталог данных доступен

Авария DR primary или DR master влияет на прием и воспроизведение WAL соответствующего shard и может вызвать накопление WAL на стороне основного кластера, поэтому ее нужно восстанавливать в первую очередь. Авария DR mirror или DR standby обычно не влияет на текущую синхронизацию, но снижает внутреннюю высокую доступность резервного кластера.

Если процесс DR primary, DR mirror, DR master или DR standby завершился аварийно, но каталог данных доступен, сначала перезапустите кластер через mxstop и mxstart:

# Остановить кластер
mxstop -a -f

# Запустить кластер
mxstart -a

7.2.2 Данные DR mirror или DR standby невосстановимы

Если файлы DR mirror или DR standby повреждены и не восстанавливаются перезапуском, но текущий DR primary или DR master исправен, выполните mxdr rebuild, чтобы перестроить копию из здорового primary или master:

# Выполнить mxdr rebuild для восстановления поврежденного mirror или standby
mxdr rebuild -s <shard_id>

7.2.3 Данные DR primary невосстановимы

Если каталог данных DR primary поврежден и больше не может принимать и воспроизводить WAL, сначала остановите резервный кластер, выполните mxdr failover, чтобы mirror того же shard временно принял синхронизацию, затем после восстановления primary выполните mxdr rebuild. Если кластер перейдет в OK_UNBALANCED, выполните mxdr rebalance. Этот порядок также применим, если невосстановим каталог данных DR master.

# Остановить кластер
mxstop -a

# Выполнить mxdr failover, чтобы резервная копия временно приняла роль
mxdr failover -s <shard_id>

# Запустить кластер
mxstart -a

# Выполнить mxdr rebuild для восстановления отказавшей копии
mxdr rebuild -s <shard_id>

# Выполнить mxdr rebalance для восстановления ролей
mxdr rebalance

7.3 Переключение основного и резервного кластера при аварии

7.3.1 Предпосылки и место выполнения

Этот раздел применим, когда все машины стороны основного кластера физически недоступны. В этом случае операции выполняются только на стороне резервного кластера.

Переключение повышает резервный кластер до обычного сервисного кластера. Перед переключением убедитесь, что сервис базы данных действительно должен быть принят резервным кластером.

7.3.2 Выполнение mxdr switch

На master резервного кластера выполните от имени mxadmin:

mxdr switch

Во время выполнения команда запросит подтверждение:

Continue promoting cluster for disaster recovery to normal cluster? Yy|Nn (default=N):

Можно добавить -a, чтобы пропустить подтверждение:

mxdr switch -a

7.3.3 Дополнительно: остановка Publisher и Subscriber

После переключения на машине Publisher выполните от имени mxadmin:

/opt/ymatrix/matrixdb6/bin/supervisorctl status

Получите имя Publisher под управлением supervisor, например publisher_<db_cluster_id>.

Остановите Publisher:

/opt/ymatrix/matrixdb6/bin/supervisorctl stop publisher_<db_cluster_id>

Проверьте состояние снова:

/opt/ymatrix/matrixdb6/bin/supervisorctl status

Убедитесь, что Publisher перешел в состояние exited.

Subscriber можно также остановить тем же способом.

7.4 Восстановление исходного основного кластера после переключения

7.4.1 Сценарий использования mxdr recover

После того как резервный кластер был повышен до обычного сервисного кластера через mxdr switch, если среда исходного основного кластера восстановлена и требуется снова включить его в DR-связь как кластер, синхронизируемый с новым основным кластером, используйте mxdr recover.

При использовании mxdr recover данные исходного основного кластера должны оставаться доступными, а состояние кластера должно быть восстанавливаемым до полностью нормального.

Когда исходный основной кластер понижается до кластера, синхронизируемого из другого кластера, правила pg_hba.conf на каждом узле базы данных сбрасываются к состоянию после инициализации кластера. Если пользователь вручную настраивал правила pg_hba.conf на master, после завершения понижения настройте их снова.

7.4.2 Предварительные условия и шаги

Формат команды:

mxdr recover [-a]

Параметр:

  • -a, --no-prompt: пропустить подтверждение. Если параметр не указан, команда спросит, преобразовать ли обычный кластер для синхронизации с его DR-кластером.

Перед выполнением убедитесь, что:

  1. Текущий кластер не является DR-кластером. Команда выполняется на стороне исходного основного кластера; если текущий кластер все еще в роли DR, команда откажется выполняться.
  2. Состояние текущего кластера — Dead. Если состояние не Dead, ошибка команды попросит сначала выполнить mxstop -a -f.
  3. Текущий кластер находится в balanced-состоянии. Если кластер unbalanced, сначала устраните проблему распределения ролей.

Шаги:

  1. Восстановите среду исходного основного кластера так, чтобы она соответствовала требованиям mxdr recover.
  2. Выполните mxdr recover на исходном основном кластере.

Чтобы пропустить подтверждение:

mxdr recover -a

7.5 Использование кластера после переключения

После переключения DR резервный кластер YMatrix переходит в обычную сервисную роль. Его использование не отличается от обычного кластера YMatrix. Приложения могут переключить подключения к этому кластеру и продолжить обслуживание.

8 Справочник команд

8.1 mxdr

mxdr используется для запуска Subscriber и Publisher, а также для управления переключением резервного кластера.

Tools for MatrixDB stream replication.

Usage:
  mxdr [flags]
  mxdr [command]

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  failover    Fail over within disaster recovery cluster
  help        Help about any command
  rebalance   Rebalance disaster recovery cluster
  rebuild     Rebuild old primary or master after disaster recovery failover
  recover     Convert a normal cluster to synchronize with its DR cluster
  switch      Promote disaster recovery cluster

Flags:
  -c, --config-file string   path of the configuration file to start up
  -h, --help                 help for mxdr
  -s, --shard-cnt int        number of shards of the source database cluster
  -v, --version              version for mxdr

Use "mxdr [command] --help" for more information about a command.

Полные параметры подкоманды можно посмотреть так:

mxdr <command> --help

8.2 mxbox deployer dr

mxbox deployer dr используется для развертывания компонентов DR и резервного кластера.

Disaster recovery deployer

Usage:
  mxbox deployer dr [command]

Available Commands:
  pub         Publisher deployer for dr

Flags:
  -h, --help   help for dr

Use "mxbox deployer dr [command] --help" for more information about a command.

mxbox deployer dr pub используется для развертывания Publisher, Subscriber и резервного кластера.

Publisher deployer for dr

Usage:
  mxbox deployer dr pub [command]

Available Commands:
  config      Generate a config template file
  plan        Generate plan for migrating host.
  setup       Execute steps to deploy physical publisher.

Flags:
  -h, --help   help for pub

Use "mxbox deployer dr pub [command] --help" for more information about a command.

Полную справку можно посмотреть командами:

mxbox deployer dr --help
mxbox deployer dr pub --help
mxbox deployer dr pub <command> --help

9 Известные проблемы

9.1 Не поддерживается расширение кластера с добавлением shard

В настоящее время DR не поддерживает изменение топологии кластера базы данных, поэтому расширение кластера с добавлением shard не поддерживается.

9.2 tablespace не поддерживается

Не используйте tablespace в кластерах, где требуется включить DR.

9.3 Результаты запросов только для чтения на резервном кластере не гарантированно согласованы в произвольный момент времени

Согласованность данных резервного кластера действительна только в глобальных точках согласованности.

Когда резервный кластер выполняет переключение после аварии, он переключается к глобальной точке согласованности, чтобы обеспечить итоговую согласованность резервных данных.

Во время резервного копирования резервный кластер поддерживает запросы только для чтения. Однако, поскольку синхронизация воспроизведения WAL по шардам контролируется только на уровне глобальных точек согласованности, корректность результатов запросов в произвольный момент времени не гарантируется.

← Предыдущая
Обзор
Следующая →
Обзор