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

Применимо к:Управляемый экземпляр SQL Azure

• База данных SQL Azure
• Управляемый экземпляр SQL Azure

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

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

Необходимые компоненты

Примите во внимание следующие предварительные требования.

• Вторичный управляемый экземпляр должен быть пустым, то есть не содержит пользовательских баз данных.
• Два управляемых экземпляра SQL должны быть на одном уровне службы и иметь одинаковый размер хранилища. Хотя это не обязательно, настоятельно рекомендуется, чтобы два экземпляра имели равный размер вычислительных ресурсов, чтобы убедиться, что вторичный экземпляр может устойчиво обрабатывать изменения, реплика от основного экземпляра, включая периоды пиковых действий.
• Диапазон IP-адресов для виртуальной сети первичного экземпляра не должен перекрываться с диапазоном адресов виртуальной сети для вторичного управляемого экземпляра или любой другой виртуальной сети, пиринговой с первичной или вторичной виртуальной сетью.
• При создании вторичного управляемого экземпляра необходимо указать идентификатор зоны DNS первичного экземпляра DnsZonePartner в качестве значения параметра. Если значение DnsZonePartnerне указано, идентификатор зоны создается в виде случайной строки при создании первого экземпляра в каждой виртуальной сети, а один и тот же идентификатор назначается всем другим экземплярам в одной подсети. После назначения зону DNS изменить нельзя.
• Правила групп безопасности сети (NSG) для экземпляра размещения подсети должны иметь порт 5022 (TCP), а диапазон портов 11000-11999 (TCP) открыт для входящих и исходящих подключений для подключений из подсети, в которых размещен другой управляемый экземпляр. Это относится как к подсетям, так и к основному и вторичному экземпляру.
• Параметры сортировки и часовой пояс для вторичного управляемого экземпляра должны соответствовать параметрам основного управляемого экземпляра.
• Управляемые экземпляры следует развертывать в парных регионах по соображениям производительности. Управляемые экземпляры, находящиеся в геопарированных регионах, получают значительно более высокую скорость гео-реплика по сравнению с неоплачиваемыми регионами.

Диапазон адресного пространства

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

Указание идентификатора зоны основного экземпляра

При создании вторичного экземпляра необходимо указать идентификатор зоны основного экземпляра в качестве идентификатора DnsZonePartner.

Портал

Если вы создаете дополнительный экземпляр в портал Azure, на вкладке "Дополнительные параметры" в разделе "Гео-реплика tion" выберите "Да", чтобы использовать в качестве вторичной отработки отказа, а затем выберите основной экземпляр в раскрывающемся списке:

PowerShell

Если вы создаете дополнительный экземпляр с помощью Azure PowerShell, обязательно укажите DnsZonePartner параметр с идентификатором зоны основного экземпляра.

Команду Get-AzSqlInstance можно использовать для параметризации идентификатора зоны DNS первичного экземпляра, а затем передать его параметру DnsZonePartnerкоманды New-AzSqlInstance:

# Get the DNS zone ID of the primary instance
$primaryManagedInstanceId = Get-AzSqlInstance -Name $primaryInstance -ResourceGroupName $resourceGroupName | Select-Object Id

# Create the secondary managed instance
New-AzSqlInstance -Name $secondaryInstance `
                  -ResourceGroupName $resourceGroupName `
                  -Location $drLocation `
                  -SubnetId $secondaryMiSubnetConfigId `
                  -AdministratorCredential $mycreds `
                  -StorageSizeInGB $maxStorage `
                  -VCore $vCores `
                  -Edition $edition `
                  -ComputeGeneration $computeGeneration `
                  -LicenseType $license `
                  -DnsZonePartner $primaryManagedInstanceId.Id
Write-host "Secondary SQL Managed Instance created successfully."

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

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

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

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

Важно!

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

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

