Репликация

Обзор

Авторские права

Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов

Использование материалов курса

Некоммерческое использование материалов курса (презентации,

демонстрации) разрешается без ограничений. Коммерческое

использование возможно только с письменного разрешения компании

Postgres Professional. Запрещается внесение изменений в материалы

курса.

Обратная связь

Отзывы, замечания и предложения направляйте по адресу:

edu@postgrespro.ru

Отказ от ответственности

Компания Postgres Professional не несет никакой ответственности за

любые повреждения и убытки, включая потерю дохода, нанесенные

прямым или непрямым, специальным или случайным использованием

материалов курса. Компания Postgres Professional не предоставляет

каких-либо гарантий на материалы курса. Материалы курса

предоставляются на основе принципа «как есть» и компания Postgres

Professional не обязана предоставлять сопровождение, поддержку,

обновления, расширения и изменения.

Темы

Задачи и виды репликации

Физическая репликация

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

Варианты использования механизма репликации

Задачи репликации

Репликация

процесс синхронизации нескольких копий кластера баз данных

на разных серверах

Задачи

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

система должна сохранить доступность

(возможна деградация производительности)

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

Одиночный сервер, управляющий базами данных, может не

удовлетворять предъявляемым требованиям.

Во-первых, отказоустойчивость: один физический сервер — это

возможная точка отказа. Если сервер выходит из строя, система

становится недоступной.

Во-вторых, производительность. Один сервер может не справляться

с нагрузкой. Зачастую наращиванию мощности сервера

предпочтительна возможность масштабирования — распределения

нагрузки на несколько серверов.

Таким образом, речь идет о том, чтобы иметь несколько серверов,

работающих над одними и теми же базами данных. Под репликацией

понимается процесс синхронизации этих серверов.

Виды репликации

Физическая

мастер-реплика: поток данных только в одну сторону

трансляция потока журнальных записей или файлов журнала

требуется двоичная совместимость серверов

возможна репликация только всего кластера

Логическая

публикация-подписка: поток данных возможен в обе стороны

информация о строках (уровень журнала logical)

требуется совместимость на уровне протокола

возможна выборочная репликация отдельных таблиц

Взаимодействие нескольких серверов можно организовать по-разному.

Два основных подхода, доступных в PostgreSQL — физическая и

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

При физической репликации серверы имеют назначенные роли: мастер

и реплика. Мастер передает на реплику журнальные записи (в виде

файлов или потока записей); реплика применяет эти записи к своим

файлам данных. Применение происходит чисто механически, без

«понимания смысла» изменений, поэтому важна двоичная

совместимость между серверами (одинаковые платформы и основные

версии PostgreSQL). Поскольку журнал общий для всего кластера, то и

реплицировать можно только кластер целиком.

При логической репликации в журнал добавляется информация более

высокого уровня, позволяющая реплике разобраться в изменениях на

уровне строк таблиц (параметр wal_level = logical). Для такой

репликации не нужна двоичная совместимость, реплика должна лишь

уметь декодировать содержащуюся в журнале логическую

информацию. Логическая репликация позволяет при необходимости

проигрывать не все изменения, а только касающиеся отдельных

таблиц.

Логическая репликация доступна, начиная с версии 10; более ранние

версии должны были использовать расширение pg_logical, либо

организовывать репликацию с помощью триггеров.

Физическая репликация

Схема работы репликации

Способы доставки журналов

Использование реплики

Переключение на реплику (и обратно)

Варианты настройки и использования репликации

Сначала познакомимся с физической репликацией.

Механизм ее работы — передача на реплику изменений в виде записей

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

чтобы между серверами была двоичная совместимость (основная

версия сервера, операционная система, аппаратная платформа).

Физическая репликация всегда однонаправлена: в ней может

существовать только один мастер (и произвольное число реплик).

Репликация

Резервная копия

базовая резервная копия — pg_basebackup

архив файлов журнала предзаписи

Непрерывное восстановление

разворачиваем резервную копию,

задаем конфигурационные параметры,

создаем сигнальный файл standby.signal

и запускаем сервер

сервер восстанавливает согласованность

и продолжает применять поступающие журналы

доставка — поток по протоколу репликации или архив WAL

подключения (только для чтения) разрешаются

сразу после восстановления согласованности

Настройка репликации выполняется очень похоже на настройку

физического резервного копирования. Отличие в том, что резервная

копия поднимается сразу, не дожидаясь поломки основного сервера,

и работает в режиме постоянного восстановления: все время читает и

применят новые сегменты WAL, приходящие с мастера. Для этого

вместо сигнального файла recovery.signal создается другой файл,

standby.signal.

Таким образом, реплика постоянно поддерживается в почти актуальном

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

работу.

По умолчанию реплика работает в режиме «горячего резерва» —

в процессе восстановления допускает подключения для чтения данных

(как только будет восстановлена согласованность). Можно запретить

подключения, тогда реплика называется сервером «теплого резерва».

В отличие от резервной копии, репликация не позволяет

восстановиться на произвольный момент в прошлом. Иными словами,

репликацию невозможно использовать, чтобы исправить допущенную

ошибку (хотя есть возможность настроить репликацию так, чтобы она

отставала от мастера на определенное время).

Использование реплики

Допускаются

запросы на чтение данных (select, copy to, курсоры)

установка параметров сервера (set, reset)

управление транзакциями (begin, commit, rollback...)

создание резервной копии (pg_basebackup)

Не допускаются

любые изменения (insert, update, delete, truncate, nextval...)

блокировки, предполагающие изменение (select for update...)

команды DDL (create, drop...), в том числе создание временных таблиц

команды сопровождения (vacuum, analyze, reindex...)

управление доступом (grant, revoke...)

не срабатывают триггеры и пользовательские (advisory) блокировки

В режиме горячего резерва на реплике не допускаются никакие

изменения данных (включая последовательности), блокировки,

команды DDL, такие служебные команды, как VACUUM и ANALYZE,

команды управления доступом — словом, все, что так или иначе

изменяет данные.

При этом реплика может выполнять запросы на чтение данных. Также

будет работать установка параметров сервера и команды управления

транзакциями — например, можно начать (читающую) транзакцию

с нужным уровнем изоляции.

Кроме того, реплику можно использовать и для изготовления резервных

копий (конечно, принимая во внимание возможное отставание от

мастера).

Потоковая репликация

основной сервер

(мастер)

сегменты WAL

select, insert

update, delete

резервный сервер

(реплика)

wal sender wal receiver

непрерывное

восстановление

обратная связь

Есть два способа доставки журналов от мастера к реплике. Основной,

который используется на практике — потоковая репликация.

В этом случае реплика подключается к мастеру по протоколу

репликации и читает поток записей WAL. За счет этого при потоковой

репликации отставание реплики сведено к минимуму, и даже к нулю при

синхронном режиме.

Тонкий момент. Очистка на основном сервере может удалить версии

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

запрос на реплике в таком случае придется отменить. Эта проблема

решается в случае потоковой репликации с помощью специального

механизма обратной связи: мастер будет знать, какой номер

транзакции нужен для снимка данных на реплике и отложит очистку.

Репликация с архивом

archive_command

архив WAL

основной сервер

(мастер)

сегменты WAL

select, insert

update, delete

резервный сервер

(реплика)

альтерна-

тивный источник

журнальных

записей

wal sender wal receiver

При использовании потоковой репликации есть опасность, что мастер

удалит сегмент WAL, данные из которого еще не переданы на реплику.

Для уверенности надо либо использовать слот репликации, либо

применять потоковую репликацию вместе с архивом WAL (который все

равно необходим для организации резервного копирования).

При использовании архива специальный процесс archiver на мастере

записывает заполненные сегменты журнала с помощью команды

archive_command (этот механизм рассматривается в модуле

«Резервное копирование»).

