Использование групп автоматической отработки отказа для включения прозрачной и согласованной отработки отказа в нескольких базах данныхUse auto-failover groups to enable transparent and coordinated failover of multiple databases

Группы автоматической отработки отказа — это функция базы данных SQL, которая позволяет управлять репликацией и отработкой отказа группы баз данных на сервере базы данных SQL или всех базах данных в управляемом экземпляре в другом регионе.Auto-failover groups is a SQL Database feature that allows you to manage replication and failover of a group of databases on a SQL Database server or all databases in a managed instance to another region. Это декларативная абстракция поверх существующей функции активной георепликации , предназначенной для упрощения развертывания геореплицируемых баз данных и управления ими в масштабе.It is a declarative abstraction on top of the existing active geo-replication feature, designed to simplify deployment and management of geo-replicated databases at scale. Вы можете запустить отработку отказа вручную или делегировать службе Базы данных SQL, используя определяемую пользователем политику.You can initiate failover manually or you can delegate it to the SQL Database service based on a user-defined policy. Последний вариант позволяет автоматически восстановить несколько связанных баз данных в дополнительном регионе после катастрофических сбоев или других незапланированных событий, которые приводят к полной или частичной потере доступности службы Базы данных SQL в основном регионе.The latter option allows you to automatically recover multiple related databases in a secondary region after a catastrophic failure or other unplanned event that results in full or partial loss of the SQL Database service’s availability in the primary region. Группа отработки отказа может включать одну или несколько баз данных, обычно используемых одним приложением.A failover group can include one or multiple databases, typically used by the same application. Кроме того, клиенты могут использовать доступные для чтения базы данных-получатели для разгрузки рабочих нагрузок запросов, доступных только для чтения.Additionally, you can use the readable secondary databases to offload read-only query workloads. Так как группы автоматической отработки отказа включают в себя несколько баз данных, базы данных необходимо настроить на сервере-источнике.Because auto-failover groups involve multiple databases, these databases must be configured on the primary server. Группы автоматической отработки отказа поддерживают репликацию всех баз данных в группе только на один сервер-получатель в другом регионе.Auto-failover groups support replication of all databases in the group to only one secondary server in a different region.

Примечание

Если при работе с отдельными базами данных или с базами данных в пуле на сервере базы данных SQL вы хотите создать несколько вторичных реплик в одном или в разных регионах, используйте активную георепликацию.When working with single or pooled databases on a SQL Database server and you want multiple secondaries in the same or different regions, use active geo-replication.

Во время работы с группами автоматической отработки отказа с политикой автоматической отработки отказа любой сбой, который влияет на одну или на несколько баз данных в группе, приведет к автоматической отработке отказа.When you are using auto-failover groups with automatic failover policy, any outage that impacts one or several of the databases in the group results in automatic failover. Обычно это инциденты, которые невозможно устранить самостоятельно с помощью встроенных автоматических операций высокой доступности.Typically these are incidents that cannot be self-mitigated by the built-in automatic high availability operations. Примеры триггеров отработки отказа включают в себя инцидент, вызванный кругом клиентов SQL или контрольным кольцом, из-за утечки памяти ядра операционной системы на нескольких службах вычислений или инцидента, вызванного неисправностью одного или нескольких звонков клиента, так как в процессе ro был вырезан Недопустимый сетевой кабель. утине аппаратное списание.The examples of failover triggers include an incident caused by a SQL tenant ring or control ring being down due to an OS kernel memory leak on several compute nodes, or an incident caused by one or more tenant rings being down because a wrong network cable was cut during routine hardware decommissioning. Дополнительные сведения см. в статье Высокая доступность базы данных SQL.For more information, see SQL Database High Availability.

Кроме того, группы автоматической отработки отказа предоставляют конечные точки прослушивателя только для чтения и для чтения-записи, которые во время отработки отказа не изменяются.In addition, auto-failover groups provide read-write and read-only listener end-points that remain unchanged during failovers. Независимо от того, используете ли вы активацию вручную или автоматическую активацию отработки отказа, отработка отказа переключит все базы данных-получатели в группе в базу данных-источник.Whether you use manual or automatic failover activation, failover switches all secondary databases in the group to primary. После выполнения автоматической отработки отказа базы данных запись DNS автоматически обновляется, чтобы перенаправить конечные точки в новый регион.After the database failover is completed, the DNS record is automatically updated to redirect the endpoints to the new region. Конкретные сведения о RPO и RTO можно найти в обзоре обеспечения непрерывности бизнес-процессов.For the specific RPO and RTO data, see Overview of Business Continuity.

Во время работы с группами автоматической отработки отказа с политикой автоматической отработки отказа любой сбой, который влияет на базы данных на сервере Базы данных SQL или в управляемом экземпляре, приведет к автоматической отработки отказа.When you are using auto-failover groups with automatic failover policy, any outage that impacts databases in the SQL Database server or managed instance results in automatic failover. Управляйте группами автоматической отработки отказа используя:You can manage auto-failover group using:

После отработки отказа убедитесь, что для новой базы данных-источника настроены требования аутентификации ваших сервера и базы данных.After failover, ensure the authentication requirements for your server and database are configured on the new primary. Дополнительные сведения см. в разделе Безопасность базы данных SQL после аварийного восстановления.For details, see SQL Database security after disaster recovery.

Добавление избыточности баз данных между центрами обработки данных — только часть решения для достижения настоящей непрерывности бизнес-процессов.To achieve real business continuity, adding database redundancy between datacenters is only part of the solution. Для комплексного восстановления приложения (службы) после катастрофического сбоя необходимо восстановить все компоненты, из которых состоит служба и все зависимые службы.Recovering an application (service) end-to-end after a catastrophic failure requires recovery of all components that constitute the service and any dependent services. К примерам этих компонентов относятся клиентское программное обеспечение (например, браузер с пользовательским кодом JavaScript), интерфейсные веб-серверы, хранилище и DNS.Examples of these components include the client software (for example, a browser with a custom JavaScript), web front ends, storage, and DNS. Очень важно, чтобы все компоненты были устойчивы к одинаковым сбоям и становились доступными в соответствии с целевым временем восстановления (RTO) вашего приложения.It is critical that all components are resilient to the same failures and become available within the recovery time objective (RTO) of your application. Следовательно, необходимо определить все зависимые службы и получить сведения о гарантиях и возможностях, которые они предоставляют.Therefore, you need to identify all dependent services and understand the guarantees and capabilities they provide. Затем необходимо выполнить соответствующие действия, чтобы обеспечить работу службы во время отработки отказа служб, от которых она зависит.Then, you must take adequate steps to ensure that your service functions during the failover of the services on which it depends. Дополнительные сведения о проектировании решений для аварийного восстановления см. в статье о разработке облачных решений для аварийного восстановления с помощью активной георепликации.For more information about designing solutions for disaster recovery, see Designing Cloud Solutions for Disaster Recovery Using active geo-replication.

