Share via

Configurer la liaison avec des scripts – Azure SQL Managed Instance

  • Article

S’applique à :Azure SQL Managed Instance

Cet article vous explique comment configurer une liaison entre SQL Server et Azure SQL Managed Instance avec Transact-SQL et PowerShell ou des scripts Azure CLI. Grâce à cette liaison, les bases de données de votre système principal initial sont répliquées sur votre réplica secondaire en quasi-temps réel.

Une fois la liaison créée, vous pouvez basculer sur votre réplica secondaire à des fins de migration ou de récupération d'urgence.

Remarque

Vue d’ensemble

Utilisez la fonctionnalité de liaison pour répliquer les bases de données de votre réplica principal initial vers votre réplica secondaire. Pour SQL Server 2022, le réplica principal initial peut être soit SQL Server, soit Azure SQL Managed Instance. Pour SQL Server 2019 et versions antérieures, le réplica principal initial doit être SQL Server. Une fois la liaison configurée, les bases de données du réplica principal initial sont répliquées vers le réplica secondaire.

Vous pouvez choisir de laisser la liaison en place pour une réplication continue des données dans un environnement hybride entre le réplica principal et le réplica secondaire, ou vous pouvez basculer la base de données vers le réplica secondaire, pour migrer vers Azure ou pour une récupération d'urgence. Pour SQL Server 2019 et les versions antérieures, le basculement vers Azure SQL Managed Instance rompt la liaison et le retour n'est pas pris en charge. Avec SQL Server 2022, vous avez la possibilité de maintenir la liaison et d'effectuer des allers-retours entre les deux réplicas – cette fonctionnalité est actuellement en aperçu.

Si vous prévoyez d'utiliser votre Managed Instance secondaire uniquement pour la récupération d'urgence, vous pouvez réduire les coûts de licence en activant l'avantage du basculement hybride.

Suivez les instructions de cet article pour configurer manuellement la liaison entre SQL Server et Azure SQL Managed Instance. Une fois la liaison créée, votre base de données source reçoit une copie en lecture seule sur votre réplica secondaire cible.

Conseil

  • Pour simplifier l'utilisation de scripts T-SQL avec les paramètres adaptés à votre environnement, nous vous recommandons vivement d'utiliser l'Assistant Liaison Managed Instance dans SQL Server Management Studio (SSMS) pour générer le script de création de la liaison. Dans la page Résumé de la fenêtre Nouvelle liaison Managed Instance, sélectionnez Script au lieu de Terminer.

Prérequis

Remarque

Certaines fonctionnalités de la liaison sont en disponibilité générale, tandis que d’autres sont en préversion. Évaluez la prise en charge de version pour en savoir plus.

Pour répliquer vos bases de données, vous devez disposer des conditions préalables suivantes :

Tenez compte des éléments suivants :

  • La fonctionnalité de liaison prend en charge une base de données par liaison. Pour répliquer plusieurs bases de données sur une instance, créez une liaison pour chaque base de données individuelle. Par exemple, pour répliquer 10 bases de données sur SQL Managed Instance, créez 10 liaisons individuelles.
  • Le classement entre SQL Server et SQL Managed Instance doit être identique. Une incohérence dans le classement peut entraîner une incohérence de la casse du nom de serveur, et empêcher la connexion de SQL Server à SQL Managed Instance.
  • L'erreur 1475 sur votre SQL Server principal initial indique que vous devez démarrer une nouvelle chaîne de sauvegarde en créant une sauvegarde complète sans l'option COPY ONLY.

Autorisations

Pour SQL Server, vous devez disposer des autorisations sysadmin.

Pour Azure SQL Managed Instance, vous devez être membre du Collaborateur SQL Managed Instance ou disposer des autorisations suivantes pour un rôle personnalisé :

Ressource Microsoft.Sql/ Autorisations nécessaires
Microsoft.Sql/managedInstances /read, /write
Microsoft.Sql/managedInstances/hybridCertificate /action
Microsoft.Sql/managedInstances/databases /read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates /read
Microsoft.Sql/managedInstances/hybridLink /read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates /write, /delete, /read

Terminologie et conventions d’affectation de noms

Lors de l’exécution de scripts à partir de ce guide de l’utilisateur, il est important de ne pas confondre les noms de SQL Server et de SQL Managed Instance avec leurs noms de domaine complets. Le tableau suivant explique ce que les différents noms représentent exactement, et comment obtenir leurs valeurs :

