Общие сведения и рекомендации для групп автоматической отработки отказа (База данных SQL Azure)

Область применения: База данных SQL Azure

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

Чтобы приступить к работе, ознакомьтесь со статьей Настройка группы автоматической отработки отказа. Подробное описание действий см. в статье Руководство по использованию групп автоматической отработки отказа.

Примечание

  • В этой статье рассматриваются группы автоматической отработки отказа для Базы данных SQL Azure. Для Управляемого экземпляра SQL Azure см. раздел Группы автоматической отработки отказа в Управляемом экземпляре SQL Azure.
  • Группы автоматической отработки отказа поддерживают георепликацию всех баз данных в группе только в один сервер-получатель в другом регионе. Если вам нужно создать несколько вторичных реплик на основании географического расположения Базы данных SQL Azure (в одном или разных регионах) для одной и той же первичной реплики, используйте активную георепликацию.

Обзор

Группы автоматической отработки отказа позволяют управлять репликацией и отработкой отказа группы баз данных на сервере или всех баз данных в управляемом экземпляре в другой регион Azure. Эта декларативная абстракция функции активной георепликации упрощает развертывание и администрирование геореплицируемых баз данных в большом масштабе.

Автоматическая отработка отказа

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

Разгрузка рабочих нагрузок, доступных только для чтения

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

Перенаправление конечных точек

Группы автоматической отработки отказа предоставляют конечные точки прослушивателей только для чтения и для чтения и записи, которые во время отработки отказа с георепликацией не изменяются. Это означает, что вам не нужно изменять строку подключения для приложения после отработки отказа с георепликацией, так как подключения будут автоматически перенаправлены в текущую базу данных-источник. Независимо от того, используете ли вы активацию вручную или автоматическую активацию отработки отказа, отработка отказа с георепликацией переключит все базы данных-получатели в группе на роль источника. После выполнения отработки отказа с георепликацией запись DNS автоматически обновляется, чтобы перенаправить конечные точки в новый регион. Сведения о RPO и RTO отработки отказа с георепликацией можно найти в статье, которая содержит обзор обеспечения непрерывности бизнес-процессов.

Восстановление приложения

Добавление избыточности баз данных между регионами — только часть решения для достижения полноценной непрерывности бизнес-процессов. Для комплексного восстановления приложения (службы) после катастрофического сбоя необходимо восстановить все компоненты, из которых состоит служба и все зависимые службы. К примерам этих компонентов относятся клиентское программное обеспечение (например, браузер с пользовательским кодом JavaScript), интерфейсные веб-серверы, хранилище и DNS. Очень важно, чтобы все компоненты были устойчивы к одинаковым сбоям и становились доступными в соответствии с целевым временем восстановления (RTO) вашего приложения. Следовательно, необходимо определить все зависимые службы и получить сведения о гарантиях и возможностях, которые они предоставляют. Затем необходимо выполнить соответствующие действия, чтобы обеспечить работу службы во время отработки отказа служб, от которых она зависит.