Терминология и способности группы автоматической отработки отказаAuto-failover group terminology and capabilities

  • Группа отработки отказа (туман)Failover group (FOG)

    Группа отработки отказа — это именованная группа баз данных, управляемая одним сервером базы данных SQL или одним управляемым экземпляром, которые могут выполнять отработку отказа в другой регион в случае, если все или некоторые базы данных-получатели становятся недоступными вследствие сбоя в основном регионе.A failover group is a named group of databases managed by a single SQL Database server or within a single managed instance that can fail over as a unit to another region in case all or some primary databases become unavailable due to an outage in the primary region. При создании для управляемых экземпляров группа отработки отказа содержит все пользовательские базы данных в экземпляре, поэтому в экземпляре можно настроить только одну группу отработки отказа.When created for managed instances, a failover group contains all user databases in the instance and therefore only one failover group can be configured on an instance.

    Важно!

    Имя группы отработки отказа должно быть глобально уникальным в пределах домена .database.windows.net.The name of the failover group must be globally unique within the .database.windows.net domain.

  • Серверы Базы данных SQLSQL Database servers

    С помощью серверов Базы данных SQL можно разместить некоторые или все пользовательские базы данных с отдельного сервера Базы данных SQL в группе отработки отказа.With SQL Database servers, some or all of the user databases on a single SQL Database server can be placed in a failover group. Сервер Базы данных SQL также поддерживает несколько групп отработки отказа на отдельном сервере Базы данных SQL.Also, a SQL Database server supports multiple failover groups on a single SQL Database server.

  • ИсточникPrimary

    Сервер базы данных SQL или управляемый экземпляр, на котором размещены базы данных источника в группе отработки отказа.The SQL Database server or managed instance that hosts the primary databases in the failover group.

  • ПолучательSecondary

    Сервер базы данных SQL или управляемый экземпляр, на котором размещены базы данных-получатели в группе отработки отказа.The SQL Database server or managed instance that hosts the secondary databases in the failover group. Источники и получатели не могут находиться в одном и том же регионе.The secondary cannot be in the same region as the primary.

  • Добавление отдельных баз данных в группу отработки отказаAdding single databases to failover group

    Вы можете разместить несколько отдельных баз данных на одном сервере Базы данных SQL в одной группе отработки отказа.You can put several single databases on the same SQL Database server into the same failover group. Если вы добавите отдельную базу данных в группу отработки отказа, она автоматически создаст базу данных-получатель, используя тот же выпуск и объем вычислительных ресурсов на сервере-получателе.If you add a single database to the failover group, it automatically creates a secondary database using the same edition and compute size on secondary server. Этот сервер следует указать при создании группы отработки отказа.You specified that server when the failover group was created. Если вы добавите базу данных, у которой уже есть база данных-получатель на сервере-получателе, эта ссылка на георепликацию наследуется группой.If you add a database that already has a secondary database in the secondary server, that geo-replication link is inherited by the group. Во время добавления базы данных, у которой уже есть база данных-получатель на сервере, которая не является частью группы отработки отказа, на этом сервере-получателе будет создана новая база данных-получатель.When you add a database that already has a secondary database in a server that is not part of the failover group, a new secondary is created in the secondary server.

    Важно!

    Убедитесь, что у сервера-получателя нет базы данных с тем же именем, если она не является существующей базой данных-получателем.Make sure that the secondary server doesn't have a database with the same name unless it is an existing secondary database. В группе отработки отказа для управляемого экземпляра реплицируются все пользовательские базы данных.In failover groups for managed instance all user databases are replicated. Нельзя выбирать подмножество для репликации пользовательских баз данных в группе отработки отказа.You cannot pick a subset of user databases for replication in the failover group.

  • Добавление баз данных в эластичный пул в группе отработки отказаAdding databases in elastic pool to failover group

    Вы можете разместить несколько баз данных или их все в эластичном пуле в одну группу отработки отказа.You can put all or several databases within an elastic pool into the same failover group. Если база данных-источник расположена в эластичном пуле, в нем автоматически создается база данных-получатель с тем же именем (вторичный пул).If the primary database is in an elastic pool, the secondary is automatically created in the elastic pool with the same name (secondary pool). Необходимо убедиться, что сервер-получатель содержит эластичный пул с тем же именем и имеет достаточную емкость для размещения баз данных-получателей, которые будут созданы группой отработки отказа.You must ensure that the secondary server contains an elastic pool with the same exact name and enough free capacity to host the secondary databases that will be created by the failover group. Если вы добавите базу данных в пул, у которого уже есть база данных-получатель на вторичном пуле, эта ссылка на георепликацию наследуется группой.If you add a database in the pool that already has a secondary database in the secondary pool, that geo-replication link is inherited by the group. Во время добавления базы данных, у которой уже есть база данных-получатель на сервере, которая не является частью группы отработки отказа, в этом вторичном пуле будет создана новая база данных-получатель.When you add a database that already has a secondary database in a server that is not part of the failover group, a new secondary is created in the secondary pool.

  • Зона DNSDNS zone

    Уникальный идентификатор, который автоматически создается при создании нового экземпляра.A unique ID that is automatically generated when a new instance is created. Сертификат с несколькими доменами (SAN) для этого экземпляра подготавливается для проверки подлинности клиентских подключений к любому экземпляру в той же зоне DNS.A multi-domain (SAN) certificate for this instance is provisioned to authenticate the client connections to any instance in the same DNS zone. Два управляемых экземпляра в одной группе отработки отказа должны иметь общий доступ к зоне DNS.The two managed instances in the same failover group must share the DNS zone.

    Примечание

    Идентификатор зоны DNS не требуется для групп отработки отказа, созданных для серверов базы данных SQL.A DNS zone ID is not required for failover groups created for SQL Database servers.

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

    Запись DNS CNAME, которая указывает на текущий основной URL-адрес.A DNS CNAME record that points to the current primary's URL. Он создается автоматически при создании группы отработки отказа и позволяет рабочей нагрузке SQL для чтения и записи прозрачно повторно подключаться к базе данных-источнику при изменении основных изменений после отработки отказа.It is created automatically when the failover group is created and allows the read-write SQL workload to transparently reconnect to the primary database when the primary changes after failover. При создании группы отработки отказа на сервере базы данных SQL запись CNAME DNS для URL-адреса прослушивателя формируется как <fog-name>.database.windows.net.When the failover group is created on a SQL Database server, the DNS CNAME record for the listener URL is formed as <fog-name>.database.windows.net. При создании группы отработки отказа на управляемом экземпляре запись CNAME DNS для URL-адреса прослушивателя формируется как <fog-name>.zone_id.database.windows.net.When the failover group is created on a managed instance, the DNS CNAME record for the listener URL is formed as <fog-name>.zone_id.database.windows.net.

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

    Формируется запись DNS CNAME, которая указывает на прослушиватель только для чтения, указывающий на URL-адрес получателя.A DNS CNAME record formed that points to the read-only listener that points to the secondary's URL. Он создается автоматически при создании группы отработки отказа и позволяет рабочей нагрузке SQL только для чтения прозрачно подключаться к базе данных-получателю с помощью указанных правил балансировки нагрузки.It is created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary using the specified load-balancing rules. При создании группы отработки отказа на сервере базы данных SQL запись CNAME DNS для URL-адреса прослушивателя формируется как <fog-name>.secondary.database.windows.net.When the failover group is created on a SQL Database server, the DNS CNAME record for the listener URL is formed as <fog-name>.secondary.database.windows.net. При создании группы отработки отказа на управляемом экземпляре запись CNAME DNS для URL-адреса прослушивателя формируется как <fog-name>.zone_id.secondary.database.windows.net.When the failover group is created on a managed instance, the DNS CNAME record for the listener URL is formed as <fog-name>.zone_id.secondary.database.windows.net.

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

    По умолчанию группа отработки отказа настроена с помощью политики автоматической отработки отказа.By default, a failover group is configured with an automatic failover policy. Служба базы данных SQL запускает отработку отказа после обнаружения сбоя и истечения льготного периода.The SQL Database service triggers failover after the failure is detected and the grace period has expired. Системе необходимо убедиться, что сбой нельзя устранить с помощью встроенной инфраструктуры обеспечения высокой доступности Службы базы данных SQL из-за масштаба влияния.The system must verify that the outage cannot be mitigated by the built-in high availability infrastructure of the SQL Database service due to the scale of the impact. Если вы хотите управлять рабочим процессом отработки отказа из приложения, вы можете отключить автоматическую отработку отказа.If you want to control the failover workflow from the application, you can turn off automatic failover.

    Примечание

    Из-за проверки масштаба сбоя и того, насколько быстро ее можно устранить, она включает в себя действия, выполняемые группой эксплуатации. льготный период не может быть указан ниже одного часа.Because verification of the scale of the outage and how quickly it can be mitigated involves human actions by the operations team, the grace period cannot be set below one hour. Это ограничение применяется ко всем базам данных в группе отработки отказа независимо от состояния синхронизации данных.This limitation applies to all databases in the failover group regardless of their data synchronization state.

  • Политика отработки отказа только для чтенияRead-only failover policy

    По умолчанию группа отработки отказа только для чтения отключена.By default, the failover of the read-only listener is disabled. Это гарантирует, что производительность базы данных-источника не изменится, если база данных-получателя отключена.It ensures that the performance of the primary is not impacted when the secondary is offline. Тем не менее, это также означает, что невозможно будет активировать сеансы только для чтения, пока база данных-получателя не восстановится.However, it also means the read-only sessions will not be able to connect until the secondary is recovered. Если вы не можете допустить время простоя для сеансов только для чтения и можете временно использовать первичный трафик как для чтения, так и для чтения и записи за счет возможного снижения производительности источника, то для прослушивателя, доступного только для чтения, необходимо настроить свойство AllowReadOnlyFailoverToPrimary.If you cannot tolerate downtime for the read-only sessions and are OK to temporarily use the primary for both read-only and read-write traffic at the expense of the potential performance degradation of the primary, you can enable failover for the read-only listener by configuring the AllowReadOnlyFailoverToPrimary property. В этом случае трафик только для чтения будет автоматически перенаправлен на сервер-источник, если дополнительный сервер недоступен.In that case, the read-only traffic will be automatically redirected to the primary if the secondary is not available.

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

    Плановая отработка отказа выполняет полную синхронизацию между базой данных-источник и базой данных-получатель, прежде чем база данных-получатель переключится на основную роль.Planned failover performs full synchronization between primary and secondary databases before the secondary switches to the primary role. Такая отработка отказа гарантирует отсутствие потери данных.This guarantees no data loss. Плановая отработка отказа используется в следующих сценариях.Planned failover is used in the following scenarios:

    • Тестирование аварийного восстановления (DR) в рабочей среде в случае, если потеря данных неприемлема.Perform disaster recovery (DR) drills in production when the data loss is not acceptable
    • Перемещение баз данных в другой регион.Relocate the databases to a different region
    • Возвращение баз данных в основной регион после устранения сбоя (восстановление размещения).Return the databases to the primary region after the outage has been mitigated (failback).
  • Незапланированная отработка отказаUnplanned failover

    При незапланированной или принудительной отработке отказа база данных-получатель немедленно переключается на основную роль без какой-либо синхронизации с базой данных-источником.Unplanned or forced failover immediately switches the secondary to the primary role without any synchronization with the primary. Эта операция приведет к потере данных.This operation will result in data loss. Незапланированная отработка отказа используется в качестве метода восстановления при сбоях, когда база данных-источник недоступна.Unplanned failover is used as a recovery method during outages when the primary is not accessible. Когда исходный первичный сервер возвращается в режим «в сети», он автоматически повторно подключается без синхронизации и становится новым сервером-получателем.When the original primary is back online, it will automatically reconnect without synchronization and become a new secondary.

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

    Вы можете запустить отработку отказа вручную в любое время, независимо от настройки автоматической отработки отказа.You can initiate failover manually at any time regardless of the automatic failover configuration. Если политика автоматической отработки отказа не настроена, для восстановления баз данных в группе отработки отказа в получателя требуется отработка отказа вручную.If automatic failover policy is not configured, manual failover is required to recover databases in the failover group to the secondary. Вы можете запустить принудительную отработку отказа или адаптированную (с полной синхронизацией данных).You can initiate forced or friendly failover (with full data synchronization). Адаптированная отработка отказа может использоваться для перемещения источника в дополнительный регион.The latter could be used to relocate the primary to the secondary region. После завершения отработки отказа записи DNS автоматически обновляются для установления подключения к новому источнику.When failover is completed, the DNS records are automatically updated to ensure connectivity to the new primary

  • Льготный период с потерей данныхGrace period with data loss

    Так как база данных-источник и база данных-получатель синхронизированы с помощью асинхронной репликации, отработка отказа может привести к потере данных.Because the primary and secondary databases are synchronized using asynchronous replication, the failover may result in data loss. Вы можете настроить политику автоматической отработки отказа, чтобы представить устойчивость приложения к потере данных.You can customize the automatic failover policy to reflect your application’s tolerance to data loss. Настроив GracePeriodWithDataLossHours, можно контролировать, как долго система ожидает перед началом отработки отказа, которая, скорее всего, приведет к утрате данных.By configuring GracePeriodWithDataLossHours, you can control how long the system waits before initiating the failover that is likely to result data loss.

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

    Вы можете настроить несколько групп отработки отказа для одной пары серверов, чтобы управлять масштабом отработок отказа.You can configure multiple failover groups for the same pair of servers to control the scale of failovers. Каждая группа выполняет отработку отказа независимо от других групп.Each group fails over independently. Если ваше мультитенантное приложение использует эластичные пулы, вы можете воспользоваться этой возможностью, чтобы объединить базу данных-источник и базу данных-получатель в каждом пуле.If your multi-tenant application uses elastic pools, you can use this capability to mix primary and secondary databases in each pool. Таким образом вы сможете снизить последствия сбоя для половины клиентов.This way you can reduce the impact of an outage to only half of the tenants.

    Примечание

    Управляемый экземпляр не поддерживает несколько групп отработки отказа.Managed Instance does not support multiple failover groups.

