Настройка Active/Passive кластера PostgreSQL с Pacemaker, Corosync и DRBD

Краткие определения

• DRBD — блочный репликатор для синхронизации дисков между серверами (репликация на уровне блоков).
• Pacemaker — менеджер ресурсов кластера (управляет запуском/остановкой сервисов и фейловером).
• Corosync — транспорт/механизм доставки сообщений и согласования кворума для Pacemaker.
• Primary/Secondary — роли DRBD: Primary = чтение/запись на локальном узле, Secondary = реплика только для чтения или ожидания повышения.

Содержание

• Конфигурация DRBD
• Создание метаданных и начальная синхронизация
• Форматирование и подготовка PostgreSQL на Primary
• Тестирование запуска PostgreSQL на Secondary
• Отключение сервисов перед настройкой кластера
• Контрольные списки, критерии приёмки и отладка

4. Конфигурация DRBD

Сначала нужно настроить /etc/drbd.conf на обоих узлах. Откройте файл в редакторе:

vi /etc/drbd.conf 

Пример конфигурации (сохраните точно такой же блок resource):

global {
    usage-count no;
}
common {
    syncer { rate 100M; }
    protocol      C;
}
resource postgres {
    startup {
       wfc-timeout 0;
       degr-wfc-timeout
       120;
    }
    disk { on-io-error detach; }
    on node1.clusterbr.int {
       device      /dev/drbd0;
       disk        /dev/sdb;
       address     172.16.0.1:7791;
       meta-disk   internal;
    }
    on node2.clusterbr.int {
       device      /dev/drbd0;
       disk        /dev/sdb;
       address     172.16.0.2:7791;
       meta-disk   internal;
    }
}  

Комментарий к ключевым параметрам:

• resource — имя ресурса, которым управляет DRBD. В примере: “postgres”.
• disk — устройство на локальном узле, которое DRBD реплицирует (например, /dev/sdb).
• address — IP:порт для обмена данными между узлами. Используйте интерфейс для кроссовера или выделенную сеть кластера.
• syncer.rate — максимальная скорость синхронизации (100M в примере, т.к. сеть — гигабитная).

Важно: если сомневаетесь в опциях, смотрите DRBD Users Guide: http://www.drbd.org/users-guide-emb/ (ссылка оставлена для справки).

Создание метаданных DRBD

После редактирования конфига на обоих узлах нужно создать метаданные ресурса postgres:

drbdadm create-md postgres

Пример вывода на node1:

[root@node1 ~]# drbdadm create-md postgres  
Writing meta data...  
initializing activity log  
NOT initialized bitmap  
New drbd meta data block successfully created.

Повторите команду на node2 и убедитесь в аналогичном успешном результате.

Поднимите ресурс DRBD

На обоих узлах выполните:

drbdadm up postgres

Первичная синхронизация (promote/overwrite)

Начальную синхронизацию нужно выполнить только с узла, который станет Primary (в примере — node1):

drbdadm -- --overwrite-data-of-peer primary postgres

Проверить статус синхронизации:

cat /proc/drbd

Пример вывода показывает скорость и прогресс синхронизации. Дождитесь окончания процесса — при больших объёмах данных это может занять долгое время и зависит от дисков и сетевой пропускной способности.

Когда синхронизация завершена, /proc/drbd на обоих узлах должен показать состояния Connected и UpToDate/UpToDate:

cat /proc/drbd

Пример вывода на node1 и node2 в корректном состоянии приведён в исходной инструкции.

Важно: смысл полей можно изучить в документации: http://www.drbd.org/users-guide-emb/ch-admin.html#s-proc-drbd

5. Конфигурация PostgreSQL

Запуск DRBD и подготовка файловой системы

На обоих узлах запустите DRBD-службу (инициализация):

/etc/init.d/drbd start

Убедитесь, что node1 находится в роли Primary (см. /proc/drbd). Это означает, что запись будет происходить на node1, а node2 будет получать реплики.

Отформатируйте DRBD-устройство на Primary (в примере используется ext3):

mkfs.ext3 /dev/drbd0 

Смонтируйте файловую систему в каталог данных PostgreSQL (типично для RHEL/CentOS):

mount -t ext3 /dev/drbd0 /var/lib/pgsql

Задайте владельца и группу каталога данных:

chown postgres.postgres /var/lib/pgsql

