Глава 7

Репликация

Вэтой главе мы рассмотрим:

•репликацию и ее устройство;

•инструменты отслеживания репликации;

•представления pg_stat_replication и pg_stat_wal_receiver;

•отставание репликации;

•слоты репликации;

•представление pg_replication_slots;

•публикации и подписки;

•представление pg_stat_replication_slots;

•представления pg_stat_subscription и pg_stat_subscription_stats;

•конфликты восстановления и представление pg_stat_database_conflicts.

Впредыдущей главе мы рассмотрели журнал упреждающей записи, один из важных компонентов СУБД, обеспечивающий гарантии сохранности данных. Кроме того, на использовании WAL-журнала основана репликация. С помощью репликации становится возможным построение комплексных и распределенных конфигураций, которые позволяют обеспечить резервирование, отказо- и катастрофоустойчивость и распределение нагрузки. Использование репликации и кластерных конфигураций усложняет администрирование, требует ответственного отношения и навыков настройки и эксплуатации. В этой главе мы кратко рассмотрим устройство репликации в PostgreSQL и варианты ее использования, а также более детально погрузимся в инструменты,которые предоставляетСУБДдля отслеживания работы кластеров и механизма репликации.

7.1. Обзор репликации

Репликация — это процесс синхронизации данных между двумя и более узлами. Обычно различают два вида репликации: физическую и логическую. Физическая репликация предполагает передачу физических изменений блоков данных без анализа содержимого передаваемых изменений. Логическая репликация является более сложной и включает в себя анализ,

174Глава 7. Репликация

фильтрацию и выборочную передачу изменений. В минимальной конфигурации в репликации участвует два узла: один — в роли основного (primary), являясь источником изменений, второй — в роли реплики, принимая изменения с основного узла и воспроизводя их у себя. В зависимости от типа репликации терминология может изменяться: например, в случае физической репликации реплики обычно называют резервными, или запасными (standby) узлами. В более сложных схемах репликации могут участвовать несколько основных узлов, типы репликации могут комбинироваться, и каждый из отдельных узлов может реплицировать изменения надругие узлы.Основное применение репликация находитв задачах распределения нагрузкинанесколькоузловиобеспеченияотказоустойчивости:приавариинаосновномузле можно переключить реплику в основной режим и продолжить обслуживать рабочую нагрузку с минимальным простоем (downtime) системы в целом. Физическая репликация получила распространение в силу своей универсальности и применимости в обоих сценариях. Логическаяжерепликацияприменяетсядлявыборочнойпередачинабораданных,напримервслучае шардирования (sharding).В этой главе мы по большей части сосредоточимся на рассмотрении именно физической репликации,а логическую затронем в меньшей степени.

ОбатипарепликациивPostgreSQLустроенысхожимобразом.Сначалавыполняетсяначальная синхронизацияданныхсосновногоузланареплику.Дальшерепликаподключаетсякосновному узлу, и все изменения, попадающие в WAL-журнал основного узла, передаются на реплику попротоколурепликации.Реплики,всвоюочередь,такжемогутпередаватьизменениянадругие узлы; таким образом можно выстраивать каскадные конфигурации.

Репликация по умолчанию является асинхронным процессом: изменения на основном сервере фиксируются независимо от наличия реплик. Репликацию можно переключить в синхронный режим (см. synchronous_commit), в котором транзакция на основном узле фиксируется только после подтверждения ее получения резервным узлом.В зависимости от значения параметра synchronous_commit подтверждение может отсылаться после сохранения полученных журнальных записей на диск (remote_write), синхронизации их с диском (on, по умолчанию) или воспроизведения принятых изменений (remote_apply).Синхронный режим позволяетваварийныхслучаяхсвестипотеризафиксированныхтранзакцийкнулю.Однакоиспользованиесинхроннойрепликации,особенноврежимеremote_apply,можетзначительносказаться напроизводительности,и,болеетого,отказрепликиможетпривестикотказувобслуживании наосновномузле:всеоперациипофиксациитранзакцийбудутожидатьдоставкижурнальных записей на реплику. Поэтому решение использовать синхронную репликацию должно быть взвешенным и обоснованным. В любом случае все изменения, записанные в журнал основного узла, появляются на репликах с некоторой задержкой (replication lag); ее величина зависит оттаких факторов,как производительностьузлов,сетевое окружение илитекущая рабочая нагрузка.

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

фоновый процесс walsender, который в дальнейшем и будет отвечать за потоковую передачу журнала. Оба процесса, walsender и walreceiver, поддерживают между собой постоянное соединение, и, как только в журнале появляются новые данные (включая данные еще незафиксированных транзакций), walsender передает их процессу walreceiver. Процесс walreceiver ожидаетпередачиданных.Получив журнальные записи,он сохраняетих влокальный каталог pg_walосновногокаталогаданных,послечегодругойфоновыйпроцесс,startup,воспроизводит (replay) переданные изменения на локальной копии данных. Как только изменения применены, обновленные данные становятся видны запросам, выполняющимся на реплике. Такой механизм репликации зарекомендовал себя как простой и надежный.

На основе передачи WAL-записей реализованы оба вида репликации — и физическая, и логическая. Поскольку в WAL-журнале фиксируются изменения на уровне отдельных физических блоков, физическая репликация и заключается в передаче изменений физических блоков. Эти изменения описывают атомарный переход блока из одного физического состояния в другое без уточнения, какие именно пользовательские данные были изменены (таблицы, строки или отдельные поля). Таким образом, процессы walsender и walreceiver обеспечивают непрерывную и последовательную передачу потока изменений между узлами, а процесс startup применяет все изменения, без пропусков и строго в порядке следования журнальных записей. Для оценки работы физической репликации достаточно отслеживать состояние процессов walsender и walreceiver и объем данных передаваемых основным узлом на реплики.

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

При физической репликации могутиспользоватьсятак называемые слоты репликации,а в случае логической репликации они являются обязательными.Слоты позволяютудерживатьнеобходимый объем WAL-сегментов, исключая возможность их переработки в ходе выполнения контрольных точек.Слоты являются важной частью механизма репликации и требуют внимания и контроля со стороны администратора: для мониторинга логической репликации нужно отслеживать не только передачу изменений,но и состояние слотов репликации.

1 postgrespro.ru/docs/postgresql/current/sql-createpublication

2 postgrespro.ru/docs/postgresql/current/sql-createsubscription