Контрольный список высокого уровня доступности и аварийного восстановления — Управляемый экземпляр SQL Azure

  • Статья

Область применения: Управляемый экземпляр SQL Azure

Служба Управляемый экземпляр SQL Azure автоматически гарантирует, что все базы данных находятся в сети, работоспособности и постоянно стремятся достичь опубликованного соглашение об уровне обслуживания.

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

Контрольный список для обеспечения доступности

Для максимальной доступности рекомендуется использовать следующие конфигурации:

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

Контрольный список для обеспечения высокой доступности

Ниже приведена рекомендуемая конфигурация для обеспечения высокой доступности.

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

Контрольный список аварийного восстановления

Хотя Управляемый экземпляр SQL Azure автоматически поддерживает доступность, существуют экземпляры, даже если высокий уровень доступности (избыточность зоны) может не гарантировать устойчивость, так как влияние сбоя охватывает весь регион. Для запуска аварийного восстановления может потребоваться региональное Управляемый экземпляр SQL Azure.

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

  • Включите группы отработки отказа для экземпляра.
    • Используйте конечные точки прослушивателя только для чтения и чтения в приложении строка подключения поэтому приложения автоматически подключаются к каждому экземпляру.
    • Задайте политику отработки отказа управляемым клиентом.
  • Убедитесь, что гео вторичный экземпляр создается с тем же уровнем служб, оборудованием и размером вычислительных ресурсов, что и основной экземпляр.
  • При увеличении масштаба сначала масштабируйте геоторичную, а затем масштабируйте основной объект.
  • При вертикальном уменьшении масштаба действия следует выполнять в обратном порядке: сначала для первичной реплики, затем — для вторичной реплики.
  • Аварийное восстановление, по сути, предназначено для использования асинхронной репликации данных между основным и вторичным регионом. Чтобы определить приоритет доступности данных по сравнению с более высокой задержкой фиксации, рассмотрите возможность вызова хранимой процедуры sp_wait_for_database_copy_sync сразу после фиксации транзакции. Вызов sp_wait_for_database_copy_sync блокирует вызывающий поток, пока последняя зафиксированная транзакция не будет передана и журнал транзакций базы данных-получателя и зафиксирована в нем.
  • Отслеживайте задержку в отношении целевой точки восстановления (RPO) с помощью replication_lag_sec столбца динамического административного представления ( DMV) sys.dm_geo_replication_link_status базы данных-источника. Динамическое административное представление показывает задержку в секундах между транзакциями, зафиксированными в основном и защищенным в журнале транзакций в дополнительном объекте. Например, предположим, что задержка составляет одну секунду в определенный момент времени, если основной из-за сбоя и геоработка отказа инициируется в тот момент времени, транзакции, зафиксированные в последней секунде, будут потеряны.
  • Если включение групп отработки отказа невозможно, рекомендуется задать параметр избыточности хранилища резервных копий в хранилище геоизбыточного резервного копирования, чтобы использовать возможность геовосстановление.
  • Часто планируйте и выполняйте детализацию аварийного восстановления, чтобы лучше подготовиться в случае реального сбоя.

Подготовка вторичной к сбою

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

  • Для геовосстановление определите экземпляр в другом регионе, чтобы стать новым основным экземпляром. Обычно это экземпляр в парном регионе для региона, в котором находится основной экземпляр. Использование экземпляра в регионе, парном с основным регионом, устраняет затраты на дополнительный трафик во время операций геовосстановения.
  • Определите способ перенаправления пользователей на новый первичный сервер. Перенаправление пользователей можно выполнить путем ручного изменения строка подключения приложений или записей DNS. Если вы настроили группы отработки отказа и использовали прослушиватель только для чтения и чтения в приложениях строка подключения, то подключения автоматически направляются к новому первичному источнику после отработки отказа.
  • Определите и при необходимости определите конфигурацию группы безопасности сети и таблицы маршрутов, к которым пользователи должны получить доступ к новой базе данных-источнику в новом первичном объекте.
  • Определите и при необходимости создайте имена входа, которые должны присутствовать в master базе данных на новом сервере-источнике, и убедитесь, что эти имена входа имеют соответствующие разрешения в master базе данных, если таковые имеются.
  • Задокументируйте конфигурацию аудита на текущем первичном сервере и сделайте ее идентичной в дополнительном экземпляре.

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

Дополнительные сведения см. в следующих статьях: