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

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

  • Включите группы отработки отказа для группы баз данных.
    • Используйте конечные точки прослушивателя только для чтения и чтения в приложении строка подключения поэтому приложения автоматически подключаются к каждому серверу и базе данных текущей первичной.
    • Задайте политику отработки отказа управляемым клиентом.
  • Кроме того, группы отработки отказа можно включить активную георепликацию , чтобы иметь доступную для чтения базу данных-получатель в другом регионе Azure.
  • Убедитесь, что база данных георепликации создается с тем же уровнем служб, вычислительным уровнем (подготовленным или бессерверным) и размером вычислительных ресурсов (DTU или виртуальными ядрами) в качестве базы данных-источника.
  • При увеличении масштаба сначала масштабируйте геоторичную, а затем масштабируйте основной объект.
  • При вертикальном уменьшении масштаба действия следует выполнять в обратном порядке: сначала для первичной реплики, затем — для вторичной реплики.
  • Аварийное восстановление, по сути, предназначено для использования асинхронной репликации данных между основным и вторичным регионом. Чтобы определить приоритет доступности данных по сравнению с более высокой задержкой фиксации, рассмотрите возможность вызова хранимой процедуры 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 базе данных, если таковые имеются. Дополнительные сведения см. в разделе База данных SQL Azure безопасности после аварийного восстановления.
  • Определите правила генерации оповещений, которые необходимо обновить для сопоставления с новым первичным.
  • Задокументируйте конфигурацию аудита на текущем первичном сервере и сделайте ее идентичной на вторичном сервере.

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