Terminologie Description Comment trouver
Réplica principal initial 1 SQL Server ou SQL Managed Instance à partir de laquelle vous créez initialement la liaison pour répliquer votre base de données vers le réplica secondaire.
Réplica principal SQL Server ou SQL Managed Instance qui héberge actuellement la base de données primaire.
Réplica secondaire SQL Server ou SQL Managed Instance qui reçoit des données répliquées en quasi-temps réel à partir du réplica principal actuel.
Nom SQL Server Nom de SQL Server en un mot court. Par exemple : sqlserver1. Exécutez SELECT @@SERVERNAME à partir de T-SQL.
FQDN SQL Server Nom de domaine complet (FQDN) de votre SQL Server. Par exemple : sqlserver1.domain.com. Si vous utilisez une machine virtuelle Azure, consultez votre configuration réseau (DNS) locale ou le nom du serveur.
Nom de l’instance gérée SQL Nom de SQL Managed Instance en un mot court. Par exemple : managedinstance1. Consultez le nom de votre instance managée dans le portail Azure.
FQDN SQL Managed Instance Nom de domaine complet (FQDN) de votre SQL Managed Instance. Par exemple : managedinstance1.6d710bcf372b.database.windows.net. Consultez le nom d’hôte dans la page de vue d’ensemble SQL Managed Instance dans le portail Azure.
Nom de domaine pouvant être résolu Nom DNS qui peut être résolu en une adresse IP. Par exemple, l’exécution de nslookup sqlserver1.domain.com devrait retourner une adresse IP telle que 10.0.0.1. Exécutez la commande nslookup à partir de l’invite de commandes.
Adresse IP du SQL Server Adresse IP de votre SQL Server. Si plusieurs adresses IP du SQL Server sont disponibles, choisissez-en une accessible à partir d’Azure. Exécutez la commande ipconfig à partir de l’invite de commandes du système d’exploitation hôte exécutant le SQL Server.

1 La configuration d'Azure SQL Managed Instance comme votre réplica principal initial est actuellement en aperçu et n'est prise en charge qu'à partir de SQL Server 2022 CU10.

Configurer la récupération et la sauvegarde de base de données

Si SQL Server est votre réplica principal initial, les bases de données qui seront répliquées via la liaison doivent être dans le mode de récupération complète et disposer d'au moins une sauvegarde. Azure SQL Managed Instance effectue des sauvegardes automatiquement. Il est alors recommandé d'ignorer cette étape si SQL Managed Instance est votre réplica principal initial. primary

Exécutez le code suivant sur SQL Server pour toutes les bases de données que vous souhaitez répliquer. Remplacez <DatabaseName> par le nom de votre base de données.

-- Run on SQL Server
-- Set full recovery model for all databases you want to replicate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to replicate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Pour plus d’informations, consultez Créer une sauvegarde complète de base de données.

Remarque

La liaison prend uniquement en charge la réplication des bases de données utilisateur. La réplication des bases de données système n’est pas prise en charge. Pour répliquer des objets au niveau de l’instance (stockés dans des bases de données master ou msdb), nous vous recommandons de les scripter et d’exécuter des scripts T-SQL sur l’instance de destination.

Établir l’approbation entre des instances

Tout d'abord, vous devez établir la confiance entre les deux instances et sécuriser les points de terminaison utilisés pour communiquer et chiffrer les données sur le réseau. Les groupes de disponibilité distribués utilisent le point de terminaison de mise en miroir de bases de données du groupe de disponibilité existant, au lieu d’avoir leur propre point de terminaison dédié. À ce titre, la sécurité et la confiance doivent être configurées entre les deux instances par l'intermédiaire du point de terminaison de mise en miroir de la base de données du groupe de disponibilité.

Remarque

La liaison est basée sur la technologie des groupes de disponibilité Always On. Le point de terminaison de mise en miroir de bases de données est destiné à l’usage spécifique des groupes de disponibilité pour recevoir les connexions d’autres instances. Le terme point de terminaison de mise en miroir de la base de données n'est pas à confondre avec la fonctionnalité héritée de mise en miroir de la base de données SQL Server.

L’approbation basée sur un certificat est le seul moyen pris en charge pour sécuriser les points de terminaison de mise en miroir de bases de données pour SQL Server et SQL Managed Instance. Si vous avez des groupes de disponibilité qui utilisent l’authentification Windows, vous devez ajouter l’approbation basée sur un certificat au point de terminaison de mise en miroir existant en guise d’option d’authentification secondaire. Vous pouvez le faire à l’aide de l’instruction ALTER ENDPOINT, comme expliqué plus loin dans cet article.

Important

Les certificats sont générés avec une date et une heure d’expiration. Ils doivent être renouvelés et faire l’objet d’une rotation avant leur expiration.

La liste suivante présente une vue d'ensemble du processus de sécurisation des points de terminaison de la mise en miroir des bases de données pour SQL Server et SQL Managed Instance :

  1. Générez un certificat sur SQL Server et obtenez sa clé publique.
  2. Obtenez la clé publique du certificat SQL Managed Instance.
  3. Échangez les clés publiques entre SQL Server et SQL Managed Instance.
  4. Importer des clés d’autorité de certification racine approuvée par Azure dans SQL Server

Les sections suivantes décrivent ces étapes en détail.

Créer un certificat sur SQL Server et importer sa clé publique vers SQL Managed Instance

Tout d'abord, créez la clé principale de la base de données dans la base de données master, si elle n'existe pas déjà. Insérez votre mot de passe à la place de <strong_password> dans le script suivant et conservez-le dans un lieu confidentiel et sûr. Exécutez ce script T-SQL sur SQL Server :

-- Run on SQL Server
-- Create a master key encryption password
-- Keep the password confidential and in a secure place
USE MASTER
IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
BEGIN
    PRINT 'Creating master key.' + CHAR(13) + 'Keep the password confidential and in a secure place.'
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>'
END
ELSE
    PRINT 'Master key already exists.'
