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

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

  • Статья

Применимо к: База данных SQL Azure

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

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

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

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

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

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

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

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

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

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

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

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

Подготовка вторичных систем к перебоям

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

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

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