Поделиться через

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

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

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

Внимание

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

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

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

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

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

Схема, показывающая повышение до операции сервера-источника.

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

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

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

Схема, показывающая повышение до независимого сервера и удаление из операции репликации.

Внимание

Повышение уровня до независимого сервера и удаление из действия репликации обратно совместимо с предыдущими функциями повышения уровня.

Внимание

Симметрия сервера. Для успешного повышения уровня с помощью операции первичного сервера первичный сервер и серверы-реплики должны иметь одинаковые уровни и размеры хранилища. Например, если основной имеет 2vCores и реплику имеет 4vCores, единственным жизнеспособным вариантом является использование действия "повышение до независимого сервера и удаление из репликации". Кроме того, они должны совместно использовать те же значения для параметров сервера, которые выделяют общую память.

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

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

  • Принудительно. Этот параметр предназначен для быстрого восстановления в таких сценариях, как региональные сбои. Вместо того, чтобы дождаться синхронизации всех данных из основного источника, сервер становится операционным после обработки файлов 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.

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

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

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

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

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

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