GO

Ensuite, générez un certificat d’authentification sur SQL Server. Dans le script suivant, remplacez :

  • @cert_expiry_date par la date d’expiration du certificat souhaitée (date future).

Enregistrez cette date et définissez un rappel pour la rotation (mise à jour) du certificat du serveur SQL avant sa date d'expiration afin d'assurer l'opération continue de la liaison.

Important

Il est vivement recommandé d’utiliser le nom de certificat généré automatiquement à partir de ce script. Si la personnalisation du nom de votre certificat est autorisée sur SQL Server, le nom ne doit pas contenir de caractères \.

-- Create the SQL Server certificate for the instance link
USE MASTER

-- Customize SQL Server certificate expiration date by adjusting the date below
DECLARE @cert_expiry_date AS varchar(max)='03/30/2025'

-- Build the query to generate the certificate
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @sqlserver_certificate_subject NVARCHAR(MAX) = N'Certificate for ' + @sqlserver_certificate_name
DECLARE @create_sqlserver_certificate_command NVARCHAR(MAX) = N'CREATE CERTIFICATE [' + @sqlserver_certificate_name + '] ' + char (13) +
'    WITH SUBJECT = ''' + @sqlserver_certificate_subject + ''',' + char (13) +
'    EXPIRY_DATE = '''+ @cert_expiry_date + ''''+ char (13)
IF NOT EXISTS (SELECT name from sys.certificates WHERE name = @sqlserver_certificate_name)
BEGIN
    PRINT (@create_sqlserver_certificate_command)
    -- Execute the query to create SQL Server certificate for the instance link
    EXEC sp_executesql @stmt = @create_sqlserver_certificate_command
END
ELSE
    PRINT 'Certificate ' + @sqlserver_certificate_name + ' already exists.'
GO

Ensuite, utilisez la requête T-SQL suivante sur SQL Server pour vérifier que le certificat a été créé :

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

Dans les résultats de la requête, vous verrez que le certificat a été chiffré avec la clé principale.

Vous pouvez maintenant obtenir la clé publique du certificat généré sur SQL Server :

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @PUBLICKEYENC VARBINARY(MAX) = CERTENCODED(CERT_ID(@sqlserver_certificate_name));
SELECT @sqlserver_certificate_name as 'SQLServerCertName'
SELECT @PUBLICKEYENC AS SQLServerPublicKey;

Enregistrez les valeurs de SQLServerCertName et de SQLServerPublicKey à partir de la production, car vous en aurez besoin à l'étape suivante lorsque vous importerez le certificat.

Commencez par vérifier que vous êtes connecté à Azure et que vous avez sélectionné l’abonnement dans lequel votre instance gérée est hébergée. La sélection de l’abonnement approprié est particulièrement importante si vous avez plusieurs abonnements Azure sur votre compte.

Remplacez <SubscriptionID> par l’identifiant de votre abonnement Azure.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

Utilisez ensuite la commande New-AzSqlInstanceServerTrustCertificate PowerShell ou Créer az sql mi partner-cert Azure CLI pour charger la clé publique du certificat d'authentification de SQL Server vers Azure, comme l'exemple PowerShell suivant.

Renseignez les informations utilisateur nécessaires, copiez-les, collez-les, puis exécutez le script. Remplacez :

  • <SQLServerPublicKey> par la partie publique du certificat SQL Server au format binaire, que vous avez enregistré à l’étape précédente. Il s’agit d’une valeur de chaîne longue qui commence par 0x.
  • <SQLServerCertName> par le nom de certificat SQL Server que vous avez enregistré à l’étape précédente.
  • <ManagedInstanceName> par le nom abrégé de votre instance managée.
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO IMPORT SQL SERVER PUBLIC CERTIFICATE TO SQL MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter the name for the server SQLServerCertName certificate – for example, "Cert_sqlserver1_endpoint"
$CertificateName = "<SQLServerCertName>"

# Insert the certificate public key blob that you got from SQL Server – for example, "0x1234567..."
$PublicKeyEncoded = "<SQLServerPublicKey>"

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the below cmdlets====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Upload the public key of the authentication certificate from SQL Server to Azure.
New-AzSqlInstanceServerTrustCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $CertificateName -PublicKey $PublicKeyEncoded

Le résultat de cette opération est un récapitulatif du certificat SQL Server chargé dans Azure.

Si vous avez besoin de voir tous les certificats SQL Server chargés dans une Managed Instance, utilisez la commande Get-AzSqlInstanceServerTrustCertificate PowerShell ou Lister az sql mi partner-cert Azure CLI dans Azure Cloud Shell. Pour supprimer un certificat SQL Server chargé dans une SQL Managed Instance, utilisez la commande Remove-AzSqlInstanceServerTrustCertificate PowerShell ou Supprimer az sql mi partner-cert Azure CLI dans Azure Cloud Shell.

Obtenir la clé publique du certificat à partir de SQL Managed Instance et l’importer dans SQL Server

Le certificat destiné à sécuriser le point de terminaison de liaison est généré automatiquement sur Azure SQL Managed Instance. Obtenez la clé publique du certificat à partir de SQL Managed Instance et importez-la dans SQL Server en utilisant la commande Get-AzSqlInstanceEndpointCertificate PowerShell ou Afficher az sql mi endpoint-cert Azure CLI comme l'exemple PowerShell suivant.

Attention

Avec Azure CLI, vous devrez ajouter manuellement 0x devant la sortie PublicKey lorsque vous l’utiliserez aux étapes suivantes. Par exemple, voici à quoi ressemblera la PublicKey : « 0x3082033E30... ».

Exécutez le script suivant. Remplacez :

  • <SubscriptionID> par votre ID d’abonnement Azure.
  • <ManagedInstanceName> par le nom abrégé de votre instance managée.
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO EXPORT MANAGED INSTANCE PUBLIC CERTIFICATE
# ===== Enter user variables here ====

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Fetch the public key of the authentication certificate from Managed Instance. Outputs a binary key in the property PublicKey.
Get-AzSqlInstanceEndpointCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -EndpointType "DATABASE_MIRRORING" | out-string

Copiez l’intégralité de la sortie PublicKey (commence par 0x), car vous en aurez besoin à l’étape suivante.

Si vous rencontrez des problèmes pour copier-coller la PublicKey, vous pouvez aussi exécuter la commande T-SQL EXEC sp_get_endpoint_certificate 4 sur l’instance managée pour obtenir sa clé publique pour le point de terminaison de liaison.

Ensuite, importez la clé publique obtenue du certificat de sécurité d’instance managée dans SQL Server. Exécutez la requête suivante sur SQL Server. Remplacez :

  • <ManagedInstanceFQDN> par le nom de domaine complet de l’instance gérée.
  • <PublicKey> par la valeur PublicKey obtenue à l’étape précédente (d’Azure Cloud Shell, commençant par 0x). Vous n’avez pas besoin d’utiliser des guillemets.

Important

Le nom du certificat doit être le FQDN de SQL Managed Instance et ne doit pas être modifié. Le lien ne sera pas opérationnel si vous utilisez un nom personnalisé.

-- Run on SQL Server
USE MASTER
CREATE CERTIFICATE [<ManagedInstanceFQDN>]
FROM BINARY = <PublicKey>

Importer des clés d’autorité de certification racine approuvée par Azure dans SQL Server

L’importation de clés de certificat racine publiques des autorités de certification Microsoft et DigiCert dans SQL Server est requise pour que votre SQL Server approuve les certificats émis par Azure pour les domaines database.windows.net.

Attention

Vérifiez que la PublicKey commence par 0x. Vous devrez peut-être l'ajouter manuellement au début de la clé publique si elle ne s'y trouve pas déjà.

Commencez par importer le certificat d’autorité racine d’infrastructure de clés publiques (PKI) Microsoft sur SQL Server :

-- Run on SQL Server
-- Import Microsoft PKI root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'MicrosoftPKI')
BEGIN
    PRINT 'Creating MicrosoftPKI certificate.'
    CREATE CERTIFICATE [MicrosoftPKI] FROM BINARY = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3

    --Trust certificates issued by Microsoft PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('MicrosoftPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate MicrosoftPKI already exsits.'
GO

Ensuite, importez le certificat d’autorité racine d’infrastructure de clés publiques (PKI) DigiCert sur SQL Server :

-- Run on SQL Server
-- Import DigiCert PKI root-authority certificate trusted by Azure to SQL Server, if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'DigiCertPKI')
BEGIN
    PRINT 'Creating DigiCertPKI certificate.'
    CREATE CERTIFICATE [DigiCertPKI] FROM BINARY = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D0

    --Trust certificates issued by DigiCert PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('DigiCertPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate DigiCertPKI already exsits.'
GO

Pour finir, vérifiez tous les certificats créés à l’aide de la vue de gestion dynamique (DMV) suivante :

-- Run on SQL Server
SELECT * FROM sys.certificates

Sécuriser le point de terminaison de mise en miroir de bases de données

Si vous ne disposez pas d'un groupe de disponibilité existant ou d'un point de terminaison de mise en miroir de la base de données sur le SQL Server, l'étape suivante consiste à créer un point de terminaison de mise en miroir de la base de données sur SQL Server et à le sécuriser à l'aide du certificat SQL Server généré précédemment. Si vous disposez d'un groupe de disponibilité ou d'un point de terminaison de mise en miroir existant, passez à la section Modifier un point de terminaison existant.

Créer et sécuriser le point de terminaison de mise en miroir de bases de données sur SQL Server

Pour vérifier que vous n’avez pas de point de terminaison de mise en miroir de bases de données, utilisez le script suivant :

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT * FROM sys.database_mirroring_endpoints WHERE type_desc = 'DATABASE_MIRRORING'

Si la requête précédente montre qu’il n’existe pas de point de terminaison de mise en miroir de bases de données, exécutez le script suivant sur SQL Server pour obtenir le nom du certificat SQL Server généré précédemment.

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
SELECT @sqlserver_certificate_name as 'SQLServerCertName'

Enregistrez SQLServerCertName à partir de la sortie, car vous en aurez besoin à l’étape suivante.

Utilisez le script suivant pour créer un nouveau point de terminaison de mise en miroir de la base de données sur le port 5022 et sécuriser le point de terminaison avec le certificat SQL Server. Remplacez :

  • <SQL_SERVER_CERTIFICATE> par le nom SQLServerCertName obtenu à l’étape précédente.
-- Run on SQL Server
-- Create a connection endpoint listener on SQL Server
USE MASTER
CREATE ENDPOINT database_mirroring_endpoint
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

Confirmez que le point de terminaison de mise en miroir a été créé en exécutant le script suivant sur SQL Server :

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc,
    connection_auth_desc, is_encryption_enabled, encryption_algorithm_desc
FROM 
    sys.database_mirroring_endpoints

La colonne state_desc du point de terminaison créé avec succès devrait indiquer STARTED.

Le nouveau point de terminaison de mise en miroir a été créé avec l’authentification par certificat et le chiffrement AES activés.

Modifier un point de terminaison existant

Notes

Ignorez cette étape si vous venez de créer un point de terminaison de mise en miroir. Effectuez cette étape uniquement si vous utilisez des groupes de disponibilité existants avec un point de terminaison de mise en miroir de bases de données existant.

Si vous utilisez des groupes de disponibilité existants pour la liaison, ou s’il existe déjà un point de terminaison de mise en miroir de bases de données, commencez par vérifier qu’il remplit les conditions obligatoires suivantes pour la liaison :

  • Le type doit être DATABASE_MIRRORING.
  • L’authentification de la connexion doit être CERTIFICATE.
  • Le chiffrement doit être activé.
  • L’algorithme de chiffrement doit être AES.

Exécutez la requête suivante sur SQL Server pour afficher les détails d’un point de terminaison de mise en miroir de bases de données existant :

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Si la sortie indique que le point de terminaison DATABASE_MIRRORING existant connection_auth_desc n’est pas CERTIFICATE, ou que encryption_algorthm_desc n’est pas AES, le point de terminaison doit être modifié pour répondre aux exigences.

Sur SQL Server, le même point de terminaison de mise en miroir de bases de données est utilisé à la fois pour les groupes de disponibilité et pour les groupes de disponibilité distribués. Si votre point de terminaison connection_auth_desc est NTLM (authentification Windows) ou KERBEROS, et que vous avez besoin de l’authentification Windows pour un groupe de disponibilité existant, il est possible de modifier le point de terminaison de façon à utiliser plusieurs méthodes d’authentification en basculant l’option d’authentification sur NEGOTIATE CERTIFICATE. Cette modification permet au groupe de disponibilité existant d'utiliser l'authentification Windows, tout en utilisant l'authentification par certificat pour SQL Managed Instance.

De même, si le chiffrement n’inclut pas AES et que vous avez besoin d’un chiffrement RC4, il est possible de modifier le point de terminaison pour utiliser les deux algorithmes. Pour plus d’informations sur les options possibles pour la modification des points de terminaison, consultez la page de documentation relative à sys.database_mirroring_endpoints.

Le script suivant illustre comment modifier votre point de terminaison de mise en miroir de bases de données existant sur SQL Server. Remplacez :

  • <YourExistingEndpointName> par le nom de votre point de terminaison existant.
  • <SQLServerCertName> par le nom du certificat SQL Server généré (obtenu dans l’une des étapes précédentes ci-dessus).

Selon votre configuration spécifique, vous devrez peut-être personnaliser davantage le script. Vous pouvez également utiliser SELECT * FROM sys.certificates pour obtenir le nom du certificat créé sur SQL Server.

-- Run on SQL Server
-- Alter the existing database mirroring endpoint to use CERTIFICATE for authentication and AES for encryption
USE MASTER
ALTER ENDPOINT [<YourExistingEndpointName>]   
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE CERTIFICATE [<SQLServerCertName>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )
GO

Après avoir exécuté la requête de point de terminaison ALTER et défini le mode d’authentification double sur Windows et Certificat, utilisez à nouveau cette requête sur SQL Server pour afficher les détails du point de terminaison de mise en miroir de bases de données :

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Vous avez correctement modifié votre point de terminaison de mise en miroir de bases de données pour une liaison SQL Managed Instance.

Créer un groupe de disponibilité sur SQL Server

Si vous ne disposez pas de groupe de disponibilité existant, l'étape suivante consiste à en créer un sur SQL Server, quel que soit le réplica principal initial. Les commandes pour créer le groupe de disponibilité sont différentes si votre SQL Managed Instance est le réplica principal initial, ce qui n'est pris en charge qu'à partir de SQL Server 2022 CU10.

Bien qu'il soit possible d'établir plusieurs liaisons pour la même base de données, la liaison ne prend en charge que la réplication d'une seule base de données par liaison. Si vous souhaitez créer plusieurs liaisons pour la même base de données, utilisez le même groupe de disponibilité pour toutes les liaisons, mais créez ensuite un nouveau groupe de disponibilité distribué pour chaque liaison de base de données entre SQL Server et SQL Managed Instance.

Si SQL Server est votre serveur principal initial, créez un groupe de disponibilité avec les paramètres suivants pour une liaison :

  • Nom du serveur principal initial
  • Nom de la base de données
  • Mode de basculement MANUAL
  • Mode d’amorçage AUTOMATIC

Tout d’abord, recherchez le nom de votre SQL Server en exécutant l’instruction T-SQL suivante :

-- Run on the initial primary
SELECT @@SERVERNAME AS SQLServerName

Utilisez ensuite le script suivant pour créer un groupe de disponibilité sur SQL Server. Remplacez :

  • <AGName> par le nom de votre groupe de disponibilité. Une liaison Managed Instance requiert une base de données par groupe de disponibilité. Pour plusieurs bases de données, vous devez créer plusieurs groupes de disponibilité. Pensez à nommer chaque groupe de disponibilité afin que son nom reflète la base de données correspondante, par exemple AG_<db_name>.
  • <DatabaseName> par le nom de la base de données que vous souhaitez répliquer.
  • <SQLServerName> par le nom de votre instance SQL Server obtenue à l’étape précédente.
  • <SQLServerIP> par l’adresse IP de SQL Server. Vous pouvez utiliser un nom d’ordinateur hôte SQL Server résolvable en guise d’alternative, mais vous devez vérifier que ce nom peut être résolu à partir du réseau virtuel SQL Managed Instance.
-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = NONE) -- <- Delete this line for SQL Server 2016 only. Leave as-is for all higher versions.
    FOR database [<DatabaseName>]  
    REPLICA ON   
        N'<SQLServerName>' WITH   
            (  
            ENDPOINT_URL = 'TCP://<SQLServerIP>:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

Important

Pour SQL Server 2016, supprimez WITH (CLUSTER_TYPE = NONE) de l’instruction T-SQL ci-dessus. Laissez-la telle quelle pour toutes les versions ultérieures de SQL Server.

Ensuite, créez le groupe de disponibilité distribué sur SQL Server. Si vous prévoyez de créer plusieurs liaisons, vous devez créer un groupe de disponibilité distribué pour chaque liaison, même si vous établissez plusieurs liaisons pour la même base de données.

Remplacez les valeurs suivantes, puis exécutez le script T-SQL pour créer votre groupe de disponibilité distribué.

  • <DAGName> par le nom de votre groupe de disponibilité distribué. Vous pouvez configurer plusieurs liaisons pour la même base de données en créant un groupe de disponibilité distribué pour chaque liaison, pensez donc à nommer chaque groupe de disponibilité distribué en conséquence – par exemple, DAG1_<db_name>, DAG2_<db_name>
  • <AGName> par le nom du groupe de disponibilité créé à l’étape précédente.
  • <SQLServerIP> par l’adresse IP de SQL Server indiquée à l’étape précédente. Vous pouvez à la place utiliser un nom d’ordinateur hôte SQL Server qui peut être résolu, mais vérifiez que ce nom peut être résolu à partir du réseau virtuel SQL Managed Instance (ce qui nécessite de configurer Azure DNS de façon personnalisée pour le sous-réseau de l’instance managée).
  • <ManagedInstanceName> par le nom abrégé de votre instance managée.
  • <ManagedInstanceFQDN> par le nom de domaine complet de votre instance managée.
-- Run on SQL Server
-- Create a distributed availability group for the availability group and database
-- ManagedInstanceName example: 'sqlmi1'
-- ManagedInstanceFQDN example: 'sqlmi1.73d19f36a420a.database.windows.net'
USE MASTER
CREATE AVAILABILITY GROUP [<DAGName>]
WITH (DISTRIBUTED) 
    AVAILABILITY GROUP ON  
    N'<AGName>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<ManagedInstanceName>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

Vérifier les groupes de disponibilité

Utilisez le script suivant pour lister tous les groupes de disponibilité et groupes de disponibilité distribués sur l’instance de SQL Server. À ce stade, l’état de votre groupe de disponibilité doit être connected, et l’état de vos groupes de disponibilité distribués doit être disconnected. L'état du groupe de disponibilité distribué passe à connected uniquement une fois qu'il est joint à SQL Managed Instance.

-- Run on SQL Server
-- This will show that the availability group and distributed availability group have been created on SQL Server.
SELECT * FROM sys.availability_groups

Vous pouvez également utiliser l’Explorateur d’objets SSMS pour rechercher des groupes de disponibilité et des groupes de disponibilité distribués. Développez le dossier Haute disponibilité AlwaysOn puis le dossier Groupes de disponibilité.

Enfin, vous pouvez créer la liaison. Les commandes diffèrent en fonction de l'instance principale initiale. Utilisez la commande New-AzSqlInstanceLink PowerShell ou Créer la liaison az sql mi Azure CLI pour créer la liaison, comme l'exemple PowerShell dans cette section. La création d'une liaison à partir d'une SQL Managed Instance principale n'est pas actuellement prise en charge par Azure CLI.

Si vous avez besoin d'afficher toutes les liaisons d'une Managed Instance, utilisez la commande Get-AzSqlInstanceLink PowerShell ou Afficher la liaison az sql mi Azure CLI dans Azure Cloud Shell.

Pour simplifier le processus, connectez-vous au portail Azure et exécutez le script suivant à partir d’Azure Cloud Shell. Remplacez :

  • <ManagedInstanceName> par le nom abrégé de votre instance managée.
  • <AGName> par le nom du groupe de disponibilité créé sur SQL Server.
  • <DAGName> par le nom du groupe de disponibilité distribué créé sur SQL Server.
  • <DatabaseName> par la base de données répliquée dans le groupe de disponibilité sur SQL Server.
  • <SQLServerIP> avec l’adresse IP de votre SQL Server. L’adresse IP fournie doit être accessible à une instance gérée.
#  Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO CREATE MANAGED INSTANCE LINK
# Instructs Managed Instance to join distributed availability group on SQL Server
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# Enter the availability group name that was created on SQL Server
$AGName = "<AGName>"

# Enter the distributed availability group name that was created on SQL Server
$DAGName = "<DAGName>"

# Enter the database name that was placed in the availability group for replication
$DatabaseName = "<DatabaseName>"

# Enter the SQL Server IP
$SQLServerIP = "<SQLServerIP>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Build properly formatted connection endpoint
$SourceIP = "TCP://" + $SQLServerIP + ":5022"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PrimaryAvailabilityGroupName $AGName -SecondaryAvailabilityGroupName $ManagedInstanceName |
-TargetDatabase $DatabaseName -SourceEndpoint $SourceIP

Le résultat de cette opération indique la date et l’heure de l’exécution réussie de la demande de création de liaison.

Pour vérifier la connexion entre SQL Managed Instance et SQL Server, exécutez la requête suivante sur SQL Server. La connexion ne sera pas instantanée. La DMV peut prendre jusqu’à une minute pour commencer à montrer une connexion réussie. Continuez à actualiser la DMV jusqu’à ce que la connexion apparaisse comme CONNECTED pour le réplica SQL Managed Instance.

-- Run on SQL Server
SELECT
    r.replica_server_name AS [Replica],
    r.endpoint_url AS [Endpoint],
    rs.connected_state_desc AS [Connected state],
    rs.last_connect_error_description AS [Last connection error],
    rs.last_connect_error_number AS [Last connection error No],
    rs.last_connect_error_timestamp AS [Last error timestamp]
FROM
    sys.dm_hadr_availability_replica_states rs
    JOIN sys.availability_replicas r
    ON rs.replica_id = r.replica_id

Une fois la connexion établie, Explorateur d'objets dans SSMS peut initialement afficher la base de données répliquée sur le réplica secondaire dans un état de Restauration, car la phase d'essaimage initiale déplace et restaure la sauvegarde complète de la base de données. Une fois la base de données restaurée, la réplication doit combler le retard afin que les deux bases de données soient dans un état synchronisé. La base de données n’est plus En cours de restauration une fois l’amorçage initial terminé. Il est possible que l’amorçage de petites bases de données soit suffisamment rapide pour que l’état En cours de restauration initial ne s’affiche pas dans SSMS.

Important

  • La liaison ne fonctionnera pas s’il n’existe pas de connectivité réseau entre SQL Server et SQL Managed Instance. Pour résoudre les problèmes liés à la connectivité réseau, suivez les étapes décrites dans Tester la connectivité réseau.
  • Effectuez des sauvegardes régulières du fichier journal sur SQL Server. Si l’espace de journal utilisé atteint 100 %, la réplication vers SQL Managed Instance s’arrête jusqu’à ce que l’utilisation de l’espace soit réduite. Nous vous recommandons vivement d’automatiser les sauvegardes de journaux en configurant un travail quotidien. Pour plus d’informations, consultez Sauvegarder des fichiers journaux sur SQL Server.

Arrêter la charge de travail

Pour basculer votre base de données sur le réplica secondaire, arrêtez d'abord toute charge de travail sur votre réplica principal pendant les heures de maintenance. Cet arrêt permet à la réplication de la base de données de rattraper le retard sur le réplica secondaire. Vous pouvez également migrer ou basculer vers Azure sans perte de données. Si la base de données primaire fait partie d’un groupe de disponibilité Always On, vous ne pouvez pas la définir en mode lecture seule. Vous devez vous assurer que les applications n'engagent pas de transactions sur le réplica principal avant le basculement.

Changer le mode de réplication

La réplication entre SQL Server et SQL Managed Instance est asynchrone par défaut. Avant de basculer votre base de données vers le réplica secondaire, passez la liaison en mode synchrone. La réplication synchrone sur de grandes distances de réseau peut ralentir les transactions sur le réplica principal.

Le passage du mode asynchrone au mode synchrone demande un changement du mode de réplication à la fois sur SQL Managed Instance et SQL Server.

Changer de mode de réplication (SQL Managed Instance)

Utilisez Azure Powershell ou Azure CLI pour basculer le mode de réplication sur SQL Managed Instance.

Tout d'abord, assurez-vous que vous êtes connecté à Azure et que vous avez sélectionné l'abonnement dans lequel votre Managed Instance est hébergée en utilisant la commande Select-AzSubscription PowerShell ou Définir az account Azure CLI. La sélection de l’abonnement approprié est particulièrement importante si vous avez plusieurs abonnements Azure sur votre compte.

Dans l'exemple PowerShell suivant, remplacez <SubscriptionID> par votre ID d'abonnement Azure.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

Vérifiez que vous connaissez le nom de la liaison vers laquelle vous souhaitez basculer. Vous pouvez utiliser la commande Get-AzSqlInstanceLink PowerShell ou Lister la liaison az sql mi Azure CLI.

Utilisez le script PowerShell suivant pour lister toutes les liaisons actives sur SQL Managed Instance. Remplacez <ManagedInstanceName> par le nom abrégé de votre instance gérée.

# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO LIST ALL LINKS ON MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# List all links on the specified managed instance
Get-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName

À partir de la sortie du script précédent, enregistrez la propriété Name de la liaison que vous voulez basculer.

Ensuite, passez du mode de réplication asynchrone au mode synchrone sur SQL Managed Instance pour la liaison identifiée en utilisant la commande Update-AzSqlInstanceLink PowerShell ou Mettre à jour la liaison az sql mi Azure CLI.

Dans l'exemple PowerShell suivant, remplacez :

  • <ManagedInstanceName> par le nom abrégé de votre instance managée.
  • <DAGName> avec le nom du lien que vous avez trouvé à l’étape précédente (propriété Name de l’étape précédente).
# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO SWITCH LINK REPLICATION MODE (ASYNC\SYNC)
# ===== Enter user variables here ====

# Enter the link name 
$LinkName = "<DAGName>"  

# Enter your managed instance name – for example, "sqlmi1" 
$ManagedInstanceName = "<ManagedInstanceName>" 

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Update replication mode of the specified link
Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName |
-Name $LinkName -ReplicationMode "Sync"

La commande précédente indique la réussite en affichant un récapitulatif de l’opération, avec la propriété ReplicationMode indiquée comme Sync.

Si vous devez annuler cette opération, exécutez le script précédent pour changer le mode de réplication, mais remplacez la chaîne Sync dans -ReplicationMode par Async.

Changer de mode de réplication (SQL Server)

Utilisez le script T-SQL suivant sur SQL Server pour changer le mode de réplication du groupe de disponibilité distribué sur SQL Server 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_COMIT.

-- 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 SQL Managed Instance et SQL Server sont en mode synchrone, la réplication entre les deux instances est synchrone. Si vous devez inverser cet état, suivez les mêmes étapes et définissez l'état sur async pour SQL Server et SQL Managed Instance.

Vérifiez les valeurs LSN sur SQL Server et SQL Managed Instance

Pour terminer le basculement ou la migration, confirmez que la réplication 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. La charge de travail ayant été arrêtée sur le réplica principal, vous devez vous attendre à ce que les LSN correspondent et cessent 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.
  • Le basculement d 'une base de données lors de la maintenance de la liaison avec SQL Server2022 est actuellement en aperçu.

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 une charge de travail en lecture/écriture. Elles sont totalement indépendantes. Renvoyez la chaîne de connexion de votre application à la base de données que vous souhaitez utiliser activement.

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.

Nettoyer les groupes de disponibilité

Le basculement avec SQL Server 2022 ne rompt pas la liaison. Par conséquent, vous pouvez choisir de laisser la liaison et les groupes de disponibilité en place.

Si vous décidez de rompre la liaison, ou si vous procédez à un basculement avec SQL Server 2019 et les versions antérieures, vous devez abandonner le groupe de disponibilité distribué pour supprimer les métadonnées de liaison de SQL Server. Toutefois, vous pouvez choisir de conserver le groupe de disponibilité sur SQL Server.

Pour nettoyer les ressources de votre groupe de disponibilité, remplacez les valeurs suivantes et exécutez ensuite le code d'exemple : dans le code suivant, remplacez :

  • <DAGName> par le nom du groupe de disponibilité distribué sur SQL Server (utilisé pour créer le lien).
  • <AGName> par le nom du groupe de disponibilité sur SQL Server (utilisé pour créer le lien).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> --mandatory
GO
-- DROP AVAILABILITY GROUP <AGName> --optional
-- GO

Résolution des problèmes

La section fournit des conseils pour résoudre les problèmes liés à la configuration et à l'utilisation de la liaison.

Erreurs

En cas de message d'erreur lors de la création de la liaison ou du basculement d'une base de données, consultez le message d'erreur dans la fenêtre de production de la requête pour en savoir plus.

En cas d'erreur lors de l'utilisation de la liaison, la requête s'arrête à l'étape qui a échoué. Une fois le problème lié à l'erreur résolu, exécutez à nouveau la commande pour poursuivre votre action.

État incohérent après le basculement forcé

L'utilisation d'un basculement forcé peut entraîner un état incohérent entre les réplicas principal et secondaire, provoquant un scénario de cerveau divisé du fait que les deux réplicas jouent le même rôle. La réplication des données échoue dans cet état jusqu'à ce que l'utilisateur résolve la situation en désignant manuellement un réplica comme principal et l'autre comme secondaire.

Contenu connexe

Pour plus d’informations sur la fonctionnalité de liaison, consultez les ressources suivantes :