Контрольный список высокого уровня доступности и аварийного восстановления — Azure SQL Managed Instance

Применимо к:Azure SQL Managed Instance

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

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

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

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

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

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

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

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

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

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

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

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

Подготовьте резервный компонент для перебоя в работе

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

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

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

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

  • Last updated on