РазрешенияPermissions

Управление разрешениями для группы отработки отказа осуществляется с помощью управления доступом на основе ролей (RBAC).Permissions for a failover group are managed via role-based access control (RBAC). Роль участника SQL Server имеет все необходимые разрешения для управления группами отработки отказа.The SQL Server Contributor role has all the necessary permissions to manage failover groups.

Создание группы отработки отказаCreate failover group

Чтобы создать группу отработки отказа, необходим доступ на запись RBAC к серверам-источнику и серверу-получателю, а также ко всем базам данных в группе отработки отказа.To create a failover group, you need RBAC write access to both the primary and secondary servers, and to all databases in the failover group. Для управляемого экземпляра необходим доступ на запись RBAC к основному и дополнительному управляемому экземпляру, но разрешения на отдельные базы данных не важны, так как отдельные базы данных управляемого экземпляра нельзя добавлять в группу отработки отказа или удалять из нее.For a managed instance, you need RBAC write access to both the primary and secondary managed instance, but permissions on individual databases are not relevant since individual managed instance databases cannot be added to or removed from a failover group.

Обновление группы отработки отказаUpdate a failover group

Чтобы обновить группу отработки отказа, требуется доступ на запись RBAC к группе отработки отказа и все базы данных на текущем сервере-источнике или управляемом экземпляре.To update a failover group, you need RBAC write access to the failover group, and all databases on the current primary server or managed instance.

Переход на другой ресурс группы отработки отказаFailover a failover group

Для переключения группы отработки отказа требуется доступ на запись RBAC к группе отработки отказа на новом сервере-источнике или управляемом экземпляре.To fail over a failover group, you need RBAC write access to the failover group on the new primary server or managed instance.

Рекомендации по использованию групп отработки отказа с отдельными базами данных и эластичными пуламиBest practices of using failover groups with single databases and elastic pools

Группу автоматической отработки отказа необходимо настроить на сервере-источнике Базы данных SQL и подключить к серверу-получателю Базы данных SQL в другом регионе Azure.The auto-failover group must be configured on the primary SQL Database server and will connect it to the secondary SQL Database server in a different Azure region. Группы могут содержать все или некоторые базы данных на этих серверах.The groups can include all or some databases in these servers. На следующей схеме показана типичная конфигурация геоизбыточного облачного приложения, использующего несколько баз данных и активную георепликацию.The following diagram illustrates a typical configuration of a geo-redundant cloud application using multiple databases and auto-failover group.

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

Примечание

Подробное пошаговое руководство по добавлению одной базы данных в группу отработки отказа см. в разделе Добавление отдельной базы данных в группу отработки отказа .See Add single database to a failover group for a detailed step-by-step tutorial adding a single database to a failover group.

При разработке службы с обеспечением непрерывности бизнес-процессов придерживайтесь следующих рекомендаций.When designing a service with business continuity in mind, follow these general guidelines:

Использование одной или нескольких групп отработки отказа для управления отработкой отказа нескольких баз данныхUsing one or several failover groups to manage failover of multiple databases

Вы можете создать одну или несколько групп отработки отказа между двумя серверами в различных регионах (для основного сервера и сервера-получателя).One or many failover groups can be created between two servers in different regions (primary and secondary servers). Каждая группа может содержать одну или несколько баз данных, которые восстанавливаются единым блоком в случае, когда все или часть баз данных-источников становятся недоступными из-за сбоя в основном регионе.Each group can include one or several databases that are recovered as a unit in case all or some primary databases become unavailable due to an outage in the primary region. Группа отработки отказа создает базу данных-получатель в дополнительном географическом регионе с таким же целевым уровнем служб, который указан для базы данных-источника.The failover group creates geo-secondary database with the same service objective as the primary. При добавлении существующей связи георепликации к группе отработки отказа убедитесь, что база данных-получатель геореплицируемых данных настроена с тем же уровнем служб и объемом вычислительных ресурсов, что и база данных-источник.If you add an existing geo-replication relationship to the failover group, make sure the geo-secondary is configured with the same service tier and compute size as the primary.

Важно!

Создание групп отработки отказа между двумя серверами в разных подписках в настоящее время не поддерживается для отдельных баз данных и эластичных пулов.Creating failover groups between two servers in different subscriptions is not currently supported for single databases and elastic pools. Если переместить основной или дополнительный сервер в другую подписку после создания группы отработки отказа, это может привести к сбоям запросов отработки отказа и других операций.If you move the primary or secondary server to a different subscription after the failover group has been created, it could result in failures of the failover requests and other operations.

Использование прослушивателя для чтения и записи для рабочей нагрузки OLTPUsing read-write listener for OLTP workload

При выполнении операций OLTP используйте <fog-name>.database.windows.net в качестве URL-адреса сервера, чтобы все подключения автоматически перенаправлялись на сервер-источник.When performing OLTP operations, use <fog-name>.database.windows.net as the server URL and the connections are automatically directed to the primary. Этот URL-адрес не будет изменяться после отработки отказа.This URL does not change after the failover. Обратите внимание на то, что отработка отказа включает в себя обновление DNS-записи, поэтому клиентские подключения будут перенаправляться на новый сервер-источник только после обновления кэша DNS на стороне клиента.Note the failover involves updating the DNS record so the client connections are redirected to the new primary only after the client DNS cache is refreshed.

Использование прослушивателя только для чтения для рабочей нагрузки только для чтенияUsing read-only listener for read-only workload

Если вы используете логически изолированную рабочую нагрузку в режиме только для чтения, устойчивую к некоторым задержкам в обновлении данных, в приложении можно использовать базу данных-получатель.If you have a logically isolated read-only workload that is tolerant to certain staleness of data, you can use the secondary database in the application. Для сеансов с доступом только для чтения используйте <fog-name>.secondary.database.windows.net в качестве URL-адреса сервера, чтобы подключение автоматически перенаправлялось на сервер-получатель.For read-only sessions, use <fog-name>.secondary.database.windows.net as the server URL and the connection is automatically directed to the secondary. Также рекомендуется указать в качестве цели чтения строки подключения ApplicationIntent=ReadOnly.It is also recommended that you indicate in connection string read intent by using ApplicationIntent=ReadOnly. Если вы хотите убедиться, что Рабочая нагрузка только для чтения может быть восстановлена после отработки отказа, или если сервер-получатель переходит в автономный режим, убедитесь, что настроено свойство AllowReadOnlyFailoverToPrimary политики отработки отказа.If you want to ensure that the read-only workload can reconnect after failover or in case the secondary server goes offline, make sure to configure the AllowReadOnlyFailoverToPrimary property of the failover policy.