• Таблица маршрутизации и группы безопасности сети, назначенные подсетям управляемого экземпляра, не используются для двух одноранговых виртуальных сетей.
• Правила группы безопасности сети (NSG) в подсети, в котором размещается основной экземпляр, разрешают:
  • Входящий трафик через порт 5022 и диапазон портов 11000-11999 из подсети, на котором размещен дополнительный экземпляр.
  • Исходящий трафик через порт 5022 и диапазон портов 11000–11999 в подсеть, где размещается дополнительный экземпляр.
• Правила группы безопасности сети (NSG) в подсети, где размещается вторичный экземпляр, разрешают:
  • Входящий трафик через порт 5022 и диапазон портов 11000-11999 из подсети, где размещается основной экземпляр.
  • Исходящий трафик через порт 5022 и диапазон портов 11000-11999 в подсеть, где размещается основной экземпляр.
• Диапазоны IP-адресов виртуальных сетей, на котором размещен первичный и вторичный экземпляр, не должны перекрываться.
• Между виртуальными сетями, включающими основной и вторичный экземпляр, между виртуальными сетями нет косвенного перекрытия или других виртуальных сетей, с которыми они пиринговая связь между локальной виртуальной сетью или другими средствами.

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

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

Портал

1. В портал Azure перейдите к ресурсу виртуальной сети для основного управляемого экземпляра.
2. Выберите пиринги в разделе Параметры и нажмите кнопку +Добавить.

1. Введите или выберите значения описанных ниже параметров:

   Настройки	Описание
   Эта виртуальная сеть
   Имя пиринговой связи	Имя для пиринга должно быть уникальным в пределах виртуальной сети.
   Трафик в удаленную виртуальную сеть	Выберите allow (default), чтобы включить обмен данными между двумя виртуальными сетями через поток по умолчанию VirtualNetwork . Если разрешить обмен данными между виртуальными сетями, то ресурсы, подключенные к каждой из них, будут взаимодействовать между собой с той же пропускной способностью и задержкой, что и ресурсы, подключенные к одной и той же виртуальной сети. Обмен данными между ресурсами двух виртуальных сетей осуществляется по частной сети Azure.
   Трафик, перенаправленный из удаленной виртуальной сети	Параметр "Разрешено" (по умолчанию) и "Блокировать" будет работать для этого руководства. Дополнительные сведения см. в разделе "Создание пиринга"
   Route Server или шлюз виртуальной сети	Выберите Отсутствует. Дополнительные сведения о других доступных параметрах см. в разделе "Создание пиринга".
   Удаленная виртуальная сеть
   Имя пиринговой связи	Имя того же пиринга, используемого в виртуальной сети, в котором размещается вторичный экземпляр.
   Модель развертывания виртуальной сети	Выберите Resource Manager.
   Я знаю идентификатор ресурса	Оставьте этот проверка box не проверка.
   Отток подписок	Выберите подписку Azure виртуальной сети, в которой размещается дополнительный экземпляр, с которым вы хотите выполнить пиринг.
   Виртуальная сеть	Выберите виртуальную сеть, в которой размещается вторичный экземпляр, с которым вы хотите выполнить пиринг. Если виртуальная сеть указана, но неактивна, это может быть связано с тем, что адресное пространство виртуальной сети перекрывается адресным пространством для этой виртуальной сети. Если адресные пространства виртуальной сети перекрываются, они не могут быть пиринговыми.
   Трафик в удаленную виртуальную сеть	Выберите "Разрешить" (по умолчанию)
   Трафик, перенаправленный из удаленной виртуальной сети	Параметр "Разрешено" (по умолчанию) и "Блокировать" будет работать для этого руководства. Дополнительные сведения см. в разделе "Создание пиринга".
   Route Server или шлюз виртуальной сети	Выберите Отсутствует. Дополнительные сведения о других доступных параметрах см. в разделе "Создание пиринга".

2. Выберите "Добавить ", чтобы настроить пиринг с выбранной виртуальной сетью. Через несколько секунд нажмите кнопку Обновить, и состояние пиринга изменится с Обновление на Подключено.

   

