Освоение репликации PostgreSQL: типы и настройка с пояснениями

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

PostgreSQL предлагает два распространенных варианта: потоковая репликация и логическая репликация. Потоковая репликация копирует WAL на уровне физического кластера. Логическая репликация отправляет изменения на уровне строк из выбранных таблиц через публикации и подписки.

Почему репликация PostgreSQL важна

Репликация помогает решить четыре повседневные операционные проблемы:

• Высокая доступность: Если основной сервер выходит из строя, вы можете повысить резервный сервер и направить на него приложения.
• Аварийное восстановление: Резервный сервер в другом месте может защитить вас от сбоя на уровне площадки.
• Масштабирование чтения: Запросы только для чтения могут выполняться на горячих резервных серверах вместо основного сервера записи.
• Поддержка миграции: Логическая репликация может помочь переместить выбранные таблицы между версиями PostgreSQL или макетами баз данных.

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

Потоковая репликация (физическая репликация)

Потоковая репликация является наиболее распространенной и фундаментальной формой репликации в PostgreSQL. Она работает путем отправки записей журнала упреждающей записи (WAL) с основного сервера на одну или несколько реплик. Эти записи WAL представляют каждое изменение, внесенное в базу данных. Затем реплики применяют эти записи WAL к своим собственным файлам данных, обеспечивая их согласованность с основным сервером.

Синхронная и асинхронная потоковая репликация

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

Асинхронная репликация позволяет основному серверу фиксировать изменения локально и отправлять WAL репликам после этого. Это быстрее для записи, но сбой основного сервера может привести к потере недавних транзакций, которые еще не достигли резервного сервера.

Настройка потоковой репликации (пример асинхронной)

Настройка потоковой репликации включает настройку как основного, так и резервного серверов. Вот упрощенное руководство:

1. Настройка основного сервера (postgresql.conf и pg_hba.conf)

На основном сервере необходимо включить архивирование WAL и соединения для репликации.

• Изменения в postgresql.conf:

  wal_level = replica  # или logical для логической репликации
  max_wal_senders = 5  # Количество одновременных соединений репликации
  wal_keep_size = 512MB # Или wal_keep_segments для старых версий
  # Для синхронной репликации добавьте:
  # synchronous_standby_names = 'replica1,replica2'
  # Или для конкретного имени сервера/приоритета:
  # synchronous_standby_names = '1 (replica1), 2 (replica2)'
  archive_mode = on
  archive_command = 'test ! -f /path/to/wal_archive/%f && cp %p /path/to/wal_archive/%f'
  

  • wal_level: Должен быть не ниже replica для потоковой репликации.
  • max_wal_senders: Определяет, сколько резервных серверов могут подключаться одновременно.
  • wal_keep_size: Предотвращает удаление файлов WAL до того, как реплики смогут их получить (более простая альтернатива archive_command для базовых настроек, но архивирование рекомендуется для надежности).
  • archive_mode и archive_command: Полезны для восстановления на момент времени (PITR) и для реплик, которым нужны старые WAL после отставания. В производственной среде используйте реальную цель архивации или инструмент резервного копирования вместо локальной команды копирования.

• Изменения в pg_hba.conf:

  Разрешите реплике подключаться для репликации. Замените replica_ip_address на фактический IP-адрес вашей реплики.

  # TYPE  DATABASE        USER            ADDRESS                 METHOD
  host    replication     replication_user  replica_ip_address/32   md5
  

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

  -- На основном сервере:
  CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'your_password';
  

  После изменения этих файлов перезагрузите конфигурацию PostgreSQL:

  pg_ctl reload
  # Или перезапустите PostgreSQL при необходимости
  

2. Подготовка резервного сервера

Перед запуском реплики ее каталог данных должен быть копией каталога данных основного сервера на определенный момент времени. Самый простой способ — использовать pg_basebackup.

• Остановите PostgreSQL на реплике (если он запущен).

• Сделайте базовую резервную копию:

  # Убедитесь, что PGDATA пуст или удален
  pg_basebackup -h primary_host_ip -p 5432 -U replication_user -D /var/lib/postgresql/data/ -Fp -Xs -P -R
  

  • -h, -p, -U: Укажите данные для подключения к основному серверу.
  • -D: Каталог данных для реплики.
  • -Fp: Формат — обычный.
  • -Xs: Потоковая передача WAL во время резервного копирования.
  • -P: Показывать прогресс.
  • -R: Записать настройки подключения резервного сервера и создать standby.signal для PostgreSQL 12 и новее.
  • Вас попросят ввести пароль для replication_user.