Подготовка к снижению производительностиPreparing for performance degradation

Типичное приложение Azure использует несколько служб Azure и состоит из нескольких компонентов.A typical Azure application uses multiple Azure service and consists of multiple components. Автоматическая отработка отказа группы отработки отказа активируется в зависимости от состояния только компонентов SQL Azure.The automated failover of the failover group is triggered based on the state the Azure SQL components alone. На другие службы Azure в основном регионе может не влиять сбой, и их компоненты могут по-прежнему быть доступны в этом регионе.Other Azure services in the primary region may not be affected by the outage and their components may still be available in that region. Когда база данных источника переключается в регион аварийного восстановления, задержка между зависимыми компонентами может увеличиться.Once the primary databases switch to the DR region, the latency between the dependent components may increase. Чтобы избежать влияния большей задержки на производительность приложения, Обеспечьте избыточность всех компонентов приложения в регионе аварийного восстановления и следуйте этим рекомендациям по безопасности сети.To avoid the impact of higher latency on the application's performance, ensure the redundancy of all the application's components in the DR region and follow these network security guidelines.

Подготовка к утере данныхPreparing for data loss

При обнаружении сбоя SQL ожидает период, указанный в GracePeriodWithDataLossHours.If an outage is detected, SQL waits for the period you specified by GracePeriodWithDataLossHours. Значение этого свойства по умолчанию – 1 час.The default value is 1 hour. Если вы не можете позволить себе потери данных, убедитесь, что для GracePeriodWithDataLossHours достаточно большого числа, например 24 часов.If you cannot afford data loss, make sure to set GracePeriodWithDataLossHours to a sufficiently large number, such as 24 hours. Используйте группу ручной отработки отказа для восстановления размещения из получателя в источник.Use manual group failover to fail back from the secondary to the primary.

Важно!

Эластичные пулы с 800 DTU или менее и более чем 250 базами данных, использующими георепликацию, могут испытывать проблемы, включая более длительные плановые операции отработки отказа и снижение производительности.Elastic pools with 800 or fewer DTUs and more than 250 databases using geo-replication may encounter issues including longer planned failovers and degraded performance. Эти проблемы чаще всего возникают из-за рабочих нагрузок, интенсивно записывающих данные, если конечные точки георепликации физически находятся далеко друг от друга или если используется несколько дополнительных конечных точек для каждой базы данных.These issues are more likely to occur for write intensive workloads, when geo-replication endpoints are widely separated by geography, or when multiple secondary endpoints are used for each database. Симптомы этих проблем проявляются при увеличении задержки георепликации с течением времени.Symptoms of these issues are indicated when the geo-replication lag increases over time. Эту задержку можно отслеживать с помощью sys.dm_geo_replication_link_status.This lag can be monitored using sys.dm_geo_replication_link_status. Если эти проблемы возникли, к возможным способам их устранения относятся увеличение числа DTU пула или уменьшение количества геореплицируемых баз данных в одном пуле.If these issues occur, then mitigations include increasing the number of pool DTUs, or reducing the number of geo-replicated databases in the same pool.

Изменение вторичного региона группы отработки отказаChanging secondary region of the failover group

Чтобы проиллюстрировать последовательность изменений, предполагается, что сервер A является сервером-источником, а сервер B — существующим сервером-получателем, а сервер C — новой базой данных-получателем в третьем регионе.To illustrate the change sequence, we will assume that server A is the primary server, server B is the existing secondary server, and server C is the new secondary in the third region. Чтобы выполнить переход, выполните следующие действия.To make the transition, follow these steps:

  1. Создайте дополнительные получатели каждой базы данных на сервере а на сервер C, используя активную георепликацию.Create additional secondaries of each database on server A to server C using active geo-replication. Каждая база данных на сервере A будет иметь два вторичных сервера: один на сервере B и один на сервере C. Это гарантирует, что базы данных источника останутся защищенными во время перехода.Each database on server A will have two secondaries, one on server B and one on server C. This will guarantee that the primary databases remain protected during the transition.
  2. Удалите группу отработки отказа.Delete the failover group. На этом этапе имена входа будут завершаться сбоем.At this point the logins will be failing. Это связано с тем, что псевдонимы SQL для прослушивателей группы отработки отказа удалены, и шлюз не распознает имя группы отработки отказа.This is because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name.
  3. Повторно создайте группу отработки отказа с тем же именем между серверами A и C. На этом этапе входы не будут завершаться сбоем.Re-create the failover group with the same name between servers A and C. At this point the logins will stop failing.
  4. Добавьте все базы данных-получатели на сервере а в новую группу отработки отказа.Add all primary databases on server A to the new failover group.
  5. Drop Server B. Все базы данных на B будут удалены автоматически.Drop server B. All databases on B will be deleted automatically.

Изменение основного региона группы отработки отказаChanging primary region of the failover group

Чтобы проиллюстрировать последовательность изменений, предполагается, что сервер A является сервером-источником, а сервер B — существующим сервером-получателем, а сервер C — новой базой данных-источником в третьем регионе.To illustrate the change sequence, we will assume server A is the primary server, server B is the existing secondary server, and server C is the new primary in the third region. Чтобы выполнить переход, выполните следующие действия.To make the transition, follow these steps:

  1. Выполните плановую отработку отказа, чтобы переключить сервер-источник на B. сервер A станет новым вторичным сервером.Perform a planned failover to switch the primary server to B. Server A will become the new secondary server. Отработка отказа может вызвать несколько минут простоя.The failover may result in several minutes of downtime. Фактическое время будет зависеть от размера группы отработки отказа.The actual time will depend on the size of failover group.
  2. Создайте дополнительные получатели каждой базы данных на сервере B на сервер C, используя активную георепликацию.Create additional secondaries of each database on server B to server C using active geo-replication. Каждая база данных на сервере B будет иметь два вторичных сервера — один на сервере A и один на сервере C. Это гарантирует, что базы данных источника останутся защищенными во время перехода.Each database on server B will have two secondaries, one on server A and one on server C. This will guarantee that the primary databases remain protected during the transition.
  3. Удалите группу отработки отказа.Delete the failover group. На этом этапе имена входа будут завершаться сбоем.At this point the logins will be failing. Это связано с тем, что псевдонимы SQL для прослушивателей группы отработки отказа удалены, и шлюз не распознает имя группы отработки отказа.This is because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name.
  4. Повторно создайте группу отработки отказа с тем же именем между серверами A и C. На этом этапе входы не будут завершаться сбоем.Re-create the failover group with the same name between servers A and C. At this point the logins will stop failing.
  5. Добавьте все базы данных источника на B в новую группу отработки отказа.Add all primary databases on B to the new failover group.
  6. Выполните плановую отработку отказа группы отработки отказа для переключения B и C. Теперь сервер C станет основным и B-вторичным.Perform a planned failover of the failover group to switch B and C. Now server C will become the primary and B - the secondary. Все базы данных-получатели на сервере A будут автоматически связаны с первичными серверами на C. Как и на шаге 1, отработка отказа может вызвать несколько минут простоя.All secondary databases on server A will be automatically linked to the primaries on C. As in step 1, the failover may result in several minutes of downtime.
  7. Удалите сервер A. Все базы данных в будут удалены автоматически.Drop the server A. All databases on A will be deleted automatically.

Важно!

При удалении группы отработки отказа также удаляются записи DNS для конечных точек прослушивателя.When the failover group is deleted, the DNS records for the listener endpoints are also deleted. На этом этапе существует ненулевая вероятность того, что кто-то еще создает группу отработки отказа или псевдоним сервера с тем же именем, что не позволит повторно использовать его.At that point, there is a non-zero probability of somebody else creating a failover group or server alias with the same name, which will prevent you from using it again. Чтобы снизить риск, не используйте универсальные имена групп отработки отказа.To minimize the risk, don't use generic failover group names.

Рекомендации по использованию групп отработки отказа с управляемыми экземплярамиBest practices of using failover groups with managed instances

Группы автоматической отработки отказа должны быть настроены на экземпляре источника и подключены к экземпляру получателя в другом регионе Azure.The auto-failover group must be configured on the primary instance and will connect it to the secondary instance in a different Azure region. Все базы данных в экземпляре будут реплицированы в экземпляр получателя.All databases in the instance will be replicated to the secondary instance.

На следующей схеме показана типичная конфигурация геоизбыточного облачного приложения, использующего несколько управляемых экземпляров и активную георепликацию.The following diagram illustrates a typical configuration of a geo-redundant cloud application using managed instance and auto-failover group.

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

Примечание

