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

Георепликация в База данных Azure для PostgreSQL — гибкий сервер

  • Статья

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

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

Вы можете использовать основной сервер в любом База данных Azure для PostgreSQL гибком регионе сервера. Основной сервер также может иметь реплики в любом глобальном регионе Azure, поддерживающем База данных Azure для PostgreSQL гибкий сервер. Кроме того, мы также поддерживаем специальные регионы Azure для государственных организаций и Microsoft Azure, управляемые 21Vianet.

Парные регионы для аварийного восстановления

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

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

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

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

  • Место расположения данных. При некоторых исключениях регионы в парном наборе находятся в пределах одного географического региона, выполняя требования к месту расположения данных.

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

Дополнительные сведения о преимуществах парных регионов см . в документации Azure по репликации между регионами.

Региональные сбои и восстановление

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

Подготовка к региональным бедствиям

Подготовка к потенциальным региональным авариям крайне важна для обеспечения непрерывной работы приложений и служб. Если вы рассматриваете надежный план на непредвиденные случаи для вашего База данных Azure для PostgreSQL гибкого экземпляра сервера, ниже приведены основные шаги и рекомендации.

  1. Создайте геореплицированную реплику чтения: важно настроить реплику чтения в отдельном регионе от основного. Это гарантирует непрерывность в случае сбоя основного региона.
  2. Убедитесь, что симметрия сервера: действие "повышение уровня до основного сервера" является наиболее рекомендуемой для обработки региональных сбоев, но оно поставляется с требованием симметрии сервера. Это означает, что первичные и реплики серверов должны иметь одинаковые конфигурации определенных параметров. Преимущества использования этого действия:
    • Если вы используете виртуальные конечные точки, не нужно изменять строка подключения приложения.
    • Он обеспечивает простой процесс восстановления, когда затронутый регион снова в сети, исходный первичный сервер автоматически возобновляет свою функцию, но в новой роли реплики.
  3. Настройте виртуальные конечные точки: виртуальные конечные точки позволяют плавно переходить приложения в другой регион, если произошел сбой. Они устраняют необходимость внесения изменений в строка подключения приложения.
  4. Настройка реплики чтения: не все параметры с первичного сервера реплицируются на реплику чтения. Важно убедиться, что на реплике чтения настроены все необходимые конфигурации и компоненты (например, PgBouncer). Дополнительные сведения см. в разделе "Управление конфигурацией ".
  5. Подготовка к высокой доступности (HA) — если для установки требуется высокий уровень доступности, она не будет автоматически включена в реплике с повышением уровня. Будьте готовы активировать его после продвижения. Рассмотрите возможность автоматизации этого шага, чтобы свести к минимуму время простоя.
  6. Регулярное тестирование: регулярно имитируйте региональные сценарии стихийных бедствий для проверки существующих пороговых значений, целевых объектов и конфигураций. Убедитесь, что приложение отвечает должным образом во время этих тестовых сценариев.
  7. Следуйте общим рекомендациям Azure: Azure предоставляет исчерпывающие рекомендации по надежности и готовности к авариям. Очень полезно обратиться к этим ресурсам и интегрировать рекомендации в план подготовки.

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

Когда сбои влияют на соглашение об уровне обслуживания

Если длительный сбой с База данных Azure для PostgreSQL гибким сервером в определенном регионе, который угрожает соглашению об уровне обслуживания приложения (SLA), помните, что оба действия, рассмотренные ниже, не управляются службой. Для обоих пользователей требуется вмешательство пользователя. Рекомендуется автоматизировать весь процесс как можно больше и обеспечить надежный мониторинг. Дополнительные сведения о том, какие сведения предоставляются во время сбоя, см. на странице сбоя службы . Только принудительное повышение возможно в сценарии уменьшения региона, что означает, что объем потери данных примерно равен текущей задержке между репликой и первичной. Поэтому важно отслеживать задержку. Рассмотрим следующие действия.

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

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

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

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

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