Инициализация базы PostgreSQL

Теперь от имени пользователя postgres создайте кластер БД (initdb). На Primary выполните:

su - postgres
initdb /var/lib/pgsql/data
exit

Я рекомендую временно разрешить доверенную аутентификацию с IP-адресов кластера для удобства тестирования (позаботьтесь об этом в производственной среде):

echo "host all all 10.0.0.191/32 trust" >> /var/lib/pgsql/data/pg_hba.conf
echo "host all all 10.0.0.192/32 trust" >> /var/lib/pgsql/data/pg_hba.conf
echo "host all all 10.0.0.190/32 trust" >> /var/lib/pgsql/data/pg_hba.conf

В конфигурации postgresql.conf включите прослушивание всех интерфейсов (listen_addresses):

vi /var/lib/pgsql/data/postgresql.conf

Измените строку:

listen_addresses = '0.0.0.0'

Запустите PostgreSQL на Primary:

/etc/init.d/postgresql start

Создайте пользователя администратора и базу для тестирования, затем заполните её pgbench:

su - postgres
createuser --superuser admpgsql --pwprompt
createdb pgbench
pgbench -i pgbench

Пример вывода pgbench показывает процесс создания таблиц и заполнения тестовыми данными.

Проверьте доступ к базе и содержимое таблицы:

psql -U admpgsql -d pgbench
select * from pgbench_tellers;

Если вы видите строки — PostgreSQL работает корректно на Primary.

Проверка работы PostgreSQL на запасном узле (node2)

Чтобы убедиться, что PostgreSQL можно поднять на node2 в случае фейловера, проведите тестовый сценарий переключения ролей.

На node1 выполните остановку PostgreSQL и переведите DRBD в Secondary:

/etc/init.d/postgresql stop
umount /dev/drbd0
drbdadm secondary postgres

На node2 продвиньте DRBD в Primary, смонтируйте устройство и запустите PostgreSQL:

drbdadm primary postgres
mount -t ext3 /dev/drbd0 /var/lib/pgsql/
/etc/init.d/postgresql start

Подключитесь к pgbench на node2 и выполните выборку, чтобы убедиться в целостности данных:

psql -U admpgsql -d pgbench
select * from pgbench_tellers;

Если всё в порядке, остановите службы и верните конфигурацию в исходное состояние для настройки Pacemaker:

На node2:

/etc/init.d/postgresql stop
umount /dev/drbd0
drbdadm secondary postgres
/etc/init.d/drbd stop

На node1:

drbdadm primary postgres
/etc/init.d/drbd stop

Отключите автозапуск DRBD и PostgreSQL в runlevel 3 и 5 (пример для RHEL/CentOS):

chkconfig --level 35 drbd off
chkconfig --level 35 postgresql off

Контрольные списки (role-based)

Администратор кластера (sysadmin):

• Убедиться, что сеть кластера выделена и имеет минимальную задержку.
• Проверить корректность /etc/hosts и DNS для node1/node2 и кластерных IP.
• Настроить и протестировать firewall/SELinux (временно отключить для тестирования).
• Прогнать тест фейловера вручную и прозвонить сервисы.

DBA:

• Проверить права и владельца каталога данных PostgreSQL.
• Выполнить initdb и проверить postgresql.conf/pg_hba.conf.
• Протестировать pgbench/пользовательские сценарии.

SRE / инженер по доступности:

• Спланировать мониторинг (DRBD, postgres, Pacemaker).
• Настроить алерты на расхождение ролей DRBD и недоступность Primary.
• Подготовить план отката и runbook на случай split-brain.

Ментальные модели и короткие эвристики

• DRBD реплицирует блоки — это не репликация на уровне СУБД. Всегда думайте о целостности файловой системы при переключениях.
• Всегда повышайте/понижайте роли DRBD осознанно: primary должен иметь смонтированную FS и быть «owner» PostgreSQL.
• Перед автозапуском Pacemaker отключите локальный автозапуск postgresql/drbd, иначе при старте узла сервисы могут конфликтовать.

Критерии приёмки

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

• DRBD показывает Connected и UpToDate/UpToDate на обоих узлах.
• На Primary PostgreSQL запускается и принимает соединения.
• На Secondary можно выполнить тестовый promote и успешно запустить PostgreSQL с доступом к тем же данным.
• Автоматический фейловер через Pacemaker отрабатывает по заданным ресурсам (тест на dev или staging).