Подробное пошаговое руководство по добавлению управляемого экземпляра для использования группы отработки отказа см. в разделе Добавление управляемого экземпляра в группу отработки отказа .See Add managed instance to a failover group for a detailed step-by-step tutorial adding a managed instance to use failover group.

Если приложение использует управляемый экземпляр в качестве уровня данных, при проектировании непрерывности бизнес-процессов следуйте приведенным ниже общим рекомендациям.If your application uses managed instance as the data tier, follow these general guidelines when designing for business continuity:

Создание экземпляра-получателяCreating the secondary instance

Чтобы обеспечить беспрерывное подключение к экземпляру источника после отработки отказа, экземпляры и источника, и получателя должны находиться в одной зоне DNS.To ensure non-interrupted connectivity to the primary instance after failover both the primary and secondary instances must be in the same DNS zone. Это гарантирует, что один и тот же сертификат с несколькими доменами (SAN) можно использовать для проверки подлинности клиентских подключений к одному из двух экземпляров в группе отработки отказа.It will guarantee that the same multi-domain (SAN) certificate can be used to authenticate the client connections to either of the two instances in the failover group. После подготовки вашего приложения к рабочему развертыванию создайте экземпляр получателя в другом регионе и убедитесь, что он использует ту же зону DNS, что и экземпляр источника.When your application is ready for production deployment, create a secondary instance in a different region and make sure it shares the DNS zone with the primary instance. Это можно сделать, указав необязательный параметр DNS Zone Partner с помощью портал Azure, PowerShell или REST API.You can do it by specifying a DNS Zone Partner optional parameter using the Azure portal, PowerShell, or the REST API.

Важно!

Первый экземпляр, созданный в подсети, определяет зону DNS для всех последующих экземпляров в той же подсети.First instance created in the subnet determines DNS zone for all subsequent instances in the same subnet. Это означает, что два экземпляра из одной подсети не могут принадлежать разным зонам DNS.This means that two instances from the same subnet cannot belong to different DNS zones.

Дополнительные сведения о создании экземпляра-получателя в той же зоне DNS, что и основной экземпляр, см. в разделе Создание вторичного управляемого экземпляра.For more information about creating the secondary instance in the same DNS zone as the primary instance, see Create a secondary managed instance.

Включение трафика репликации между двумя экземплярамиEnabling replication traffic between two instances

Поскольку каждый экземпляр изолирован в своей виртуальной сети, двусторонний трафик между этими виртуальными сетями должен быть разрешен.Because each instance is isolated in its own VNet, two-directional traffic between these VNets must be allowed. См. VPN-шлюзы AzureSee Azure VPN gateway

Создание группы отработки отказа между управляемыми экземплярами в разных подпискахCreating a failover group between managed instances in different subscriptions

Группу отработки отказа можно создать между управляемыми экземплярами в двух разных подписках.You can create a failover group between managed instances in two different subscriptions. При использовании API PowerShell можно сделать это, указав параметр PartnerSubscriptionId для вторичного экземпляра.When using PowerShell API you can do it by specifying the PartnerSubscriptionId parameter for the secondary instance. При использовании REST API каждый идентификатор экземпляра, включаемый в параметр properties.managedInstancePairs, может иметь собственное значение subscriptionID.When using REST API, each instance ID included in the properties.managedInstancePairs parameter can have its own subscriptionID.

Важно!

Портал Azure не поддерживает группы отработки отказа в разных подписках.Azure Portal does not support failover groups across different subscriptions.

Управление отработкой отказа на экземпляр-получательManaging failover to secondary instance

Группа отработки отказа будет управлять отработкой отказа всех баз данных в экземпляре.The failover group will manage the failover of all the databases in the instance. При создании группы каждая база данных в экземпляре будет автоматически геореплицироваться в экземпляр получателя.When a group is created, each database in the instance will be automatically geo-replicated to the secondary instance. Вы не можете использовать группы отработки отказа для запуска частичной отработки отказа подмножества баз данных.You cannot use failover groups to initiate a partial failover of a subset of the databases.

Важно!

Если база данных удалена из экземпляра источника, то она также будет автоматически удалена из экземпляра геополучателя.If a database is removed from the primary instance, it will also be dropped automatically on the geo secondary instance.

Использование прослушивателя для чтения и записи для рабочей нагрузки OLTPUsing read-write listener for OLTP workload

При выполнении операций OLTP используйте <fog-name>.zone_id.database.windows.net в качестве URL-адреса сервера, чтобы все подключения автоматически перенаправлялись на сервер-источник.When performing OLTP operations, use <fog-name>.zone_id.database.windows.net as the server URL and the connections are automatically directed to the primary. Этот URL-адрес не будет изменяться после отработки отказа.This URL does not change after the failover. Отработка отказа включает в себя обновление DNS-записи, поэтому клиентские подключения будут перенаправляться на новый сервер-источник только после обновления кэша DNS на стороне клиента.The failover involves updating the DNS record, so the client connections are redirected to the new primary only after the client DNS cache is refreshed. Так как вторичный экземпляр использует зону DNS в качестве базы данных-источника, клиентское приложение сможет повторно подключиться к нему, используя тот же сертификат SAN.Because the secondary instance shares the DNS zone with the primary, the client application will be able to reconnect to it using the same SAN certificate.

Использование прослушивателя только для чтения для подключения к экземпляру-получателюUsing read-only listener to connect to the secondary instance

Если вы используете логически изолированную рабочую нагрузку в режиме только для чтения, устойчивую к некоторым задержкам в обновлении данных, в приложении можно использовать базу данных-получатель.If you have a logically isolated read-only workload that is tolerant to certain staleness of data, you can use the secondary database in the application. Для прямого подключения к георепликации получателя используйте server.secondary.zone_id.database.windows.net в качестве URL-сервера.To connect directly to the geo-replicated secondary, use server.secondary.zone_id.database.windows.net as the server URL and the connection is made directly to the geo-replicated secondary.

Примечание

На некоторых уровнях служб База данных SQL Azure поддерживает использование реплик только для чтения для балансировки рабочих нагрузок запросов только для чтения, используя возможности одной реплики и параметра ApplicationIntent=ReadOnly в строке соединения.In certain service tiers, Azure SQL Database supports the use of read-only replicas to load balance read-only query workloads using the capacity of one read-only replica and using the ApplicationIntent=ReadOnly parameter in the connection string. После настройки георепликации получателя вы можете использовать эту возможность для соединения с репликой только для чтения либо в основном расположении, либо в геореплицированном расположении.When you have configured a geo-replicated secondary, you can use this capability to connect to either a read-only replica in the primary location or in the geo-replicated location.

  • Для подключения к реплике только для чтения в основном расположении используйте <fog-name>.zone_id.database.windows.net.To connect to a read-only replica in the primary location, use <fog-name>.zone_id.database.windows.net.
  • Чтобы подключиться к реплике только для чтения в дополнительном расположении, используйте <fog-name>.secondary.zone_id.database.windows.net.To connect to a read-only replica in the secondary location, use <fog-name>.secondary.zone_id.database.windows.net.

Подготовка к снижению производительностиPreparing for performance degradation

Типичное приложение Azure использует несколько служб Azure и состоит из нескольких компонентов.A typical Azure application uses multiple Azure service and consists of multiple components. Автоматическая отработка отказа группы отработки отказа активируется в зависимости от состояния только компонентов SQL Azure.The automated failover of the failover group is triggered based on the state the Azure SQL components alone. На другие службы Azure в основном регионе может не влиять сбой, и их компоненты могут по-прежнему быть доступны в этом регионе.Other Azure services in the primary region may not be affected by the outage and their components may still be available in that region. Когда база данных источника переключается в регион аварийного восстановления, задержка между зависимыми компонентами может увеличиться.Once the primary databases switch to the DR region, the latency between the dependent components may increase. Чтобы избежать влияния большей задержки на производительность приложения, Обеспечьте избыточность всех компонентов приложения в регионе аварийного восстановления и следуйте этим рекомендациям по безопасности сети.To avoid the impact of higher latency on the application's performance, ensure the redundancy of all the application's components in the DR region and follow these network security guidelines.

Подготовка к утере данныхPreparing for data loss

При обнаружении сбоя SQL автоматически активирует отработку отказа с чтением и записью, если потери данных нулевые, насколько нам известно.If an outage is detected, SQL automatically triggers read-write failover if there is zero data loss to the best of our knowledge. В противном случае он ожидает в течение периода, указанного в GracePeriodWithDataLossHours.Otherwise, it waits for the period you specified by GracePeriodWithDataLossHours. Если вы указали GracePeriodWithDataLossHours, будьте готовы к потере данных.If you specified GracePeriodWithDataLossHours, be prepared for data loss. Во время сбоев Azure, как правило, повышает доступность.In general, during outages, Azure favors availability. Если вы не можете позволить себе потерю данных, установите для параметра GracePeriodWithDataLossHours достаточно большое количество времени, например 24 часа.If you cannot afford data loss, make sure to set GracePeriodWithDataLossHours to a sufficiently large number, such as 24 hours.

