Чтобы переключиться на резервный узел, сначала нужно изменить режим репликации экземпляра 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 Managed Instance совпадают.
Первоначально ожидается, что 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 в конце скрипта. На уровне обслуживания Business Critical этот фильтр гарантирует, что сведения считываются только из основной реплики.
-- 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 show в Azure CLI, чтобы получить свойство для вашей ссылки на 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 и более ранних версиях разрывает и удаляет связь между двумя репликами. Невозможно вернуться к исходному первичному.
Следующий пример скрипта нарушает связь и завершает репликацию между репликами, делая базу данных доступной для чтения и записи в обоих экземплярах. Замена:
-
<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 Managed Instance могут обе выполнять рабочие нагрузки на чтение и запись, так как теперь они полностью независимы друг от друга.
Внимание
После успешного переключения на Управляемый экземпляр 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