Терминология и возможности

  • Группа отработки отказа (FOG)

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

    Важно!

    Имя группы отработки отказа должно быть глобально уникальным в пределах .database.windows.net домена.

  • Серверы

    Некоторые или все пользовательские базы данных с одного логического сервера можно разместить в одной группе отработки отказа. Также сервер поддерживает несколько групп отработки отказа на одном сервере.

  • Источник

    Сервер, на котором размещаются базы данных-источники в группе отработки отказа.

  • Получатель

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

  • Добавление отдельных баз данных в группу отработки отказа

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

    Важно!

    Убедитесь, что у сервера-получателя нет базы данных с тем же именем, если она не является существующей базой данных-получателем.

  • Добавление баз данных в эластичный пул в группе отработки отказа

    Вы можете разместить несколько баз данных или их все в эластичном пуле в одну группу отработки отказа. Если база данных-источник расположена в эластичном пуле, в нем автоматически создается база данных-получатель с тем же именем (вторичный пул). Необходимо убедиться, что сервер-получатель содержит эластичный пул с тем же именем и имеет достаточную емкость для размещения баз данных-получателей, которые будут созданы группой отработки отказа. Если вы добавите базу данных в пул, у которого уже есть база данных-получатель на вторичном пуле, эта ссылка на георепликацию наследуется группой. Во время добавления базы данных, у которой уже есть база данных-получатель на сервере, которая не является частью группы отработки отказа, в этом вторичном пуле будет создана новая база данных-получатель.

  • Прослушиватель чтения и записи для группы отработки отказа

    Запись DNS CNAME, которая указывает на текущий источник. Она создается автоматически при создании группы отработки отказа и позволяет рабочим нагрузкам чтения и записи прозрачно повторно подключаться к первичной базе данных, когда исходник изменяется после отработки отказа. При создании группы отработки отказа на сервере запись CNAME DNS для прослушивателя для URL-адреса формируется следующим образом: <fog-name>.database.windows.net.

  • Прослушиватель только для чтения для группы отработки отказа

    Запись CNAME DNS, которая указывает на текущий получатель. Она создается автоматически при создании группы отработки отказа и позволяет рабочей нагрузке SQL только для чтения прозрачно подключаться к базе данных-получателю, когда получатель изменяется после отработки отказа. При создании группы отработки отказа на сервере запись CNAME DNS для прослушивателя для URL-адреса формируется следующим образом: <fog-name>.secondary.database.windows.net.

  • Несколько групп отработки отказа

    Вы можете настроить несколько групп отработки отказа для одной пары серверов, чтобы управлять масштабом отработок отказа с георепликацией. Каждая группа выполняет отработку отказа независимо от других групп. Если ваше приложение типа "клиент на базу данных" развернуто в нескольких регионах и использует эластичные пулы, вы можете воспользоваться этой возможностью, чтобы объединить базу данных-источник и базу данных-получатель в каждом пуле. Таким образом вы сможете сузить влияние простоя на некоторые базы данных клиента.

  • Политика автоматической отработки отказа

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

    Примечание

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

  • Политика отработки отказа только для чтения

    По умолчанию группа отработки отказа только для чтения отключена. Это гарантирует, что производительность базы данных-источника не изменится, если база данных-получателя отключена. Тем не менее, это также означает, что невозможно будет активировать сеансы только для чтения, пока база данных-получателя не восстановится. Если вас не устраивает время простоя для сеансов с доступом только для чтения и можете использовать базу данных-исходник для режима только для чтения, а также для режима чтения и записи трафика за счет возможного замедления производительности исходника, вы можете включить отработку отказа для прослушивателя с доступом только для чтения, настроив AllowReadOnlyFailoverToPrimary свойство. В таком случае трафик только для чтения будет автоматически перенаправляться на исходник, если получатель недоступен.

    Примечание

    Свойство AllowReadOnlyFailoverToPrimary действует, только если включена политика автоматической отработки отказа и активирована автоматическая отработка отказа с георепликацией. В этом случае, если свойство имеет значение true, новая база данных-исходник будет обслуживать сеансы для чтения и записи и сеансы только для чтения.

  • Плановая отработка отказа

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

    • Тестирование аварийного восстановления (DR) в рабочей среде в случае, если потеря данных неприемлема
    • Перемещение баз данных в другой регион.
    • Возвращение баз данных в основной регион после устранения сбоя (восстановление размещения)

    Примечание

    Если база данных содержит объекты OLTP в памяти, базы данных-источник и целевые базы данных геореплик должны иметь соответствующие уровни служб, так как объекты OLTP в памяти всегда гидратируются в памяти. Более низкий уровень служб в целевой базе данных геореплики может привести к проблемам с нехваткой памяти. В этом случае затронутая реплика базы данных геореплики-получателя может быть переведена в ограниченный режим только для чтения, называемый режимом только контрольных точек в памяти OLTP . Табличные запросы только для чтения разрешены, но только для чтения в памяти табличные запросы OLTP запрещены в затронутой реплике базы данных геореплики-получателя. Плановая отработка отказа блокируется, если все реплики в базе данных-получателе геореплик находятся в режиме только контрольных точек. Внеплановая отработка отказа может завершиться сбоем из-за нехватки памяти. Чтобы избежать этого, обновите уровень служб базы данных-получателя в соответствии с базой данных-источником во время плановой отработки отказа или детализации. Обновление уровня служб может быть операцией с размером данных и может занять некоторое время.

  • Внеплановая отработка отказа

    При незапланированном или принудительном переходе на другой ресурс роль получателя автоматически изменяется на роль источника, еще до распространения последних изменений из источника. Эта операция может привести к потере данных. Незапланированная отработка отказа используется в качестве метода восстановления при сбоях, когда база данных-источник недоступна. После устранения сбоя прежний источник автоматически подключиться снова и станет новым получателем. Запланированную отработку отказа можно выполнить для восстановления размещения, чтобы вернуть репликам их исходные роли источника и получателя.

  • Отработка отказа вручную

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

  • Льготный период с потерей данных

    Так как данные реплицируются в базу данных-получатель путем асинхронной репликации, автоматическая отработка отказа с георепликацией может привести к потере данных. Вы можете настроить политику автоматической отработки отказа с учетом допустимости приложения к потере данных. Настраивая GracePeriodWithDataLossHours, вы можете управлять продолжительностью периода ожидания системы перед последующим запуском принудительного перехода на другой ресурс, который может привести к потере данных.