После запуска отработки отказа DNS обновления прослушивателя чтения и записи произойдут автоматически.The DNS update of the read-write listener will happen immediately after the failover is initiated. Эта операция не приведет к потере данных.This operation will not result in data loss. Однако процесс смены ролей баз данных в обычных условиях может занять до 5 минут.However, the process of switching database roles can take up to 5 minutes under normal conditions. До окончания этого процесса некоторые базы данных в новом экземпляре источника будут оставаться в режиме только для чтения.Until it is completed, some databases in the new primary instance will still be read-only. Если отработка отказа инициируется с помощью PowerShell, вся операция выполняется синхронно.If failover is initiated using PowerShell, the entire operation is synchronous. Если она инициируется с помощью портал Azure, Пользовательский интерфейс будет указывать состояние завершения.If it is initiated using the Azure portal, the UI will indicate completion status. Если она инициируется с помощью REST API, то используйте стандартный механизм опроса Azure Resource Manager для мониторинга выполнения.If it is initiated using the REST API, use standard Azure Resource Manager’s polling mechanism to monitor for completion.

Важно!

Используйте группу ручной отработки отказа для перемещения источников в исходное расположение.Use manual group failover to move primaries back to the original location. После устранения сбоя, вызвавшего отработку отказа, вы можете переместить базы данных-источники в исходное расположение.When the outage that caused the failover is mitigated, you can move your primary databases to the original location. Для этого вам следует инициировать ручную отработку отказа группы.To do that you should initiate the manual failover of the group.

Изменение вторичного региона группы отработки отказаChanging secondary region of the failover group

Предположим, что экземпляр а является основным экземпляром, экземпляр б является существующим экземпляром-получателем, а экземпляр C — новым вторичным экземпляром в третьем регионе.Let's assume that instance A is the primary instance, instance B is the existing secondary instance, and instance C is the new secondary instance in the third region. Чтобы выполнить переход, выполните следующие действия.To make the transition, follow these steps:

  1. Создайте экземпляр C с тем же размером, что и в той же зоне DNS.Create instance C with same size as A and in the same DNS zone.
  2. Удалите группу отработки отказа между экземплярами A и B. На этом этапе имена входа будут завершаться сбоем, так как псевдонимы SQL для прослушивателей группы отработки отказа удалены и шлюз не распознает имя группы отработки отказа.Delete the failover group between instances A and B. At this point the logins will be failing because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name. Базы данных-получатели будут отключены от первичного цвета и станут базами данных для чтения и записи.The secondary databases will be disconnected from the primaries and will become read-write databases.
  3. Создайте группу отработки отказа с тем же именем между экземпляром A и C. Следуйте инструкциям в руководстве по группе отработки отказа с управляемым экземпляром.Create a failover group with the same name between instance A and C. Follow the instructions in failover group with managed instance tutorial. Это операция по размеру данных, которая будет выполнена, когда все базы данных экземпляра A будут заполнены и синхронизированы.This is a size-of-data operation and will complete when all databases from instance A are seeded and synchronized.
  4. Удалите экземпляр B, если не требуется, чтобы избежать ненужных расходов.Delete instance B if not needed to avoid unnecessary charges.

Примечание

После выполнения шага 2 и до завершения шага 3 базы данных в экземпляре A останутся незащищенными от катастрофического сбоя экземпляра а.After step 2 and until step 3 is completed the databases in instance A will remain unprotected from a catastrophic failure of instance A.

Изменение основного региона группы отработки отказаChanging primary region of the failover group

Предположим, что экземпляр а является основным экземпляром, экземпляр б является существующим экземпляром-получателем, а экземпляр C — новым основным экземпляром в третьем регионе.Let's assume instance A is the primary instance, instance B is the existing secondary instance, and instance C is the new primary instance in the third region. Чтобы выполнить переход, выполните следующие действия.To make the transition, follow these steps:

  1. Создайте экземпляр C с тем же размером, что и B, и в той же зоне DNS.Create instance C with same size as B and in the same DNS zone.
  2. Подключитесь к экземпляру б и отработку отказа вручную, чтобы переключить основной экземпляр в B. экземпляр A станет автоматически новым экземпляром-получателем.Connect to instance B and manually failover to switch the primary instance to B. Instance A will become the new secondary instance automatically.
  3. Удалите группу отработки отказа между экземплярами A и B. На этом этапе имена входа будут завершаться сбоем, так как псевдонимы SQL для прослушивателей группы отработки отказа удалены и шлюз не распознает имя группы отработки отказа.Delete the failover group between instances A and B. At this point the logins will be failing because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name. Базы данных-получатели будут отключены от первичного цвета и станут базами данных для чтения и записи.The secondary databases will be disconnected from the primaries and will become read-write databases.
  4. Создайте группу отработки отказа с тем же именем между экземпляром A и C. Следуйте инструкциям руководства по использованию группы отработки отказа с управляемым экземпляром.Create a failover group with the same name between instance A and C. Follow the instructions in the failover group with managed instance tutorial. Это операция по размеру данных, которая будет выполнена, когда все базы данных экземпляра A будут заполнены и синхронизированы.This is a size-of-data operation and will complete when all databases from instance A are seeded and synchronized.
  5. Удалите экземпляр A, если не требуется, чтобы избежать ненужных расходов.Delete instance A if not needed to avoid unnecessary charges.

Примечание

После выполнения шага 3 и до завершения шага 4 базы данных в экземпляре A останутся незащищенными от катастрофического сбоя экземпляра а.After step 3 and until step 4 is completed the databases in instance A will remain unprotected from a catastrophic failure of instance A.

Важно!

При удалении группы отработки отказа также удаляются записи DNS для конечных точек прослушивателя.When the failover group is deleted, the DNS records for the listener endpoints are also deleted. На этом этапе существует ненулевая вероятность того, что кто-то еще создает группу отработки отказа или псевдоним сервера с тем же именем, что не позволит повторно использовать его.At that point, there is a non-zero probability of somebody else creating a failover group or server alias with the same name, which will prevent you from using it again. Чтобы снизить риск, не используйте универсальные имена групп отработки отказа.To minimize the risk, don't use generic failover group names.

Группы отработки отказа и сетевая безопасностьFailover groups and network security

Для некоторых приложений правила безопасности требует, чтобы сетевой доступ к уровню данных был ограничен конкретным компонентом или компонентами, такими как виртуальная машина, веб-служба и т. д. Это требование представляет некоторые трудности при проектировании непрерывности бизнес-процессов и использовании групп отработки отказа.For some applications the security rules require that the network access to the data tier is restricted to a specific component or components such as a VM, web service etc. This requirement presents some challenges for business continuity design and the use of the failover groups. При реализации такого ограниченного доступа учитывайте следующие параметры.Consider the following options when implementing such restricted access.

Использование групп отработки отказа и правил виртуальной сетиUsing failover groups and virtual network rules

Если вы используете конечные точки служб и правила виртуальной сети для ограничения доступа к базе данных SQL, помните, что каждая конечная точка службы для виртуальной сети применяется только к одному региону Azure.If you are using Virtual Network service endpoints and rules to restrict access to your SQL database, be aware that Each Virtual Network service endpoint applies to only one Azure region. Конечная точка не поддерживает прием подключений из подсети в других регионах.The endpoint does not enable other regions to accept communication from the subnet. Таким образом, только клиентские приложения, развернутые в одном регионе, могут подключаться к базе данных-источнику.Therefore, only the client applications deployed in the same region can connect to the primary database. Так как результаты отработки отказа в сеансах клиента SQL пересылаются на сервер в другом (дополнительном) регионе, эти сеансы завершатся сбоем, если будут исходить из клиента за пределами этого региона.Since the failover results in the SQL client sessions being rerouted to a server in a different (secondary) region, these sessions will fail if originated from a client outside of that region. По этой причине политику автоматической отработки отказа невозможно включить, если на серверы-участники распространяются правила виртуальной сети.For that reason, the automatic failover policy cannot be enabled if the participating servers are included in the Virtual Network rules. Для поддержки перехода на другой ресурс вручную выполните следующие действия:To support manual failover, follow these steps:

  1. Подготовьте избыточные копии интерфейсных компонентов приложения (веб-службы, виртуальные машины и т. д.) в дополнительном регионе.Provision the redundant copies of the front-end components of your application (web service, virtual machines etc.) in the secondary region
  2. Настройте правила виртуальной сети по отдельности для основного и дополнительного сервера.Configure the virtual network rules individually for primary and secondary server
  3. Включите отработку отказа внешнего интерфейса с помощью конфигурации диспетчера трафика.Enable the front-end failover using a Traffic manager configuration
  4. Инициируйте отработку отказа вручную при обнаружении сбоя.Initiate manual failover when the outage is detected. Этот параметр оптимизирован для приложений, требующих последовательной задержки между внешним интерфейсом и уровнем данных, и поддерживает восстановление после сбоя внешнего интерфейса уровня данных или их обоих.This option is optimized for the applications that require consistent latency between the front-end and the data tier and supports recovery when either front end, data tier or both are impacted by the outage.

Примечание

