Повышение уровня реплик чтения в Базе данных Azure для PostgreSQL

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

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

Повышение уровня до основного сервера

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

Если основной сервер имеет какие-либо сломанные реплики, эти реплики необходимо удалить, прежде чем инициировать действие по повышению до основного сервера. Во время этого процесса реплика для чтения повышается до статуса нового первичного сервера. Эта операция может привести к краткому простою примерно на 1–3 минуты в зависимости от задержки репликации во время продвижения (для запланированных рекламных акций). После завершения процесса повышения предыдущий первичный сервер будет настроен как читаемая реплика.

На схеме показана конфигурация серверов до продвижения и итогового состояния после успешного завершения операции повышения.

Повышение до независимого сервера и удаление из репликации

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

На схеме показано, как серверы настроены до повышения их уровня и их конфигурации после успешного создания независимых серверов.

Для обоих методов продвижения можно рассмотреть дополнительные варианты:

• Запланированный: этот параметр гарантирует синхронизацию данных перед продвижением. Он применяет все необработанные журналы, чтобы обеспечить согласованность данных до принятия клиентских подключений.

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

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

Управление конфигурацией

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

Операция продвижения не переносит специфичные конфигурации и параметры. Ниже приведены некоторые из заметных:

• PgBouncer: Настройки и статус встроенного пулла подключений PgBouncer не реплицируются во время процесса повышения. Если PgBouncer был включен на первичной, но не на реплике, он останется отключенным на реплике после повышения. Если вы хотите PgBouncer на только что продвинутом сервере, необходимо включить его до или после действия повышения.
• Геоизбыточное хранилище резервных копий: параметры геоизбыточного резервного копирования не передаются. Так как реплики не поддерживают геоизбыточное резервное копирование, переведённый в основной статус (ранее реплика) его не имеет. Эту функцию можно активировать только во время создания обычного сервера (а не реплики).
• Параметры сервера: если значения на основном сервере и реплике для чтения отличаются, они не изменятся во время переназначения. Важно отметить, что параметры, влияющие на размер общей памяти, должны иметь одинаковые значения как на первичных, так и на репликах. Это требование подробно описано в разделе параметров сервера.
• Проверка подлинности Microsoft Entra: если для основного узла была настроена проверка подлинности Microsoft Entra, но реплика была настроена с использованием проверки подлинности PostgreSQL, то после повышения реплика не будет автоматически переключаться на проверку подлинности Microsoft Entra. Он сохраняет проверку подлинности PostgreSQL. Пользователям необходимо вручную настроить проверку подлинности Microsoft Entra на продвинутой реплике до или после процесса повышения.
• Высокий уровень доступности (HA): если вам требуется [HA]/azure/надежность/гибкий сервер postgresql для обеспечения надежности после повышения, его необходимо настроить на новом первичном сервере после изменения роли.

Соображения

Состояния сервера во время продвижения

В сценариях планового и принудительного продвижения необходимо, чтобы серверы (как первичные, так и реплики) были в состоянии "Готово". Если состояние сервера отличается от состояния "Готово" (например, "Обновление" или "Перезапуск"), повышение уровня не может продолжаться без проблем. Однако исключение производится в случае регионального сбоя.

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

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

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

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

Восстановление на определённый момент времени во время обновления

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

Error : Point-in-time-restore of server to the period when the siteswap operation for this server was in-progress or when the server was replica is not allowed.

Часто задаваемые вопросы

• Можно ли повысить уровень реплики, если на основном сервере включен высокий уровень доступности?

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

• Если у меня есть первичный сервер и реплика для чтения с функцией высокой доступности, и я повышу реплику до основного сервера, а затем переключусь обратно на исходный первичный сервер, будет ли сервер по-прежнему иметь высокую доступность?

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

Связанный контент

• Чтение реплик в Базе данных Azure для PostgreSQL.
• Георепликация в Базе данных Azure для PostgreSQL.
• Виртуальные конечные точки для реплик чтения в Базе данных Azure для PostgreSQL.
• Создайте реплику для чтения.
• Репликация между регионами Azure и виртуальными сетями с частными сетями.