Архитектура группы отработки отказа

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

Группы автоматической отработки отказа должны быть настроены на сервере-источнике и подключены к серверу-получателю в другом регионе Azure. Группы могут содержать все или некоторые базы данных на этих серверах. На следующей схеме показана типичная конфигурация геоизбыточного облачного приложения, использующего несколько баз данных и активную георепликацию.

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

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

Сведения об использовании восстановления до точки во времени с группами отработки отказа см. в разделе Восстановление до точки во времени (PITR).

Начальное заполнение

При добавлении баз данных или эластичных пулов в группу отработки отказа перед началом репликации данных осуществляется начальное заполнение. Начальная фаза заполнения — это самая продолжительная и дорогостоящая операция. После завершения первоначального заполнения данные синхронизируются, а затем реплицируются только последующие изменения данных. Время, необходимое для завершения начального заполнения, зависит от объема данных, количества реплицируемых баз данных, нагрузки на базу данных-источник и скорости связи между источником и получателем. В нормальных обстоятельствах возможная скорость заполнения составляет до 500 ГБ в час для Базы данных SQL. Заполнение выполняется для всех баз данных в параллельном режиме.

Использование нескольких групп отработки отказа для отработки отказа нескольких баз данных

Вы можете создать одну или несколько групп отработки отказа между двумя серверами в различных регионах (для основного сервера и сервера-получателя). Каждая группа может содержать одну или несколько баз данных, которые восстанавливаются единым блоком в случае, когда все или часть баз данных-источников становятся недоступными из-за сбоя в основном регионе. При создании группа отработки отказа создает базу данных-получатель в дополнительном географическом регионе с таким же целевым уровнем служб, который указан для базы данных-источника. При добавлении существующей связи георепликации к группе отработки отказа убедитесь, что дополнительный экземпляр с георепликацией настроен с тем же уровнем служб и объемом вычислительных ресурсов, что и первичный экземпляр.

Использование прослушивателя для чтения и записи (источник)

Для рабочих нагрузок для чтения и записи используйте в качестве имени сервера в строке подключения <fog-name>.database.windows.net. Подключения автоматически направляются к источнику. Это имя не будет изменяться после отработки отказа. Обратите внимание на то, что отработка отказа включает в себя обновление DNS-записи, поэтому клиентские подключения будут перенаправляться на новый сервер-источник только после обновления кэша DNS на стороне клиента. Время жизни (TTL) записи DNS прослушивателя источника и получателя составляет 30 секунд.

Использование прослушивателя только для чтения (получатель)

Если у вас есть логически изолированные рабочие нагрузки, предназначенные только для чтения и устойчивые к задержкам данных, вы можете запускать их в дополнительном экземпляре с георепликацией. Для сеансов только для чтения используйте в качестве имени сервера в строке подключения <fog-name>.secondary.database.windows.net. Подключения автоматически направляются к дополнительному экземпляру с георепликацией. Кроме того, мы рекомендуем указать режим только для чтения прямо в строке подключения, используя ApplicationIntent=ReadOnly.

На уровнях Premium, критически важном для бизнеса и гипермасштабирования база данных SQL поддерживает использование реплик только для чтения для балансировки рабочих нагрузок запросов только для чтения, используя ApplicationIntent=ReadOnly параметр в строке подключения. После настройки дополнительного экземпляра с георепликацией вы можете использовать эту возможность для соединения с репликой только для чтения в основном расположении или в геореплицированном расположении:

  • Для подключения к реплике только для чтения в дополнительном расположении используйте ApplicationIntent=ReadOnly и <fog-name>.secondary.database.windows.net.

