Общие сведения о группах отработки отказа и рекомендации — Управляемый экземпляр SQL Azure

Область применения: Управляемый экземпляр SQL Azure

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

Чтобы приступить к работе с функцией, просмотрите группу отработки отказа для Управляемый экземпляр SQL Azure.

Обзор

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

Дополнительные сведения см. в разделе "Высокий уровень доступности" для Управляемый экземпляр SQL Azure. Сведения о географической отработки отказа RPO и RTO см. в обзоре непрерывности бизнес-процессов.

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

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

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

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

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

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

Политика отработки отказа

Группы отработки отказа поддерживают две политики отработки отказа:

• Управление клиентом (рекомендуется). Клиенты могут выполнять отработку отказа группы, когда они замечают непредвиденный сбой, влияющий на одну или несколько баз данных в группе отработки отказа. При использовании таких средств командной строки, как PowerShell, Azure CLI или Rest API, значение политики отработки отказа для управляемого клиентом manualзначения политики отработки отказа.
• Управление Майкрософт. В случае распространенного сбоя, влияющего на основной регион, корпорация Майкрософт инициирует отработку отказа всех затронутых групп отработки отказа, для которых настроена политика управления Майкрософт. Отработка отказа под управлением Майкрософт не будет инициирована для отдельных групп отработки отказа или подмножества групп отработки отказа в регионе. При использовании таких средств командной строки, как PowerShell, Azure CLI или Rest API, значение политики отработки отказа для управляемого automaticКорпорацией Майкрософт значения политики отработки отказа.

Каждая политика отработки отказа имеет уникальный набор вариантов использования и соответствующие ожидания в области отработки отказа и потере данных, как показано в следующей таблице:

Управляемые клиентом

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

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

Организуется корпорацией Майкрософт

С помощью политики управляемой отработки отказа Майкрософт ответственность за аварийное восстановление делегирована службе SQL Azure. Чтобы служба SQL Azure начала принудительной отработки отказа, должны выполняться следующие условия:

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

При выполнении этих условий служба SQL Azure инициирует принудительные отработки отказа для всех групп отработки отказа в регионе, для которых задана политика отработки отказа, управляемая Корпорацией Майкрософт.

Установите политику отработки отказа корпорацией Майкрософт, управляемую только в следующих случаях:

• Вы хотите делегировать ответственность за аварийное восстановление службе SQL Azure.
• Приложение терпимо к базе данных недоступно по крайней мере за один час или более.
• Можно активировать принудительные отработки отказа некоторое время после истечения льготного периода, так как фактическое время принудительной отработки отказа может значительно отличаться.
• Приемлемо, что все базы данных в группе отработки отказа выполняют отработку отказа независимо от конфигурации избыточности зоны или состояния доступности. Хотя базы данных, настроенные для избыточности зоны, устойчивы к зональным сбоям и могут не влиять на сбой, они по-прежнему будут отработки отказа, если они являются частью группы отработки отказа с политикой управляемой отработки отказа Майкрософт.
• Принудительная отработка отказа баз данных в группе отработки отказа не учитывает зависимость приложения от других служб Или компонентов Azure, используемых приложением, что может привести к снижению производительности или недоступности приложения.
• Это приемлемо для неизвестного объема потери данных, так как точное время принудительной отработки отказа невозможно контролировать, и игнорирует состояние синхронизации баз данных-получателей.
• Все базы данных-источник и вторичные базы данных в группе отработки отказа и все связи георепликации имеют один уровень служб, уровень вычислений (подготовленный или бессерверный) и размер вычислительных ресурсов (DTU или виртуальные ядра). Если цель уровня обслуживания (SLO) всех баз данных не совпадает, политика отработки отказа в конечном итоге будет обновлена из службы SQL Microsoft Managed to Customer Managed by Azure SQL.

Когда отработка отказа активируется корпорацией Майкрософт, в журнал действий Azure Monitor добавляется запись для имени операции отработки отказа Azure SQL. Запись содержит имя группы отработки отказа в разделе "Ресурс" и событие, инициированное отображением одного дефиса (-), чтобы указать, что отработка отказа была инициирована корпорацией Майкрософт. Эти сведения также можно найти на странице журнала действий нового сервера-источника или экземпляра в портал Azure.

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

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

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

  Внимание

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

• Источник

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

• Вторичные

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

  Внимание

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

• Отработка отказа (без потери данных)

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

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

