Чтобы выполнить отработку отказа, сначала необходимо переключить режимы репликации экземпляра SQL Server с помощью Transact-SQL (T-SQL).
Затем можно выполнить отработку отказа и переключить роли с помощью PowerShell.
Переключение режима репликации (отработка отказа на SQL MI)
Репликация между SQL Server и Управляемый экземпляр SQL по умолчанию является асинхронной. Если вы выполняете отработку отказа из SQL Server в Управляемый экземпляр SQL Azure, перед отработой отказа базы данных переключитесь на синхронный режим на SQL Server с помощью Transact-SQL (T-SQL).
Примечание.
- Пропустите этот шаг, если выполняется отработка отказа с Управляемый экземпляр SQL на SQL Server 2022.
- Синхронная репликация между большими сетевыми расстояниями может замедлить транзакции на первичной реплике.
Выполните следующий скрипт T-SQL на SQL Server, чтобы изменить режим репликации распределенной группы доступности с асинхронной синхронизации. Заменять:
<DAGName> с именем распределенной группы доступности (используется для создания ссылки).<AGName> с именем группы доступности, созданной на SQL Server (используется для создания ссылки).<ManagedInstanceName> именем управляемого экземпляра;
-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>]
MODIFY
AVAILABILITY GROUP ON
'<AGName>' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
'<ManagedInstanceName>' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
Чтобы убедиться, что режим репликации функции связи успешно изменен, используйте следующее динамическое административное представление. Результаты указывают на состояние SYNCHRONOUS_COMMIT.
-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
ag.name, ag.is_distributed, ar.replica_server_name,
ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
ars.operational_state_desc, ars.synchronization_health_desc
FROM
sys.availability_groups ag
join sys.availability_replicas ar
on ag.group_id=ar.group_id
left join sys.dm_hadr_availability_replica_states ars
on ars.replica_id=ar.replica_id
WHERE
ag.is_distributed=1
Теперь, когда вы переключили SQL Server на режим синхронной фиксации, репликация между двумя экземплярами синхронна. Если необходимо изменить это состояние, выполните те же действия и задайте для нее AVAILABILITY_MODE значение ASYNCHRONOUS_COMMIT.
Проверка значений номеров LSN как в SQL Server, так и в Управляемом экземпляре SQL
Чтобы завершить отработку отказа или миграцию, убедитесь, что репликация на дополнительный объект завершена. Для этого убедитесь, что номера последовательности журналов (LSN) в записях журнала для SQL Server и Управляемый экземпляр SQL одинаковы.
Первоначально ожидается, что LSN на первичном сервере выше, чем LSN на вторичном. Задержка в сети может привести к задержке репликации несколько за основной. Так как рабочая нагрузка остановлена на основном сервере, имена LSN будут соответствовать и перестать изменяться через некоторое время.
Используйте следующий запрос T-SQL в SQL Server, чтобы считать номер LSN последнего записанного журнала транзакций. Замена:
<DatabaseName> с именем базы данных и найдите последний защищенный номер LSN.
-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
ag.name AS [Replication group],
db.name AS [Database name],
drs.database_id AS [Database ID],
drs.group_id,
drs.replica_id,
drs.synchronization_state_desc AS [Sync state],
drs.end_of_log_lsn AS [End of log LSN],
drs.last_hardened_lsn AS [Last hardened LSN]
FROM
sys.dm_hadr_database_replica_states drs
inner join sys.databases db on db.database_id = drs.database_id
inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
ag.is_distributed = 1 and db.name = '<DatabaseName>'
Используйте следующий запрос T-SQL в Управляемом экземпляре SQL, чтобы считать последний зафиксированный номер LSN для базы данных. Замените <DatabaseName> именем базы данных.
Этот запрос работает с Управляемый экземпляр SQL общего назначения. Для критически важный для бизнеса Управляемый экземпляр SQL раскомментируйте and drs.is_primary_replica = 1 его в конце скрипта. На уровне служб критически важный для бизнеса этот фильтр гарантирует, что сведения считываются только из основной реплики.
-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
db.name AS [Database name],
drs.database_id AS [Database ID],
drs.group_id,
drs.replica_id,
drs.synchronization_state_desc AS [Sync state],
drs.end_of_log_lsn AS [End of log LSN],
drs.last_hardened_lsn AS [Last hardened LSN]
FROM
sys.dm_hadr_database_replica_states drs
inner join sys.databases db on db.database_id = drs.database_id
WHERE
db.name = '<DatabaseName>'
-- for Business Critical, add the following as well
-- AND drs.is_primary_replica = 1
Кроме того, можно использовать команду Get-AzSqlInstanceLink PowerShell или az sql mi link, чтобы получить LastHardenedLsn свойство для ссылки на Управляемый экземпляр SQL, чтобы предоставить те же сведения, что и предыдущий запрос T-SQL.
Внимание
Убедитесь, что рабочая нагрузка остановлена на первичной. Убедитесь, что LSN в SQL Server и Управляемый экземпляр SQL совпадают, и что они остаются совпадающими и неизменными в течение некоторого времени. Стабильные LSN в обоих экземплярах указывают, что журнал хвоста реплицируется во вторичную и рабочая нагрузка фактически останавливается.
Отработка отказа базы данных
Если вы хотите использовать PowerShell для отработки отказа базы данных между SQL Server 2022 и Управляемый экземпляр SQL при сохранении связи или для отработки отказа с потерей данных для любой версии SQL Server, используйте мастер отработки отказа между SQL Server и Управляемый экземпляр в SSMS для создания скрипта для вашей среды. Вы можете выполнить плановая отработка отказа из первичной или вторичной реплики. Для принудительной отработки отказа подключитесь к вторичной реплике.
Чтобы разорвать ссылку и остановить репликацию при отработке отказа или переносе базы данных независимо от версии SQL Server, используйте команду Remove-AzSqlInstanceLink PowerShell или az sql mi link delete Azure CLI.
Внимание
- Прежде чем выполнить отработку отказа, остановите рабочую нагрузку в исходной базе данных, чтобы позволить реплицированной базе данных полностью выполнить перехват и отработку отказа без потери данных. Если вы выполняете принудительной отработки отказа или если вы прерываете ссылку до сопоставления LSN, может потерять данные.
- Отработка отказа базы данных в SQL Server 2019 и более ранних версиях прерывает работу и удаляет связь между двумя репликами. Не удается вернуться к исходному первичному источнику.
- Отработка отказа базы данных при сохранении ссылки на SQL Server 2022 в настоящее время находится в предварительной версии.
Следующий пример скрипта нарушает связь и завершает репликацию между репликами, что делает базу данных чтением и записью в обоих экземплярах. Замена:
<ManagedInstanceName> именем управляемого экземпляра;<DAGName> с именем отработки отказа ссылки (выходные данные свойства Name из Get-AzSqlInstanceLink команды, выполненной ранее выше).
# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====
# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"
# ==== Do not customize the following cmdlet ====
# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName
# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force
После успешной отработки отказа ссылка удаляется и больше не существует. База данных SQL Server и база данных Управляемый экземпляр SQL могут выполнять рабочие нагрузки чтения и записи, так как они теперь полностью независимы.
Внимание
После успешного отработки отказа до Управляемый экземпляр SQL вручную укажите строка подключения приложения в полное доменное имя управляемого экземпляра SQL, чтобы завершить миграцию или выполнить отработку отказа и продолжить работу в Azure.
После удаления ссылки можно сохранить группу доступности в SQL Server, но необходимо удалить распределенную группу доступности, чтобы удалить метаданные ссылки из SQL Server. Этот дополнительный шаг необходим только при отработки отказа с помощью PowerShell, так как SSMS выполняет это действие.
Чтобы удалить распределенную группу доступности, замените следующее значение и запустите пример кода T-SQL:
<DAGName> с именем распределенной группы доступности в SQL Server (используется для создания ссылки).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName>
GO
Управляемый экземпляр SQL Azure