Потенциальное замедление после отработки отказа

Типичное приложение Azure использует несколько служб Azure и состоит из нескольких компонентов. Автоматическая отработка отказа с георепликацией группы отработки отказа активируется только в зависимости от состояния компонентов Azure SQL. На другие службы Azure в основном регионе может не влиять сбой, и их компоненты могут по-прежнему быть доступны в этом регионе. Когда базы данных-источники переключаются во вторичный регион (DR), задержка между зависимыми компонентами может увеличиться. Чтобы избежать влияния более продолжительных задержек на производительность приложения, обеспечьте избыточность всех компонентов приложения в регионе DR, следуя этим рекомендациям по защите сети, а также выполните оркестрацию отработки отказа с георепликацией соответствующих компонентов приложения вместе с базой данных.

Потенциальная потеря данных после отработки отказа

Если в основном регионе возникает сбой, недавние транзакции могут не реплицироваться в дополнительный экземпляр с георепликацией. Если настроить политику автоматической отработки отказа, система будет ожидать указанный вами период (GracePeriodWithDataLossHours), прежде чем инициировать отработку отказа с георепликацией. Значение этого свойства по умолчанию – 1 час. При этом предпочтение отдается доступности базы данных, а не отсутствию потери данных. Если задать для параметра GracePeriodWithDataLossHours большее значение, например 24 часов, или отключить автоматическую отработку отказа с георепликацией, вы сможете снизить вероятность потери данных за счет доступности базы данных.

Важно!

Эластичные пулы с 800 единицами передачи данных (или менее) или 8 виртуальными ядрами (или менее), а также более чем 250 базами данных могут испытывать проблемы, в том числе сталкиваться с более длительными плановыми операциями отработки отказа с георепликацией и снижением производительности. Эти проблемы чаще всего возникают из-за рабочих нагрузок, интенсивно записывающих данные, если геореплики физически находятся далеко друг от друга или если используется несколько дополнительных геореплик для каждой базы данных. Симптомом этих проблем является увеличение задержки георепликации с течением времени, что потенциально может привести к более масштабной потере данных в случае сбоя. Эту задержку можно отслеживать с помощью sys.dm_geo_replication_link_status. Если такие проблемы возникают, то меры по их устранению включают масштабирование пула для увеличения количества единиц передачи данных или виртуальных ядер, или уменьшение количества геореплицированных баз данных в пуле.

Группы отработки отказа и сетевая безопасность

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

Использование групп отработки отказа и конечных точек службы для виртуальной сети

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

  1. Подготовьте избыточные копии интерфейсных компонентов приложения (веб-службы, виртуальные машины и т. д.) в дополнительном регионе.
  2. Настройте правила виртуальной сети по отдельности для основного и дополнительного сервера.
  3. Включите отработку отказа внешнего интерфейса с помощью конфигурации диспетчера трафика.
  4. Инициируйте отработку отказа с георепликацией вручную при обнаружении сбоя. Этот параметр оптимизирован для приложений, требующих последовательной задержки между внешним интерфейсом и уровнем данных, и поддерживает восстановление после сбоя внешнего интерфейса уровня данных или их обоих.

Примечание

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

Использование групп отработки отказа и правил брандмауэра

Если для плана обеспечения непрерывности бизнес-процессов требуется отработка отказа с помощью групп с автоматическим переходом на другой ресурс, можно ограничить доступ к Базе данных SQL с помощью правил брандмауэра для общедоступных IP-адресов. Для поддержки автоматического перехода на другой ресурс выполните следующие действия:

  1. создайте общедоступный IP-адрес;
  2. создайте общедоступный балансировщик нагрузки и назначьте ему общедоступный IP-адрес;
  3. создайте виртуальную сеть и виртуальные машины для интерфейсных компонентов;
  4. создайте группу безопасности сети и настройте входящие подключения.
  5. Убедитесь, что исходящие подключения открыты для Базы данных SQL Azure в регионе с помощью Sql.<Region>тега службы.
  6. Создайте правило брандмауэра базы данных SQL, чтобы разрешить входящий трафик из общедоступного IP-адреса, созданного на этапе 1.