При использовании прослушивателя только для чтения для балансировки рабочей нагрузки только для чтения убедитесь, что эта рабочая нагрузка выполняется на виртуальной машине или в другом ресурсе в дополнительном регионе, чтобы прослушиватель мог подключаться к базе данных-получателю.If you are using the read-only listener to load-balance a read-only workload, make sure that this workload is executed in a VM or other resource in the secondary region so it can connect to the secondary database.

Использование групп отработки отказа и правил брандмауэра базы данных SQLUsing failover groups and SQL database firewall rules

Если для плана обеспечения непрерывности бизнес-процессов требуется отработка отказа с помощью групп с автоматической отработкой отказа, можно ограничить доступ к базе данных SQL с помощью традиционных правил брандмауэра.If your business continuity plan requires failover using groups with automatic failover, you can restrict access to your SQL database using the traditional firewall rules. Для поддержки автоматического перехода на другой ресурс выполните следующие действия:To support automatic failover, follow these steps:

  1. создайте общедоступный IP-адрес;Create a public IP
  2. создайте общедоступный балансировщик нагрузки и назначьте ему общедоступный IP-адрес;Create a public load balancer and assign the public IP to it.
  3. создайте виртуальную сеть и виртуальные машины для интерфейсных компонентов;Create a virtual network and the virtual machines for your front-end components
  4. создайте группу безопасности сети и настройте входящие подключения.Create network security group and configure inbound connections.
  5. Убедитесь, что исходящие подключения открыты для базы данных SQL Azure с помощью тега службы "Sql".Ensure that the outbound connections are open to Azure SQL database by using ‘Sql’ service tag.
  6. Создайте правило брандмауэра базы данных SQL, чтобы разрешить входящий трафик из общедоступного IP-адреса, созданного на этапе 1.Create a SQL database firewall rule to allow inbound traffic from the public IP address you create in step 1.

Дополнительные сведения о том, как настроить исходящий доступ и какой IP-адрес нужно использовать в правилах брандмауэра, см. в статье Исходящие подключения в Azure.For more information about on how to configure outbound access and what IP to use in the firewall rules, see Load balancer outbound connections.

Приведенная выше конфигурация гарантирует, что автоматический переход на другой ресурс не будет блокировать подключения из интерфейсных компонентов, и предполагает, что приложение может выдержать более длительную задержку между интерфейсном и уровнем данных.The above configuration will ensure that the automatic failover will not block connections from the front-end components and assumes that the application can tolerate the longer latency between the front end and the data tier.

Важно!

Для обеспечения непрерывности бизнес-процессов при региональных сбоях должна присутствовать географическая избыточность интерфейсных компонентов и баз данных.To guarantee business continuity for regional outages you must ensure geographic redundancy for both front-end components and the databases.

Включение георепликации между управляемыми экземплярами и их виртуальных сетейEnabling geo-replication between managed instances and their VNets

При настройке группы отработки отказа между основным и дополнительным управляемыми экземплярами в двух разных регионах каждый экземпляр изолирован с помощью независимой виртуальной сети.When you set up a failover group between primary and secondary managed instances in two different regions, each instance is isolated using an independent virtual network. Чтобы разрешить трафик репликации между этими виртуальных сетей, убедитесь, что выполнены следующие условия.To allow replication traffic between these VNets ensure these prerequisites are met:

  1. Два управляемых экземпляра должны находиться в разных регионах Azure.The two managed instances need to be in different Azure regions.

  2. Два управляемых экземпляра должны быть одного уровня службы и иметь одинаковый размер хранилища.The two managed instances need to be the same service tier, and have the same storage size.

  3. Ваш вторичный управляемый экземпляр должен быть пустым (без пользовательских баз данных).Your secondary managed instance must be empty (no user databases).

  4. Виртуальные сети, используемые управляемыми экземплярами, должны быть подключены через VPN-шлюз или Express Route.The virtual networks used by the managed instances need to be connected through a VPN Gateway or Express Route. Если две виртуальные сети подключаются через локальную сеть, убедитесь в отсутствии портов, блокирующих правила брандмауэра 5022 и 11000-11999.When two virtual networks connect through an on-premises network, ensure there is no firewall rule blocking ports 5022, and 11000-11999. Пиринг глобальной виртуальной сети не поддерживается.Global VNet Peering is not supported.

  5. У двух управляемых экземпляров виртуальных сетей не может быть перекрывающихся IP-адресов.The two managed instance VNets cannot have overlapping IP addresses.

  6. Необходимо настроить группы безопасности сети (NSG), чтобы порты 5022 и диапазон 11000 ~ 12000 были открытыми входящими и исходящими для подключений из подсети другого управляемого экземпляра.You need to set up your Network Security Groups (NSG) such that ports 5022 and the range 11000~12000 are open inbound and outbound for connections from the subnet of the other managed instance. Это позволяет обеспечить репликацию трафика между экземплярами.This is to allow replication traffic between the instances.

    Важно!

    Неправильная настройка правил безопасности NSG приводит к задержке операций копирования баз данных.Misconfigured NSG security rules leads to stuck database copy operations.

  7. Для экземпляра-получателя настраивается правильный идентификатор зоны DNS.The secondary instance is configured with the correct DNS zone ID. Зона DNS — это свойство управляемого экземпляра и виртуального кластера, а его идентификатор включается в адрес имени узла.DNS zone is a property of a managed instance and virtual cluster, and its ID is included in the host name address. Идентификатор зоны создается в виде случайной строки, когда первый управляемый экземпляр создается в каждой виртуальной сети, и один и тот же идентификатор назначается всем остальным экземплярам в той же подсети.The zone ID is generated as a random string when the first managed instance is created in each VNet and the same ID is assigned to all other instances in the same subnet. После назначения зону DNS изменить нельзя.Once assigned, the DNS zone cannot be modified. Управляемые экземпляры, входящие в одну группу отработки отказа, должны иметь общий доступ к зоне DNS.Managed instances included in the same failover group must share the DNS zone. Это достигается путем передачи идентификатора зоны основного экземпляра в качестве значения параметра Днсзонепартнер при создании экземпляра-получателя.You accomplish this by passing the primary instance's zone ID as the value of DnsZonePartner parameter when creating the secondary instance.

    Примечание

    Подробное руководство по настройке групп отработки отказа с управляемым экземпляром см. в разделе Добавление управляемого экземпляра в группу отработки отказа.For a detailed tutorial on configuring failover groups with managed instance, see add a managed instance to a failover group.

Повышение или понижение уровня производительности базы данных-источникаUpgrading or downgrading a primary database

Вы можете повышать или понижать объем вычислительных ресурсов базы данных-источника (в рамках одного уровня служб, а не между уровнем общего назначения и критически важным для бизнеса) без отключения каких-либо баз данных-получателей.You can upgrade or downgrade a primary database to a different compute size (within the same service tier, not between General Purpose and Business Critical) without disconnecting any secondary databases. При обновлении рекомендуется сначала обновить все базы данных-получатели, а затем обновить сервер-источник.When upgrading, we recommend that you upgrade all of the secondary databases first, and then upgrade the primary. При переходе на более раннюю версию в обратном порядке: переход на более раннюю версию первичного и последующее понижение уровня всех баз данных-получателей.When downgrading, reverse the order: downgrade the primary first, and then downgrade all of the secondary databases. Когда вы повышаете или понижаете базу данных до следующего уровня служб, особенно важно выполнять рекомендацию выше.When you upgrade or downgrade the database to a different service tier, this recommendation is enforced.

Эту последовательность рекомендуется использовать в частности, чтобы избежать проблем, когда вторичная версия на более низком SKU перегружается и должна быть повторно заполнена во время обновления или перехода на более раннюю версию.This sequence is recommended specifically to avoid the problem where the secondary at a lower SKU gets overloaded and must be re-seeded during an upgrade or downgrade process. Вы также можете избежать этой проблемы, сделав первичную доступную только для чтения, за счет чего влияют на все рабочие нагрузки чтения и записи для первичной реплики.You could also avoid the problem by making the primary read-only, at the expense of impacting all read-write workloads against the primary.

Примечание

Если вы создали базу данных-получатель как часть конфигурации группы отработки отказа, понижение ее уровня не рекомендуется.If you created secondary database as part of the failover group configuration it is not recommended to downgrade the secondary database. Это необходимо, чтобы обеспечить достаточную емкость уровня данных для обработки регулярных рабочих нагрузок после активации отработки отказа.This is to ensure your data tier has sufficient capacity to process your regular workload after failover is activated.

Предотвращение потери важных данныхPreventing the loss of critical data

