Yandex Cloud
  • Сервисы
  • Решения
  • Почему Yandex Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Language / Region
© 2022 ООО «Яндекс.Облако»
Yandex Managed Service for PostgreSQL
  • Начало работы
  • Пошаговые инструкции
    • Все инструкции
    • Информация об имеющихся кластерах
    • Создание кластера
    • Подключение к базе данных
    • Остановка и запуск кластера
    • SQL-запросы в консоли управления
    • Обновление версии PostgreSQL
    • Изменение настроек кластера и базы данных
    • Подключение к DataLens
    • Управление хостами PostgreSQL
    • Управление базами данных
    • Управление PostgreSQL-расширениями
    • Управление пользователями БД
    • Назначение привилегий и ролей
    • Управление резервными копиями
    • Просмотр логов кластера
    • Удаление кластера
    • Диагностика производительности
    • Мониторинг состояния кластера и хостов
  • Практические руководства
    • Создание кластера PostgreSQL для 1С
    • Выгрузка базы данных в Yandex Data Proc
    • Анализ производительности и оптимизация
    • Репликация и миграция
      • Логическая репликация PostgreSQL
      • Миграция базы данных в Managed Service for PostgreSQL
      • Миграция базы данных из Managed Service for PostgreSQL
      • Создание логической реплики Amazon RDS для PostgreSQL в Managed Service for PostgreSQL
    • Поставка данных в Yandex Managed Service for Apache Kafka® с помощью Yandex Data Transfer
    • Поставка данных в Yandex Managed Service for Apache Kafka® с помощью Debezium
  • Концепции
    • Взаимосвязь ресурсов сервиса
    • Классы хостов
      • Действующие классы хостов
      • Архив
        • До 1 июня 2020 года
      • Использование устаревших классов хостов
    • Сеть в Managed Service for PostgreSQL
    • Квоты и лимиты
    • Хранилище в Managed Service for PostgreSQL
    • Резервные копии
    • Назначение ролей
    • Управление соединениями
    • Репликация
    • Техническое обслуживание
    • Поддерживаемые клиенты
    • Настройки PostgreSQL
  • Управление доступом
  • Правила тарификации
    • Действующие правила
    • Архив
      • До 1 января 2019 года
      • С 1 января до 1 марта 2019 года
      • С 1 марта 2019 года до 1 февраля 2020 года
  • Справочник API
    • Аутентификация в API
    • gRPC (англ.)
      • Overview
      • BackupService
      • ClusterService
      • DatabaseService
      • ResourcePresetService
      • UserService
      • OperationService
    • REST (англ.)
      • Overview
      • Backup
        • Overview
        • get
        • list
      • Cluster
        • Overview
        • addHosts
        • backup
        • create
        • delete
        • deleteHosts
        • get
        • list
        • listBackups
        • listHosts
        • listLogs
        • listOperations
        • move
        • rescheduleMaintenance
        • restore
        • start
        • startFailover
        • stop
        • streamLogs
        • update
        • updateHosts
      • Database
        • Overview
        • create
        • delete
        • get
        • list
        • update
      • ResourcePreset
        • Overview
        • get
        • list
      • User
        • Overview
        • create
        • delete
        • get
        • grantPermission
        • list
        • revokePermission
        • update
      • Operation
        • Overview
        • get
  • История изменений
  • Вопросы и ответы
    • Общие вопросы
    • Подключение
    • Изменение кластера
    • Настройки параметров кластера
    • Перемещение и восстановление кластера
    • Мониторинг и логи
    • Все вопросы на одной странице
  1. Концепции
  2. Репликация

Репликация

Статья создана
Yandex Cloud
  • Управление репликацией
    • Автоматическое управление потоками репликации
    • Ручное управление потоками репликации
  • Выбор мастера
  • Синхронность записи и консистентность чтения

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

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

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

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

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

Из-за ограниченных ресурсов хосты классов b1.nano, b1.micro, b2.nano и b2.micro не реплицируются.

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

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

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

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

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

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

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

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

Подробнее о процессе выбора мастера см. в подразделе Выбор мастера.

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

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

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

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

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

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

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

Выбор мастера

Чтобы повлиять на процесс выбора мастера в кластере PostgreSQL, установите нужные значения приоритета для хостов кластера: либо мастером будет выбран хост с самым высоким заданным приоритетом, либо, если в кластере есть несколько реплик с одинаково высоким приоритетом, будут проведены выборы среди этих реплик.

Задать приоритет хоста можно:

  • при создании кластера с помощью YC CLI, API или Terraform;
  • при изменении настроек хоста.

Наименьший приоритет — 0 (по умолчанию), наивысший — 100.

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

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

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

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

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

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

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

Language / Region
© 2022 ООО «Яндекс.Облако»
В этой статье:
  • Управление репликацией
  • Автоматическое управление потоками репликации
  • Ручное управление потоками репликации
  • Выбор мастера
  • Синхронность записи и консистентность чтения