Центр знаний DevOps
Центр знаний DevOps

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

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

38 просмотров

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

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

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

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

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

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

PostgreSQL предлагает два основных метода репликации: потоковую репликацию и логическую репликацию. Хотя оба метода обеспечивают синхронизацию данных, они работают на разных принципах и подходят для разных сценариев.

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

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

Типы потоковой репликации:

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

    • Плюсы: Гарантирует отсутствие потери данных для зафиксированных транзакций на синхронной реплике.
    • Минусы: Может вызывать задержку при фиксации транзакций, поскольку основной сервер должен ждать подтверждения от реплики.

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

    • Плюсы: Минимальное влияние на задержку фиксации транзакций.
    • Минусы: Возможна потеря данных, если основной сервер выйдет из строя, а записи WAL еще не достигли реплики.

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

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

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

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

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

    ```ini
    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 = 'cp %p /path/to/wal_archive/%f'
    `` *wal_level: Должен быть как минимумreplicaдля потоковой репликации. *max_wal_senders: Указывает, сколько резервных серверов могут подключаться одновременно. *wal_keep_size: Предотвращает удаление файлов WAL до того, как реплики смогут их получить (более простой альтернативойarchive_commandдля базовых настроек, но архивирование рекомендуется для надежности). *archive_modeиarchive_command`: Важно для восстановления на определенный момент времени (PITR) и необходимо, если реплика сильно отстает или нуждается в перестройке.

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

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

    ```ini

    TYPE DATABASE USER ADDRESS METHOD

    host replication replication_user replica_ip_address/32 md5
    ```

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

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

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

    ```bash
    pg_ctl reload

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

    ```

2. Подготовка сервера реплики

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

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

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

    ```bash

    Убедитесь, что PGDATA пуст или удален предварительно

    pg_basebackup -h primary_host_ip -p 5432 -U replication_user -D /var/lib/postgresql/data/ -Fp -Xs -P
    `` *-h,-p,-U: Укажите детали подключения к основному серверу. *-D: Каталог данных для реплики. *-Fp: Формат — plain. *-Xs: Использовать потоковую передачу TSL/WAL. Эквивалентно настройкеprimary_conninfoдля потоковой передачи WAL. *-P: Показать прогресс. * Вас попросят ввести пароль дляreplication_user`.

3. Настройка сервера реплики (postgresql.conf и recovery.conf или postgresql.conf для PG12+)

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

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

    Для синхронной репликации добавьте:

    primary_promote_delay = 10 # секунд

    Или используйте механизм триггерного файла

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

  • recovery.conf (для версий PostgreSQL до 12):

    Создайте файл recovery.conf в каталоге данных реплики со следующим содержимым:

    ```ini
    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'

    ```

    Для PG12+ primary_conninfo и hot_standby настраиваются непосредственно в postgresql.conf.

4. Запуск сервера реплики

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

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

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

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

Основные функции и сценарии использования:

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

Принцип работы:

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

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

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

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

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

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

    ```sql
    -- В базе данных издателя:
    CREATE PUBLICATION my_publication FOR TABLE
    table1,
    table2
    WITH (publish = 'insert,update,delete');

    -- Или для всех таблиц:
    -- CREATE PUBLICATION all_tables_pub FOR ALL TABLES;
    ```

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

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

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

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

    sql -- В базе данных подписчика: 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 на подписчике.

Совет: Логическая репликация требует расширения logical decoding, которое обычно встроено. Она более ресурсоемка, чем потоковая репликация, но предлагает большую гибкость.

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

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

Заключение

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

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