Если реплика не сможет получить очередную журнальную запись по

протоколу репликации, она попробует прочитать ее из архива

с помощью команды из параметра restore_command.

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

потоковой репликации. Но в этом случае:

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

сегмента;

- мастер ничего не знает о существовании реплики, поэтому очистка

может удалить версии строк, нужные для снимка на реплике (можно

настроить задержку применения конфликтующих записей, но далеко не

всегда понятно, на какое время).

Переключение на реплику

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

останов основного сервера для технических работ без прерывания

обслуживания

ручной режим

Аварийное переключение

переход на реплику из-за сбоя основного сервера

ручной режим,

но в принципе можно автоматизировать с помощью

дополнительного кластерного ПО

Причины перехода на резервный сервер бывают разные. Это может

быть необходимость проведения технических работ на основном

сервере — тогда переход выполняется в удобное время в штатном

режиме. А может быть сбой основного сервера, и в таком случае

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

прерывать обслуживание пользователей.

Даже в случае сбоя переход осуществляется вручную, так как

PostgreSQL не имеет встроенного кластерного программного

обеспечения (которое должно следить за состоянием серверов и

инициировать переход).

Переключение на реплику

основной сервер

(мастер)

сегменты WAL

select, insert

update, delete

резервный сервер

(реплика)

wal sender wal receiver

Переход на реплику в картинках: вначале имеются два сервера (мастер

и реплика), между ними настроена репликация.

Переключение на реплику

бывший мастер

сегменты WAL

основной сервер

(бывшая реплика)

select, insert

update, delete

В случае выхода основного сервера из строя или при штатной

необходимости работ реплике дается команда прекратить

восстановление и стать самостоятельным сервером, а бывший мастер

отключается.

Конечно, требуется способ перенаправить пользователей на новый

сервер; но это выполняется средствами вне PostgreSQL.

Восстановление мастера

резервный сервер

(бывший мастер)

основной сервер

select, insert

update, delete

wal senderwal receiver

После восстановления бывшего основного сервера или окончания

других работ на нем он подключается в качестве реплики к новому

работающему мастеру.

Восстановление мастера

Простое подключение бывшего мастера — не работает

проблема потери записей WAL, не попавших на реплику из-за задержки

Восстановление «с нуля» из резервной копии

на месте бывшего мастера разворачивается абсолютно новая реплика

процесс занимает много времени (отчасти можно ускорить rsync)

Утилита pg_rewind

«откатывает» потерянные записи WAL, заменяя соответствующие

страницы на диске страницами с нового мастера

есть ряд ограничений, ограничивающий применение

Если переход на реплику произошел из-за аппаратуры (необходима

замена дисков или сервера) или операционной системы (необходима

переустановка ОС), то единственный вариант состоит в изготовлении

абсолютно новой реплики на новом сервере.

Если же переход был штатным, полезен способ быстро вернуть старый

мастер в строй (теперь уже в качестве реплики).

К сожалению, простой способ — подключить старый мастер к новому

по репликационному протоколу — не работает. Причина в том, что из-за

задержек в репликации часть записей WAL могла не дойти до реплики.

Если на старом мастере остались такие записи, то применение записей

с нового мастера приведет к повреждению базы.

Всегда есть вариант создать абсолютно новую реплику путем

изготовления базовой резервной копии. Однако для больших баз

данных этот процесс может занимать много времени. Его можно

ускорить с помощью rsync.

Еще более быстрый вариант состоит в использовании утилиты

pg_rewind https://postgrespro.ru/docs/postgresql/13/app-pgrewind.

Утилита определяет записи WAL, которые не дошли до реплики

(начиная с последней общей контрольной точки), и находит страницы,

затронутые этими записями. Найденные страницы (которых должно

быть немного) заменяются страницами с нового мастера. Кроме того,

утилита копирует с сервера-источника (нового мастера) все служебные

файлы. Дальше работает обычный процесс восстановления.