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

  • Статья

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

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

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

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

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

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

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

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

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

Список проверка аварийного восстановления

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

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

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

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

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

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

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