Дополнительные сведения о том, как настроить исходящий доступ и какой IP-адрес нужно использовать в правилах брандмауэра, см. в статье Исходящие подключения балансировки нагрузки.

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

Важно!

Для обеспечения непрерывности бизнес-процессов во время региональных сбоев должна применятся географическая избыточность интерфейсных компонентов и баз данных.

Масштабирование базы данных-источника

Вы можете вертикально увеличивать или уменьшать масштаб вычислительных ресурсов базы данных-источника с переходом на другой размер вычисления (в рамках одного уровня служб) без отключения вторичных геореплик. При этом рекомендуется сначала вертикально увеличить масштаб вторичной геореплики, а затем вертикально увеличить масштаб первичной реплики. При вертикальном уменьшении масштаба действия следует выполнять в обратном порядке: сначала для первичной реплики, затем — для вторичной реплики. Когда вы изменяете масштаб базы данных до другого уровня служб, особенно важно следовать рекомендации выше.

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

Примечание

Если вы создали дополнительный экземпляр с георепликацией как часть конфигурации группы отработки отказа, вертикально уменьшать масштаб дополнительного экземпляра с георепликацией не рекомендуется. Это необходимо, чтобы обеспечить достаточную емкость уровня данных для обработки регулярных рабочих нагрузок после отработки отказа с георепликацией.

Предотвращение потери критически важных данных

Из-за высокой задержки в глобальных сетях георепликация использует механизм асинхронной репликации. Асинхронная репликация делает неизбежной возможность потери данных при отказе первичной реплики. Чтобы защитить эти критические транзакции от потери данных, разработчик приложения может вызвать хранимую процедуру sp_wait_for_database_copy_sync сразу же после фиксации транзакции. Вызов sp_wait_for_database_copy_sync блокирует вызывающий поток, пока последняя зафиксированная транзакция не будет передана и журнал транзакций базы данных-получателя и зафиксирована в нем. Но вызов не дожидается воспроизведения (повторной обработки) транзакций в базе данных-получателе. Областью действия процедуры sp_wait_for_database_copy_sync является определенная связь георепликации. Эту процедуру может вызвать любой пользователь с правами подключения к базе данных-источнику.

Примечание

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

Разрешения

Управление разрешениями для группы отработки отказа осуществляется с помощью управления доступом на основе ролей Azure (Azure RBAC).

Доступ на запись в Azure RBAC необходим для создания групп отработки отказа и управления ими. Роль Участник SQL Server имеет все необходимые разрешения для управления группами отработки отказа.

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

Ограничения

Следует учитывать следующие ограничения.

  • Группы отработки отказа не могут быть созданы между двумя серверами в одном регионе Azure.
  • Невозможно переименовать группы отработки отказа. Необходимо удалить группу и создать ее повторно с другим именем.
  • Переименование базы данных не поддерживается для баз данных в группе отработки отказа. Чтобы переименовать базу данных или удалить базу данных из группы отработки отказа, вам потребуется временно удалить саму группу отработки отказов.

Программное управление группами отработки отказа

Как уже говорилось ранее, группами автоматической отработки отказа можно также управлять программно с помощью Azure PowerShell, Azure CLI и REST API. В приведенных ниже таблицах описан доступный для этого набор команд. Активная георепликация включает в себя набор API-интерфейсов Azure Resource Manager для управления, в том числе REST API Базы данных SQL Azure и командлеты Azure PowerShell. Для этих API требуется использование групп ресурсов и поддержка управления доступом на основе ролей в Azure (Azure RBAC). Дополнительные сведения о том, как реализовать контроль доступа на основе ролей, см. в статье Управление доступом на основе ролей (Azure RBAC).

Командлет Описание
New-AzSqlDatabaseFailoverGroup Создает группу отработки отказа и регистрирует ее на основном сервере и сервере-получателе.
Remove-AzSqlDatabaseFailoverGroup Удаляет группу отработки отказа с сервера
Get-AzSqlDatabaseFailoverGroup Извлекает конфигурацию группы отработки отказа
Set-AzSqlDatabaseFailoverGroup Изменяет конфигурацию отказоустойчивого кластера
Switch-AzSqlDatabaseFailoverGroup Запускает отработку отказа группы отработки отказа на сервер-получатель
Add-AzSqlDatabaseToFailoverGroup Добавляет одну или несколько баз данных в группу отработки отказа

Дальнейшие действия