Pour basculer, vous devez d’abord basculer les modes de réplication de l’instance SQL Server à l’aide de Transact-SQL (T-SQL).
Vous pouvez ensuite basculer et changer de rôle à l’aide de PowerShell.
Basculez le mode de réplication (basculement vers SQL MI)
La réplication entre SQL Server et SQL Managed Instance est asynchrone par défaut. Si vous basculez de SQL Server vers Azure SQL Managed Instance, avant de basculer votre base de données, basculez le lien vers le mode synchrone sur SQL Server à l’aide de Transact-SQL (T-SQL).
Remarque
- Ignorez cette étape si vous passez de SQL Managed Instance vers SQL Server 2022.
- La réplication synchrone sur de grandes distances de réseau peut ralentir les transactions sur le réplica principal.
Exécutez le script T-SQL suivant sur SQL Server pour changer le mode de réplication du groupe de disponibilité distribué en passant du mode asynchrone au mode synchrone. Remplacez :
<DAGName> par le nom du groupe de disponibilité distribué (utilisé pour créer le lien).<AGName> par le nom du groupe de disponibilité créé sur SQL Server (utilisé pour créer le lien).<ManagedInstanceName> par le nom de votre instance managée.
-- 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);
Pour confirmer que vous avez correctement changé le mode de réplication de la liaison, utilisez la vue de gestion dynamique suivante. Les résultats indiquent l’état 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
Maintenant que vous avez basculé SQL Server en mode de validation synchrone, la réplication entre les deux instances est synchrone. Si vous devez inverser cet état, suivez les mêmes étapes et définissez AVAILABILITY_MODE sur ASYNCHRONOUS_COMMIT.
Vérifiez les valeurs LSN sur SQL Server et SQL Managed Instance
Pour terminer le basculement ou la migration, confirmez que la réplication vers le secondaire est terminée. Pour ce faire, vérifiez que les numéros séquentiels dans le journal (LSN) correspondant aux enregistrements du journal de SQL Server et SQL Managed Instance sont identiques.
Il est prévu initialement que, le LSN du réplica principal soit plus élevé que celui du réplica secondaire. Le temps de réponse du réseau peut entraîner un certain décalage de la réplication par rapport au réplica principal. Comme la charge de travail a été arrêtée sur le principal, les LSN correspondront et cesseront de changer après un certain temps.
Utilisez la requête T-SQL suivante sur SQL Server pour lire le LSN du dernier journal des transactions enregistré. Remplacez :
<DatabaseName> par le nom de votre base de données et recherchez le dernier numéro LSN renforcé.
-- 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>'
Utilisez la requête T-SQL suivante sur SQL Managed Instance pour lire le dernier numéro LSN renforcé pour votre base de données. Remplacez <DatabaseName> par le nom de votre base de données.
Cette requête fonctionne sur une SQL Managed Instance à usage général. Pour une SQL Managed Instance critique pour l'entreprise, supprimez les marques de commentaire and drs.is_primary_replica = 1 à la fin du script. Sur le niveau de service critique pour l'entreprise, ce filtre garantit que les détails ne sont lus qu'à partir du réplica principal.
-- 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
Vous pouvez également utiliser la commande Get-AzSqlInstanceLink PowerShell ou Afficher la liaison az sql mi Azure CLI pour récupérer la propriété LastHardenedLsn de votre liaison sur SQL Managed Instance afin de fournir les mêmes informations que la requête T-SQL précédente.
Important
Vérifiez à nouveau que votre charge de travail est arrêtée sur le réplica principal. Vérifiez que les LSN sur SQL Server et SQL Managed Instance correspondent, et qu’ils restent identiques et inchangés pendant un certain temps. Des LSN stables sur les deux instances indiquent que le fichier journal d'activité a été répliqué sur le réplica secondaire et que la charge de travail est effectivement arrêtée.
Basculer une base de données
Si vous souhaitez utiliser PowerShell pour basculer une base de données entre SQL Server 2022 et SQL Managed Instance tout en maintenant la liaison, ou pour effectuer un basculement avec perte de données pour n'importe quelle version de SQL Server, utilisez l'Assistant Basculement entre SQL Server et Managed Instance dans SSMS pour générer le script pour votre environnement. Vous pouvez effectuer un basculement planifié à partir du réplica principal ou du réplica secondaire. Pour effectuer un basculement forcé, connectez-vous au réplica secondaire.
Pour rompre la liaison et arrêter la réplication en cas de basculement ou de migration de votre base de données, quelle que soit la version de SQL Server, utilisez la commande Remove-AzSqlInstanceLink PowerShell ou Supprimer la liaison az sql mi Azure CLI.
Attention
- Avant de basculer, arrêtez la charge de travail sur la base de données source pour permettre à la base de données répliquée de rattraper complètement son retard et de basculer sans perte de données. Si vous effectuez un basculement forcé ou si vous arrêtez la liaison avant la correspondance des LSN, vous risquez de perdre des données.
- Le basculement d'une base de données dans SQL Server 2019 et les versions antérieures rompt et supprime la liaison entre les deux réplicas. Vous ne pouvez pas effectuer de retour vers le réplica principal initial.
L'exemple de script suivant rompt la liaison et met fin à la réplication entre vos réplicas, en mettant la base de données en lecture/écriture sur les deux instances. Remplacez :
<ManagedInstanceName> par le nom de votre instance managée.<DAGName> par le nom du lien vers lequel vous basculez (sortie de la propriété Name à partir de la commande Get-AzSqlInstanceLink exécutée précédemment ci-dessus).
# 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
Après le processus de basculement, la liaison est supprimée et n’existe plus. La base de données SQL Server et la base de données SQL Managed Instance peuvent toutes deux exécuter des charges de travail en lecture et en écriture car elles sont désormais complètement indépendantes.
Important
Après le basculement réussi vers la SQL Managed Instance, reportez manuellement la chaîne de connexion de votre (vos) application(s) vers le FQDN de SQL Managed Instance pour terminer le processus de migration ou de basculement et continuer l'exécution dans Azure.
Une fois le lien supprimé, vous pouvez conserver le groupe de disponibilité sur SQL Server, mais vous devez supprimer le groupe de disponibilité distribué pour supprimer les métadonnées de lien de SQL Server. Cette étape supplémentaire n’est nécessaire que lorsque vous basculez à l’aide de PowerShell, car SSMS effectue cette action pour vous.
Pour supprimer votre groupe de disponibilité distribué, remplacez la valeur suivante, puis exécutez l’exemple de code T-SQL :
<DAGName> par le nom du groupe de disponibilité distribué sur SQL Server (utilisé pour créer le lien).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName>
GO
Azure SQL Managed Instance