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

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

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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Группа автоматического переключения (FOG)

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

  Внимание

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

• Основной

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

• Вторичные

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

  Внимание

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

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

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

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

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

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

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

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

• Зона DNS

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

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

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

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

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

  Примечание.

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

Архитектура группы резервирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Начальный засев

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

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

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

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

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

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

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

Если у вас есть логически изолированные рабочие нагрузки, предназначенные только для чтения и устойчивые к задержкам данных, вы можете запускать их в дополнительном экземпляре с георепликацией. Чтобы подключиться напрямую к георезервной копии, используйте в качестве имени сервера <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.

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

Возможное ухудшение производительности после переключения на резерв

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

Возможность потери данных после принудительного переключения

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

Обновление DNS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возврат к исходной системе

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

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

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

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

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

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

Рассмотрим следующий пример.

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

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

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

Базы данных, перенесенные в Управляемый экземпляр 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. Просмотрите настройку группы отказоустойчивости, чтобы узнать больше.

Тренировки по устранению последствий аварии

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

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

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

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

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

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

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

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