PowerShell

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

# Create global virtual network peering
$primaryVirtualNetwork  = Get-AzVirtualNetwork `
                  -Name $primaryVNet `
                  -ResourceGroupName $resourceGroupName

$secondaryVirtualNetwork = Get-AzVirtualNetwork `
                  -Name $secondaryVNet `
                  -ResourceGroupName $resourceGroupName
                  
Write-host "Peering primary VNet to secondary VNet..."
Add-AzVirtualNetworkPeering `
 -Name primaryVnet-secondaryVNet1 `
 -VirtualNetwork $primaryVirtualNetwork `
 -RemoteVirtualNetworkId $secondaryVirtualNetwork.Id
 Write-host "Primary VNet peered to secondary VNet successfully."

Write-host "Peering secondary VNet to primary VNet..."
Add-AzVirtualNetworkPeering `
 -Name secondaryVNet-primaryVNet `
 -VirtualNetwork $secondaryVirtualNetwork `
 -RemoteVirtualNetworkId $primaryVirtualNetwork.Id
Write-host "Secondary VNet peered to primary VNet successfully."

Write-host "Checking peering state on the primary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $primaryVNet `
| Select PeeringState

Write-host "Checking peering state on the secondary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $secondaryVNet `
| Select PeeringState

В этом фрагменте кода используются следующие команды:

Команда	Примечания.
1. Get-AzVirtualNetwork	Получает виртуальную сеть в группе ресурсов.
2. Add-AzVirtualNetworkPeering	Добавляет пиринг в виртуальную сеть.
3. Get-AzVirtualNetworkPeering	Получает пиринг для виртуальной сети.

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

Создайте группу отработки отказа для своих управляемых экземпляров, используя портал Azure или PowerShell.

Портал

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

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

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

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

   

4. На странице Группа отработки отказа экземпляра введите имя группы отработки отказа, а затем в раскрывающемся списке выберите вторичный управляемый экземпляр. Щелкните Создать, чтобы создать группу отработки отказа.

   

5. После завершения развертывания группы отработки отказа вы вернеесь на страницу группы отработки отказа.

PowerShell

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