3. Настройка резервного сервера

• Изменения в postgresql.conf (для PG12+):

  hot_standby = on # Разрешает запросы только для чтения на реплике
  primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'
  

  • hot_standby: Включает запросы только для чтения на резервном сервере.
  • primary_conninfo: Строка подключения к основному серверу.

• Старые версии PostgreSQL:

  PostgreSQL 12 удалил recovery.conf. Если вы поддерживаете старый сервер, создайте recovery.conf в каталоге данных реплики:

  standby_mode = 'on'
  primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'
  # Если вы используете восстановление из архива вместо потоковой передачи, укажите restore_command
  # restore_command = 'cp /path/to/wal_archive/%f %p'
  # recovery_target_timeline = 'latest'
  

  В PostgreSQL 12 и новее режим резервного сервера управляется standby.signal, а primary_conninfo обычно находится в postgresql.auto.conf при создании с помощью pg_basebackup -R.

4. Запуск резервного сервера

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

Совет: Для надежной высокой доступности рассмотрите возможность использования таких инструментов, как Patroni или repmgr, которые автоматизируют переключение при сбое и управление.

Логическая репликация

Логическая репликация — это более гибкая и детализированная форма репликации, представленная в PostgreSQL 10. Вместо репликации целых блоков данных или записей WAL она реплицирует изменения данных на основе их логического значения (например, операторы INSERT, UPDATE, DELETE) на уровне строк. Это достигается путем декодирования записей WAL в поток логических изменений.

Ключевые особенности и варианты использования:

• Выборочная репликация: Вы можете выбрать, какие таблицы реплицировать. Последние версии PostgreSQL также поддерживают списки столбцов в публикациях, но перед использованием этой функции проверьте версию вашего сервера.
• Кроссплатформенная репликация: Логическая репликация может реплицировать данные между разными основными версиями PostgreSQL.
• Контроль схемы: Логическая репликация не реплицирует DDL автоматически. Создайте соответствующие таблицы и применяйте миграции схемы на подписчике.
• Преобразование данных: Хотя это и не встроенная функция, логическая репликация обеспечивает основу для более сложных процессов ETL (извлечение, преобразование, загрузка).
• Репликация с основного сервера на реплику, которая не является полным клоном: Целевая база данных не должна быть полной физической копией источника.

Как это работает:

1. Издатель: Исходная база данных (основная), где происходят изменения данных. Для нее требуется wal_level = logical. Изменения декодируются из WAL в логический поток.
2. Публикация: Именованный набор таблиц на издателе, изменения которых будут реплицироваться.
3. Подписчик: Целевая база данных (реплика), которая получает изменения.
4. Подписка: Соединение на подписчике, которое подключается к издателю и применяет изменения из определенной публикации.

Настройка логической репликации

1. Настройка издателя (основного сервера)

• Изменения в postgresql.conf:

  wal_level = logical
  max_replication_slots = 10 # Для слотов логической репликации
  max_wal_senders = 10     # Должно быть не меньше max_replication_slots
  

• Создание публикации:

  -- В базе данных издателя:
  CREATE PUBLICATION my_publication FOR TABLE 
      table1, 
      table2 
      WITH (publish = 'insert,update,delete');
  
  -- Или для всех таблиц:
  -- CREATE PUBLICATION all_tables_pub FOR ALL TABLES;
  

  Перезагрузите конфигурацию на издателе.

2. Настройка подписчика (резервного сервера)

• Убедитесь, что целевые таблицы существуют: База данных подписчика должна иметь целевые таблицы с той же схемой, что и у издателя. Вы можете создать их вручную или использовать pg_dump для извлечения схемы.

• Создание подписки:

  -- В базе данных подписчика:
  CREATE SUBSCRIPTION my_subscription
      CONNECTION 'host=publisher_host_ip port=5432 user=replication_user password=your_password dbname=publisher_db'
      PUBLICATION my_publication;
  

  replication_user должен иметь соответствующие разрешения на издателе.

  PostgreSQL автоматически создаст слот репликации на издателе и начнет применять изменения. Вы можете отслеживать статус подписки с помощью pg_stat_subscription на подписчике.

Совет: Логическая репликация использует встроенную инфраструктуру логического декодирования PostgreSQL. Для базовых публикаций и подписок не требуется отдельное расширение.

Выбор правильного метода репликации

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

Вывод

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

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