• Принудительное отработка отказа (потенциальная потеря данных)

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

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

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

• Зона DNS

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

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

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

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

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

  Примечание.

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

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

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

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

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

Создание гео вторичного экземпляра

Чтобы обеспечить непрерывное подключение к основному Управляемый экземпляр SQL после отработки отказа, первичные и вторичные экземпляры должны находиться в одной зоне DNS. Это гарантирует, что один и тот же сертификат с несколькими доменами (SAN) можно использовать для проверки подлинности клиентских подключений к одному из двух экземпляров в группе отработки отказа. Когда приложение готово к развертыванию в рабочей среде, создайте вторичную Управляемый экземпляр SQL в другом регионе и убедитесь, что она использует зону DNS с основным Управляемый экземпляр SQL. Это можно сделать, указав необязательный параметр во время создания. Если вы используете PowerShell или REST API, это имя необязательного параметра DNSZonePartner. Имя соответствующего необязательного поля на портале Azure — Первичный управляемый экземпляр.

Дополнительные сведения о создании вторичных Управляемый экземпляр SQL в той же зоне DNS, что и основной экземпляр, см. в разделе "Настройка группы отработки отказа для Управляемый экземпляр SQL Azure".

Использование сопряженных регионов

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

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

В ситуациях, когда Управляемый экземпляр SQL Azure входит в группу отработки отказа, а экземпляры в группе не входят в парные регионы Azure, выберите разные расписания периода обслуживания для базы данных-источника и вторичной базы данных. Например, выберите окно обслуживания weekday для базы данных гео-вторичной базы данных и периода обслуживания выходных данных для гео-первичной базы данных.

Включение и оптимизация потока трафика георепликации между экземплярами

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

• Пиринг глобальной виртуальной сети
• VPN-шлюзы
• Azure ExpressRoute

Пиринг глобальной виртуальной сети (пиринг виртуальной сети) — это рекомендуемый способ установить подключение между двумя экземплярами в группе отработки отказа. Он обеспечивает частное подключение с низкой задержкой и высокой пропускной способностью между пиринговыми виртуальными сетями с помощью инфраструктуры магистральной сети Майкрософт. В обмене данными между пиринговых виртуальных сетей не требуется общедоступный Интернет, шлюзы или дополнительное шифрование.

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

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

Если скорость связи между двумя экземплярами медленнее, чем необходимо, время начального значения, вероятно, будет заметно затронуто. Вы можете использовать указанные скорость заполнения, число баз данных, общий размер данных и скорость связи, чтобы определить, как долго будет выполняться начальная фаза заполнения перед началом репликации данных. Например, для одной базы данных размером 100 ГБ начальная фаза начального значения займет около 1,2 часа, если ссылка способна отправлять 84 ГБ в час, и если другие базы данных не заполняются. Если ссылка может передавать только 10 ГБ в час, то время заполнения базы данных размером 100 ГБ может занять около 10 часов. Если существует несколько баз данных для репликации, заполнение будет выполняться параллельно, и при сочетании со скоростью медленной связи начальная фаза заполнения может занять значительно больше времени, особенно если параллельное заполнение данных из всех баз данных превышает доступную пропускную способность канала.

Управление отработкой отказа с георепликацией на дополнительном экземпляре с георепликацией

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

Использование прослушивателя, доступного для чтения и записи (основной Управляемый экземпляр)

Для рабочих нагрузок для чтения и записи используйте в качестве имени сервера <fog-name>.zone_id.database.windows.net. Подключения автоматически направляются к первичному объекту. Это имя не изменяется после отработки отказа. Геоработка отказа включает обновление записи DNS, поэтому новые клиентские подключения направляются в новый первичный только после обновления кэша DNS клиента. Клиентское приложение сможет повторно подключиться к серверу-источнику, используя тот же сертификат SAN на стороне сервера, поскольку экземпляры первичного и вторичного экземпляра используют общую DNS-зону. Существующие клиентские подключения необходимо завершить, а затем повторно перенаправить на новый первичный объект. Прослушиватель чтения и прослушиватель только для чтения не может быть достигнут через общедоступную конечную точку для управляемого экземпляра.

Использование прослушивателя, доступных только для чтения (вторичный Управляемый экземпляр)

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

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

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

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

Возможное замедление после отработки отказа

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

Возможность потери данных после принудительной отработки отказа

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

Обновление DNS