Сценарии неполадок и отладка (Troubleshooting)

1. Синхронизация застряла или очень медленная:

• Проверьте сетевую пропускную способность между адресами в конфиге DRBD.
• Убедитесь, что syncer.rate не превышает реальную способность сети.
• Отключите ненужные firewall-правила для порта 7791.

2. DRBD не поднимается (drbdadm up падает):

• Проверьте корректность /etc/drbd.conf — синтаксис и соответствие имён узлов.
• Просмотрите /var/log/messages или systemd journal для детальной ошибки.

3. Split-brain (оба узла считают себя Primary):

• Немедленно остановите PostgreSQL на одном узле.
• Используйте drbdadm –help или документацию для восстановления и объединения данных; при необходимости восстановите из бэкапа.
• Всегда планируйте процедуру разрешения split-brain заранее и держите бэкапы.

4. PostgreSQL не стартует на новом Primary после promote:

• Проверьте права и владельца каталога /var/lib/pgsql.
• Убедитесь, что fstab не монтирует /var/lib/pgsql автоматически конфликтующим образом.
• Посмотрите логи PostgreSQL (pg_log или systemd journal).

Безопасность и соответствие данным

• Во время тестов была предложена trust-аутентификация для удобства. В продакшене используйте md5/scram или сертификаты.
• Настройте резервное копирование (pg_basebackup, pg_dump, инструменты на уровне файлов) и проверяйте восстановление.
• Для данных, подпадающих под GDPR/локальные регламенты, обеспечьте шифрование at rest и контроль доступа к бэкапам.

Мини-методология быстрого развёртывания (5 шагов)

1. Подготовить сеть и разделы на обоих узлах (/dev/sdb).
2. Сконфигурировать /etc/drbd.conf и создать метаданные (drbdadm create-md).
3. Поднять DRBD и выполнить initial sync с –overwrite-data-of-peer на выбранном Primary.
4. Отформатировать /dev/drbd0, смонтировать, и инициализировать PostgreSQL на Primary.
5. Протестировать promote на Secondary и подготовить Pacemaker/Corosync для автоматического управления ресурсами.

Примеры полезных команд (Cheat sheet)

• Создание метаданных DRBD:

  drbdadm create-md postgres

• Поднять ресурс:

  drbdadm up postgres

• Promote primary с перезаписью данных на пира:

  drbdadm -- --overwrite-data-of-peer primary postgres

• Проверка статуса DRBD:

  cat /proc/drbd

• Форматирование устройства:

  mkfs.ext3 /dev/drbd0

• Монтирование и изменение владельца:

  mount -t ext3 /dev/drbd0 /var/lib/pgsql
  chown postgres.postgres /var/lib/pgsql

• Инициализация БД и загрузка тестовых данных:

  su - postgres
  initdb /var/lib/pgsql/data
  createdb pgbench
  pgbench -i pgbench

Decision flow (мермайд для быстрого понимания фейловера)

flowchart TD
  A[Нормальная работа на node1 'Primary'] -->|Сбой Primary| B{DRBD статус}
  B -->|Connected| C[Pacemaker промотит node2]
  B -->|Split-Brain| D[Остановить оба узла, вмешательство оператора]
  C --> E[drbdadm primary на node2, mount, start postgres]
  E --> F[Проверка целостности данных]
  F --> G[Если OK — обновить конфиг Pacemaker]

Итог и рекомендации

• DRBD + Pacemaker + Corosync — надёжная модель для Active/Passive кластера PostgreSQL, если правильно настроены сеть и процедура фейловера.
• Всегда тестируйте promote/rollback в staging и имейте валидные бэкапы перед сменой ролей.
• Автоматизация через Pacemaker избавит от ручных переключений, но требует тщательной проработки ресурсов и зависимостей.

Важное: перед вводом в продакшн адаптируйте конфигурации (pg_hba.conf, firewall, SELinux, резервное копирование) под вашу политику безопасности и регламент.

Список ключевых проверок перед продом:

• DRBD синхронизирован и устойчив к кратковременным сетевым задержкам.
• PostgreSQL корректно стартует после promote на резервном узле.
• Pacemaker корректно управляет ресурсами и сопровождается мониторингом/алертами.