# Create failover group
Write-host "Creating the failover group..."
$failoverGroup = New-AzSqlDatabaseInstanceFailoverGroup -Name $failoverGroupName `
     -Location $location -ResourceGroupName $resourceGroupName -PrimaryManagedInstanceName $primaryInstance `
     -PartnerRegion $drLocation -PartnerManagedInstanceName $secondaryInstance `
     -FailoverPolicy Manual -GracePeriodWithDataLossHours 1
$failoverGroup

Тестовая отработка отказа

Протестируйте отработку отказа для группы отработки отказа с помощью портала Azure или PowerShell.

Портал

Протестируйте отработку отказа для группы отработки отказа с помощью портала Azure.

1. Перейдите к вторичному управляемому экземпляру на портале Azure и выберите Группы отработки отказа экземпляра в разделе параметров.

2. Обратите внимание на управляемые экземпляры в первичной и вторичной роли.

3. Щелкните Отработка отказа, а затем нажмите Да в предупреждении о том, что сеансы TDS будут отключены.

   

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

   

Важно!

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

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

PowerShell

Проверьте плановая отработка отказа, отработка отказа на вторичный реплика, а затем отработка отказа.

Проверка ролей каждого сервера

Используйте команду Get-AzSqlDatabaseInstanceFailoverGroup, чтобы подтвердить роли каждого сервера:

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Отработка отказа на сервере-получателе

Используйте switch-AzSqlDatabaseFailoverGroup для отработки отказа на дополнительный сервер.

# Failover the primary managed instance to the secondary role
Write-host "Failing primary over to the secondary location"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to secondary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName

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

Используйте команду Switch-AzSqlDatabaseFailoverGroup, чтобы вернуться к основному серверу.

# Fail primary managed instance back to primary role
Write-host "Failing primary back to primary role"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to primary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Проверка ролей каждого сервера

Используйте команду Get-AzSqlDatabaseFailoverGroup, чтобы подтвердить роли каждого сервера.

# Check role of secondary replica
Write-host "Confirming the secondary replica is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Отработка отказа на сервере-получателе

Используйте switch-AzSqlDatabaseFailoverGroup для отработки отказа на дополнительный сервер.

# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully to" $drServerName 

Write-host "Confirming the secondary server is now primary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

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

Используйте команду Switch-AzSqlDatabaseFailoverGroup, чтобы вернуться к основному серверу.

# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully back to" $serverName

Определение конечной точки прослушивателя

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

Конечная точка прослушивателя имеет вид fog-name.database.windows.net и отображается на портале Azure при просмотре группы отработки отказа.

Создание группы между экземплярами в различных подписках

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

• При использовании API PowerShell можно сделать это, указав параметр PartnerSubscriptionId для вторичного управляемого экземпляра SQL.
• При использовании REST API каждый идентификатор экземпляра, входящий в параметр properties.managedInstancePairs, может иметь собственное значение "Идентификатор подписки".
• портал Azure не поддерживает создание групп отработки отказа в разных подписках.

Важно!

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

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

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

Примечание.

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

Изменение дополнительного региона

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

1. Создайте экземпляр C с тем же размером, что и A в той же зоне DNS.
2. Удалите группу отработки отказа между экземплярами A и B. На этом этапе попытки входа начинаются сбоем, так как псевдонимы SQL для прослушивателей группы отработки отказа были удалены, и шлюз не распознает имя группы отработки отказа. Базы данных-получатели отключены от первичных баз данных и становятся базами данных для чтения и записи.
3. Создайте группу отработки отказа с одинаковым именем между экземпляром A и C. Следуйте инструкциям в руководстве по настройке группы отработки отказа. Это операция с размером данных и завершается, когда все базы данных из экземпляра A заполнены и синхронизированы.
4. Удалите экземпляр B, если не требуется избежать ненужных расходов.

Примечание.

После выполнения шага 2 и до завершения шага 3 базы данных в экземпляре A останутся незащищенными от катастрофического сбоя экземпляра A.

Изменение основного региона

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

1. Создайте экземпляр C с тем же размером, что и B в той же зоне DNS.
2. Подключение экземпляр B и вручную отработка отказа, чтобы переключить основной экземпляр на B. Экземпляр A становится новым вторичным экземпляром автоматически.
3. Удалите группу отработки отказа между экземплярами A и B. На этом этапе попытки входа с помощью конечных точек группы отработки отказа начинают завершать сбой. Базы данных-получатели В отключены от первичных баз данных и становятся базами данных для чтения и записи.
4. Создайте группу отработки отказа с одинаковым именем между экземпляром B и C. Следуйте инструкциям в руководстве по группе отработки отказа. Это операция с размером данных и завершается, когда все базы данных из экземпляра A заполнены и синхронизированы. На этом этапе попытки входа перестают завершать сбой.
5. Отработка отказа вручную для переключения экземпляра C на основную роль. Экземпляр B автоматически становится новым вторичным экземпляром.
6. Удалите экземпляр A, если не требуется избежать ненужных расходов.

Внимание

После выполнения шага 3 и до завершения шага 4 базы данных в экземпляре A останутся незащищенными от катастрофического сбоя экземпляра A.

Важно!

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

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

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

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

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

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

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

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

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

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

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

Разрешения

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

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

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

Действие	Разрешение	Область применения
Создание группы отработки отказа	Доступ на запись для Azure RBAC	Основной управляемый экземпляр Дополнительный управляемый экземпляр
Обновление группы отработки отказа	Доступ на запись для Azure RBAC	Группа отработки отказа Все базы данных в управляемом экземпляре
Выполнение отработки отказа для группы отработки отказа	Доступ на запись для Azure RBAC	Группа отработки отказа в новом основном управляемом экземпляре

Ограничения

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

• Группы отработки отказа не могут быть созданы между двумя экземплярами в одном регионе Azure.
• Невозможно переименовать группы отработки отказа. Вам нужно будет удалить группу и создать ее повторно с другим именем.
• Группа отработки отказа содержит ровно два управляемых экземпляра. Добавление дополнительных экземпляров в группу отработки отказа не поддерживается.
• Экземпляр может участвовать только в одной группе отработки отказа в любой момент.
• Не удается создать группу отработки отказа между двумя экземплярами, принадлежащими разным клиентам Azure.
• Не удается создать группу отработки отказа между двумя экземплярами, принадлежащими разным подпискам Azure, с помощью портал Azure или Azure CLI. Вместо этого используйте Azure PowerShell или REST API для создания такой группы отработки отказа. После создания группа отработки отказа между подписками регулярно отображается в портал Azure и все последующие операции, включая отработку отказа, можно инициировать из портал Azure или Azure CLI.
• Переименование базы данных не поддерживается для баз данных в группе отработки отказа. Чтобы переименовать базу данных, необходимо временно удалить группу отработки отказа.
• Системные базы данных не реплицируются на вторичный экземпляр в группе отработки отказа. Таким образом, сценарии, зависящие от объектов системных баз данных, например, имени для входа на сервер и заданий агента, нуждаются в создании объектов вручную в дополнительных экземплярах, а также в ручной синхронизации после внесения любых изменений в основной экземпляр. Единственным исключением является главный ключ службы (SMK) для Управляемый экземпляр SQL, который автоматически реплика в дополнительный экземпляр во время создания группы отработки отказа. Однако любые последующие изменения SMK на основном экземпляре не будут реплика в дополнительный экземпляр. Для получения дополнительных сведений см. статью Включение сценариев, зависящих от объектов из системных баз данных.
• Группы отработки отказа нельзя создавать между экземплярами, если они находятся в пуле экземпляров.

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

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

PowerShell

Командлет	Description
New-AzSqlDatabaseInstanceFailoverGroup	Эта команда создает группу отработки отказа и регистрирует ее на основном сервере и сервере-получателе
Set-AzSqlDatabaseInstanceFailoverGroup	Изменяет конфигурацию отказоустойчивого кластера
Get-AzSqlDatabaseInstanceFailoverGroup	Извлекает конфигурацию группы отработки отказа
Switch-AzSqlDatabaseInstanceFailoverGroup	Запускает отработку отказа группы отработки отказа на вторичный экземпляр
Remove-AzSqlDatabaseInstanceFailoverGroup	Удаляет группу отработки отказа.

Azure CLI

Команда	Description
az sql instance-failover-group create	Создает группу отработки отказа и регистрирует ее на основном сервере и сервере-получателе.
az sql instance-failover-group delete	Удаляет группу отработки отказа с сервера
az sql instance-failover-group show	Извлекает конфигурацию группы отработки отказа
az sql instance-failover-group update	Изменяет конфигурацию группы отработки отказа и (или) добавляет одну или несколько баз данных в группу отработки отказа
az sql instance-failover-group set-primary	Запускает отработку отказа группы отработки отказа на сервер-получатель

REST API

API	Description
Создание или обновление группы отработки отказа	Создает или обновляет конфигурацию группы отработки отказа
Удаление группы отработки отказа	Удаляет группу отработки отказа с экземпляра
Плановая отработка отказа	Активирует отработку отказа с текущего первичного экземпляра на этот экземпляр с полной синхронизацией данных.
Принудительная отработка отказа (возможна потеря данных)	Активирует отработку отказа с текущего первичного экземпляра на вторичный без синхронизации данных. Эта операция может привести к потере данных.
Получение группы отработки отказа	извлекает конфигурацию группы отработки отказа.
Перечисление групп отработки отказа – Перечисление по расположению	Перечисляет группы отработки отказа в расположении.

Следующие шаги

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

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