Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Истории успеха
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Доступны в регионе
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • AI Studio
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Партнёрская программа
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Истории успеха
  • Документация
  • Блог
Проект Яндекса
© 2025 ТОО «Облачные Сервисы Казахстан»
Yandex Managed Service for PostgreSQL
  • Начало работы
    • Взаимосвязь ресурсов сервиса
    • Планирование топологии кластера
    • Высокая доступность кластера
    • Сеть в Managed Service for PostgreSQL
    • Квоты и лимиты
    • Хранилище в Managed Service for PostgreSQL
    • Резервные копии
    • Назначение ролей
    • Управление соединениями
    • Репликация
    • Техническое обслуживание
    • Поддерживаемые клиенты
    • Настройки PostgreSQL
    • Индексы
    • Ограничения для команд SQL
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • Публичные материалы
  • История изменений
  • Обучающие курсы

В этой статье:

  • Управление репликацией
  • Автоматическое управление потоками репликации
  • Ручное управление потоками репликации
  • Синхронность записи и консистентность чтения
  • Логическое декодирование
  • Примеры использования
  1. Концепции
  2. Репликация

Репликация в Managed Service for PostgreSQL

Статья создана
Yandex Cloud
Обновлена 2 июля 2025 г.
  • Управление репликацией
    • Автоматическое управление потоками репликации
    • Ручное управление потоками репликации
  • Синхронность записи и консистентность чтения
  • Логическое декодирование
  • Примеры использования

В кластерах Managed Service for PostgreSQL используется кворумная репликация (quorum-based synchronous replication):

  1. Среди хостов кластера выбирается мастер, а все остальные хосты становятся репликами.
  2. Транзакция считается успешной только в том случае, если ее подтвердили хост-мастер и не менее половины реплик кластера.

Если количество реплик нечетное, значение округляется вниз. Например, в кластере с 17 репликами для формирования кворума необходимы 8.

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

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

Подробнее о том, как организована репликация в PostgreSQL, читайте в документации СУБД.

Управление репликациейУправление репликацией

Для обеспечения сохранности данных в кластере используется потоковая репликация. Каждый хост-реплика получает поток репликации от другого хоста (обычно это хост-мастер). Managed Service for PostgreSQL управляет потоками репликации в кластере автоматически, но при необходимости ими можно управлять вручную.

В кластере допустимо комбинировать автоматическое и ручное управление потоками репликации.

Автоматическое управление потоками репликацииАвтоматическое управление потоками репликации

После создания кластера PostgreSQL из нескольких хостов в нем находятся один хост-мастер и реплики. Реплики используют хост-мастер в качестве источника репликации.

Особенности автоматической репликации в Managed Service for PostgreSQL:

  • При выходе из строя хоста-мастера одна из реплик становится новым мастером.
  • При смене мастера источник репликации для всех хостов-реплик автоматически переключается на новый хост-мастер.

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

Ручное управление потоками репликацииРучное управление потоками репликации

При ручном управлении в качестве источника репликации для реплики могут выступать другие хосты в кластере.

При этом вы можете:

  • Полностью управлять процессом репликации в кластере и не использовать автоматическую репликацию.
  • Настроить репликацию для кластеров PostgreSQL со сложной топологией. При этом часть реплик будет управляться автоматически, а часть — вручную.

Например, таким образом можно настроить каскадную репликацию, когда часть реплик кластера использует другие хосты кластера в качестве источника потока репликации. При этом управление потоком репликации для таких хостов-источников может осуществляться как автоматически средствами Managed Service for PostgreSQL, так и вручную.

Важно

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

  • Становиться мастером при автоматической или ручной смене хоста-мастера.
  • Автоматически переключаться на новый источник репликации при выходе из строя текущего источника репликации.
  • Участвовать в кворумной репликации.
  • Выбираться как наименее отстающие при использовании особого FQDN.

Синхронность записи и консистентность чтенияСинхронность записи и консистентность чтения

За синхронизацию записи данных в PostgreSQL отвечает синхронность передачи WAL (Write-Ahead Log) — журнала опережающей записи (параметр synchronous_commit). По умолчанию для этого параметра установлено значение synchronous_commit = on. Оно предполагает, что транзакция подтверждается, только если WAL записан и на диск мастера, и на диск кворумной реплики.

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

Недостаток этого решения — операции записи в кластер будут занимать больше времени. Если мастер и кворумная реплика расположены в разных зонах доступности, то задержка подтверждения транзакции (latency) будет не меньше, чем время передачи данных туда и обратно (Round-Trip Time, RTT) между дата-центрами. Это снизит производительность кластера при записи в один поток и при включенном режиме AUTOCOMMIT.

Для повышения производительности ведите запись в несколько потоков, где это возможно, а также отключите AUTOCOMMIT и группируйте запросы в транзакции.

Логическое декодированиеЛогическое декодирование

Кластер Managed Service for PostgreSQL поддерживает логическое декодирование, которое позволяет передавать во внешние сервисы информацию об изменениях в базе данных. В частности, оно используется для захвата изменения данных (CDC).

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

Managed Service for PostgreSQL поддерживает следующие плагины WAL:

  • test_decoding — преобразует данные из WAL в текстовое представление.
  • wal2json — преобразует данные из WAL в JSON-представление.
  • pgoutput — преобразует данные из WAL в формат протокола логической репликации.

Создавать слоты репликации могут пользователи с ролью mdb_replication.

Примеры использованияПримеры использования

  • Миграция базы данных из стороннего кластера PostgreSQL в Managed Service for PostgreSQL
  • Миграция данных из Yandex Managed Service for MySQL® в Managed Service for PostgreSQL с помощью Yandex Data Transfer
  • Миграция данных из Managed Service for PostgreSQL в Yandex Managed Service for MySQL® с помощью Yandex Data Transfer
  • Миграция базы данных из Managed Service for PostgreSQL
  • Асинхронная репликация данных из PostgreSQL в ClickHouse®

Была ли статья полезна?

Предыдущая
Управление соединениями
Следующая
Техническое обслуживание
Проект Яндекса
© 2025 ТОО «Облачные Сервисы Казахстан»