После запуска отработки отказа DNS обновления прослушивателя чтения и записи произойдут автоматически. Эта операция не приведет к потере данных. Однако процесс смены ролей баз данных в обычных условиях может занять до 5 минут. До завершения некоторые базы данных в новом первичном экземпляре по-прежнему будут доступны только для чтения. Если отработка отказа инициируется с помощью PowerShell, операция переключения первичной реплики выполняется синхронно. Если он инициируется с помощью портал Azure, пользовательский интерфейс указывает состояние завершения. Если он инициируется с помощью REST API, используйте стандартный механизм опроса Azure Resource Manager для отслеживания завершения.

Экономия затрат с помощью реплики аварийного восстановления без лицензии

Вы можете сэкономить на затратах на лицензию SQL Server, настроив дополнительный управляемый экземпляр, который будет использоваться только для аварийного восстановления (DR). Сведения о настройке см. в статье "Настройка резервной реплики без лицензии" для Управляемый экземпляр SQL Azure.

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

Включение сценариев, зависящих от объектов из системных баз данных

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

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

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Дополнительные сведения см. в статье Репликация имен входа и заданий агента.

Синхронизация свойств экземпляра и политик хранения

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

Масштабирование экземпляров

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

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

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

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

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

Состояние группы отработки отказа

Группа отработки отказа сообщает о своем состоянии, описывая текущее состояние репликации данных:

• Начальное заполнение — начальное заполнение выполняется после создания группы отработки отказа до тех пор, пока не будут инициализированы все пользовательские базы данных на дополнительном экземпляре. Процесс отработки отказа не может быть инициирован, пока группа отработки отказа находится в состоянии начального заполнения, так как пользовательские базы данных еще не копируются в вторичный экземпляр.
• Синхронизация — обычное состояние группы отработки отказа. Оно означает, что изменения данных на первичном экземпляре асинхронно реплицируются на дополнительный экземпляр. Это состояние не гарантирует, что данные полностью синхронизированы в каждый момент времени. Могут быть изменения данных из первичного компонента, которые по-прежнему должны быть реплицированы на вторичный из-за асинхронной природы процесса репликации между экземплярами в группе отработки отказа. Автоматические и вручную отработки отказа можно инициировать, пока группа отработки отказа находится в состоянии синхронизации.
• Выполняется отработка отказа — это состояние указывает, что в текущий момент выполняется автоматический или инициированный вручную процесс отработки отказа. Изменения в группе отработки отказа или дополнительных отработках отказа не могут быть инициированы, пока группа отработки отказа находится в этом состоянии.

Восстановление размещения

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

Взаимодействие функций

Резервные копии

Полная резервная копия выполняется в следующих сценариях:

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

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

Служба воспроизведения журналов

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

Репликация транзакций

Использование репликации транзакций с экземплярами, которые находятся в группе отработки отказа, поддерживается. Однако при настройке репликации перед добавлением управляемого экземпляра SQL в группу отработки отказа репликация приостанавливается при запуске создания группы отработки отказа, а монитор репликации показывает состояние Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Репликация возобновляется после успешного создания группы отработки отказа.

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

Разрешения и ограничения

Просмотрите список разрешений и ограничений перед настройкой группы отработки отказа.

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

Группами отработки отказа также можно управлять программными средствами с помощью Azure PowerShell, Azure CLI и REST API. Дополнительные сведения см . в статье о настройке группы отработки отказа.

Отработка аварийного восстановления

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

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

• Рабочая нагрузка останавливается на основном управляемом экземпляре.
• Все длительные транзакции завершены.
• Все клиентские подключения к основному управляемому экземпляру были отключены.
• Состояние группы отработки отказа — "Синхронизация".

Убедитесь, что два управляемых экземпляра переключили роли и что состояние группы отработки отказа переключилось с "Отработка отказа выполняется" на "Синхронизация", прежде чем при необходимости устанавливать подключения к новому основному управляемому экземпляру и запускать рабочую нагрузку чтения и записи.

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

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

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

• Настройка группы отработки отказа
• Добавление управляемого экземпляра в группу отработки отказа с помощью PowerShell
• Настройка резервной реплики без лицензии для Управляемый экземпляр SQL Azure
• Общие сведения об обеспечении непрерывности бизнес-процессов с помощью Управляемого экземпляра Azure SQL
• Автоматическое резервное копирование в Управляемый экземпляр SQL Azure
• Восстановление базы данных из резервной копии в Управляемый экземпляр SQL Azure