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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перевести на независимый сервер и удалить из репликации

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

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

  • Last updated on