Из-за высокой задержки глобальных сетей непрерывная копия использует механизм асинхронной репликации.Due to the high latency of wide area networks, continuous copy uses an asynchronous replication mechanism. Ввиду асинхронной репликации потеря данных в случае сбоя неизбежна.Asynchronous replication makes some data loss unavoidable if a failure occurs. Тем не менее для некоторых приложений терять данные недопустимо.However, some applications may require no data loss. Чтобы защитить эти критические обновления, разработчик приложения сразу же после фиксации транзакции может вызывать системную процедуру sp_wait_for_database_copy_sync.To protect these critical updates, an application developer can call the sp_wait_for_database_copy_sync system procedure immediately after committing the transaction. Вызов sp_wait_for_database_copy_sync блокирует вызывающий поток до тех пор, пока Последняя зафиксированная транзакция не будет передана в базу данных-получатель.Calling sp_wait_for_database_copy_sync blocks the calling thread until the last committed transaction has been transmitted to the secondary database. Но вызов не дожидается воспроизведения и фиксации переданных транзакций в базе данных-получателе.However, it does not wait for the transmitted transactions to be replayed and committed on the secondary. sp_wait_for_database_copy_sync ограничивается ссылкой на конкретное непрерывное копирование.sp_wait_for_database_copy_sync is scoped to a specific continuous copy link. Эту процедуру может вызвать любой пользователь с правами подключения к базе данных-источнику.Any user with the connection rights to the primary database can call this procedure.

Примечание

sp_wait_for_database_copy_sync предотвращает потерю данных после отработки отказа, но не гарантирует полную синхронизацию для доступа на чтение.sp_wait_for_database_copy_sync prevents data loss after failover, but does not guarantee full synchronization for read access. Задержка, вызванная вызовом процедуры sp_wait_for_database_copy_sync, может быть существенной и зависит от размера журнала транзакций во время вызова.The delay caused by a sp_wait_for_database_copy_sync procedure call can be significant and depends on the size of the transaction log at the time of the call.

Группы отработки отказа и восстановление до точки во времениFailover groups and point-in-time restore

Сведения об использовании восстановления до точки во времени с группами отработки отказа см. в разделе Восстановление до точки во времени (PITR).For information about using point-in-time restore with failover groups, see Point in Time Recovery (PITR).

Ограничения групп отработки отказаLimitations of failover groups

Следует учитывать следующие ограничения.Be aware of the following limitations:

  • Невозможно создать группу отработки отказа между двумя серверами или экземплярами в одном регионе Azure.Failover group cannot be created between two servers or instances in the same Azure regions.
  • Невозможно переименовать группу отработки отказа.Failover group cannot be renamed. Необходимо удалить группу и создать ее повторно с другим именем.You will need to delete the group and re-create it with a different name.
  • Переименование базы данных не поддерживается для экземпляров в группе отработки отказа.Database rename is not supported for instances in failover group. Чтобы иметь возможность переименовать базу данных, необходимо временно удалить группу отработки отказа.You will need to temporarily delete failover group to be able to rename a database.

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

Как уже говорилось ранее, группами автоматической отработки отказа и активной георепликацией можно также управлять программно с помощью Azure PowerShell и REST API.As discussed previously, auto-failover groups and active geo-replication can also be managed programmatically using Azure PowerShell and the REST API. В приведенных ниже таблицах описан доступный для этого набор команд.The following tables describe the set of commands available. Активная георепликация включает в себя набор API-интерфейсов Azure Resource Manager для управления, в том числе REST API Базы данных SQL Azure и командлеты Azure PowerShell.Active geo-replication includes a set of Azure Resource Manager APIs for management, including the Azure SQL Database REST API and Azure PowerShell cmdlets. Эти интерфейсы API требуют использования групп ресурсов и поддерживают безопасность на основе ролей (RBAC).These APIs require the use of resource groups and support role-based security (RBAC). Дополнительные сведения о том, как реализовать контроль доступа на основе ролей, см. в статье Использование управления доступом на основе ролей для контроля доступа к ресурсам в подписке Azure.For more information on how to implement access roles, see Azure Role-Based Access Control.

Управление отработкой отказа баз данных SQL с отдельными базами данных и эластичными пуламиManage SQL database failover with single databases and elastic pools

КомандлетCmdlet DescriptionDescription
New-AzSqlDatabaseFailoverGroupNew-AzSqlDatabaseFailoverGroup Создает группу отработки отказа и регистрирует ее на основном сервере и сервере-получателе.This command creates a failover group and registers it on both primary and secondary servers
Remove-АзсклдатабасефаиловерграупRemove-AzSqlDatabaseFailoverGroup Удаляет группу отработки отказа с сервераRemoves a failover group from the server
Get-AzSqlDatabaseFailoverGroupGet-AzSqlDatabaseFailoverGroup Извлекает конфигурацию группы отработки отказаRetrieves a failover group's configuration
Set-АзсклдатабасефаиловерграупSet-AzSqlDatabaseFailoverGroup Изменяет конфигурацию группы отработки отказаModifies configuration of a failover group
Switch-AzSqlDatabaseFailoverGroupSwitch-AzSqlDatabaseFailoverGroup Активирует отработку отказа группы отработки отказа на сервер-получательTriggers failover of a failover group to the secondary server
Add-AzSqlDatabaseToFailoverGroupAdd-AzSqlDatabaseToFailoverGroup Добавляет одну или несколько баз данных в группу отработки отказаAdds one or more databases to a failover group

Управление группами отработки отказа базы данных SQL с помощью управляемых экземпляровManage SQL database failover groups with managed instances

КомандлетCmdlet DescriptionDescription
New-AzSqlDatabaseInstanceFailoverGroupNew-AzSqlDatabaseInstanceFailoverGroup Эта команда создает группу отработки отказа и регистрирует ее на первичном и вторичном экземплярах.This command creates a failover group and registers it on both primary and secondary instances
Set-АзсклдатабасеинстанцефаиловерграупSet-AzSqlDatabaseInstanceFailoverGroup Изменяет конфигурацию группы отработки отказаModifies configuration of a failover group
Get-AzSqlDatabaseInstanceFailoverGroupGet-AzSqlDatabaseInstanceFailoverGroup Извлекает конфигурацию группы отработки отказаRetrieves a failover group's configuration
Switch-AzSqlDatabaseInstanceFailoverGroupSwitch-AzSqlDatabaseInstanceFailoverGroup Активирует отработку отказа группы отработки отказа на дополнительный экземплярTriggers failover of a failover group to the secondary instance
Remove-АзсклдатабасеинстанцефаиловерграупRemove-AzSqlDatabaseInstanceFailoverGroup Удаляет группу отработки отказа.Removes a failover group

Важно!

Пример сценария см. в статье Use PowerShell to configure an active geo-replication failover group for a single Azure SQL database (Использование PowerShell для настройки группы отработки отказа активной георепликации для отдельной базы данных SQL Azure).For a sample script, see Configure and failover a failover group for a single database.

REST API: Управление группами отработки отказа базы данных SQL с помощью одной базы данных и в составе пулаREST API: Manage SQL database failover groups with single and pooled databases

APIAPI DescriptionDescription
Создание или обновление группы отработки отказаCreate or Update Failover Group Создает или обновляет группу отработки отказа.Creates or updates a failover group
Удаление группы отработки отказаDelete Failover Group Удаляет группу отработки отказа с сервераRemoves a failover group from the server
Плановая отработка отказаFailover (Planned) Активирует отработку отказа с текущего сервера-источника на сервер-получатель с полной синхронизацией данных.Triggers failover from the current primary server to the secondary server with full data synchronization.
Принудительная отработка отказа (возможна потеря данных)Force Failover Allow Data Loss Активирует отработку отказа с текущего сервера-источника на сервер-получатель без синхронизации данных.Triggers failover from the current primary server to the secondary server without synchronizing data. Эта операция может привести к утере данных.This operation may result in data loss.
Получение группы отработки отказаGet Failover Group Извлекает конфигурацию группы отработки отказа.Retrieves a failover group's configuration.
Вывод списка групп отработки отказа с фильтрацией по серверуList Failover Groups By Server Список групп отработки отказа на сервере.Lists the failover groups on a server.
Обновление группы отработки отказаUpdate Failover Group Обновляет конфигурацию группы отработки отказа.Updates a failover group's configuration.

REST API: Управление группами отработки отказа с помощью управляемых экземпляровREST API: Manage failover groups with Managed Instances

APIAPI DescriptionDescription
Создание или обновление группы отработки отказаCreate or Update Failover Group Создает или обновляет конфигурацию группы отработки отказа.Creates or updates a failover group's configuration
Удаление группы отработки отказаDelete Failover Group Удаляет группу отработки отказа из экземпляра.Removes a failover group from the instance
Плановая отработка отказаFailover (Planned) Активирует отработку отказа с текущего первичного экземпляра на этот экземпляр с полной синхронизацией данных.Triggers failover from the current primary instance to this instance with full data synchronization.
Принудительная отработка отказа (возможна потеря данных)Force Failover Allow Data Loss Активирует отработку отказа из текущего первичного экземпляра в экземпляр-получатель без синхронизации данных.Triggers failover from the current primary instance to the secondary instance without synchronizing data. Эта операция может привести к утере данных.This operation may result in data loss.
Получение группы отработки отказаGet Failover Group Извлекает конфигурацию группы отработки отказа.retrieves a failover group's configuration.
Перечисление групп отработки отказа – Перечисление по расположениюList Failover Groups - List By Location Перечисляет группы отработки отказа в расположении.Lists the failover groups in a location.

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