Configurer un lien avec des scripts - Azure SQL Managed Instance

Applies to :Azure SQL Managed Instance

Cet article explique comment configurer un link entre SQL Server et Azure SQL Managed Instance avec des scripts Transact-SQL et PowerShell ou 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 connexion créée, vous pouvez passer à votre réplica secondaire pour migration ou récupération d'urgence.

Vue d’ensemble

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

Vous pouvez choisir de laisser le lien en place pour la réplication continue des données dans un environnement hybride entre le réplica principal et le réplica secondaire, ou basculer la base de données vers le réplica secondaire, pour migrer vers Azure ou pour la récupération d’urgence. Pour SQL Server 2019 et versions antérieures, le basculement vers Azure SQL Managed Instance interrompt le lien et la restauration automatique n’est pas prise en charge. Avec SQL Server 2022, vous avez la possibilité de maintenir le lien et d'échouer d'un côté à l'autre entre les deux réplicas.

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.

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

Prérequis

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

• Un abonnement actif Azure. Si vous n’en avez pas, créez un compte gratuit.
• Version prise en charge de SQL Server avec la mise à jour de service requise installée.
• Azure SQL Managed Instance. Commencez si vous ne l'avez pas déjà.
• Module PowerShell Az.SQL 6.0.0 ou version ultérieure ou Azure CLI 2.67.0 ou version ultérieure. Ou de préférence, utilisez Azure Cloud Shell en ligne à partir du navigateur web pour exécuter les commandes, car elle est toujours mise à jour avec les dernières versions du module.
• Un environnement correctement préparé.

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 vers SQL Managed Instance, créez 10 liens individuels.
• La collation entre SQL Server et SQL Managed Instance doit être le même. Une incompatibilité dans le classement peut entraîner une incompatibilité dans la casse de nom de serveur et empêcher une connexion réussie de SQL Server à SQL Managed Instance.
• L’erreur 1475 sur votre principal de SQL Server 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.
• Pour établir un lien, ou basculer, de l'instance SQL gérée vers SQL Server 2025, votre instance SQL gérée doit être configurée avec la stratégie de mise à jour SQL Server 2025. La réplication et le basculement des données depuis SQL Managed Instance vers SQL Server 2025 ne sont pas pris en charge par les instances configurées avec une stratégie de mise à jour incompatible.
• Pour établir un lien ou effectuer une bascule de l'instance SQL Managed à SQL Server 2022, votre instance SQL Managed doit être configurée avec la stratégie de mise à jour SQL Server 2022. La réplication et le basculement des données from SQL Managed Instance vers SQL Server 2022 ne sont pas pris en charge par les instances configurées avec une stratégie de mise à jour incompatible.
• Bien que vous puissiez établir un lien à partir d’une version prise en charge de SQL Server à un SQL managed instance configuré avec la Always -up-to-date stratégie de mise à jour, après le basculement vers SQL Managed Instance, vous ne pourrez plus répliquer les données ou effectuer une restauration automatique vers votre instance de SQL Server.

autorisations

Pour SQL Server, vous devez disposer d’autorisations sysadmin.

Pour Azure SQL Managed Instance, vous devez être membre du SQL Managed Instance Contributeur ou disposer des autorisations de rôle personnalisées suivantes :

Terminologie et conventions d’affectation de noms

Lorsque vous exécutez des scripts à partir de ce guide utilisateur, il est important de ne pas confondre les noms de SQL Server et SQL Managed Instance avec leurs noms de domaine complets (FQDN). Le tableau suivant explique ce que les différents noms représentent exactement, et comment obtenir leurs valeurs :

¹ La configuration de Azure SQL Managed Instance en tant que principal initial est prise en charge à partir de SQL Server 2022 CU10.

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

Si SQL Server est votre principal initial, les bases de données qui seront répliquées via le lien doivent se trouver dans le modèle de récupération complète et avoir au moins une sauvegarde. Étant donné que Azure SQL Managed Instance effectue automatiquement des sauvegardes, ignorez cette étape si SQL Managed Instance est votre principal initial.

Lorsque vous créez un lien, l’amorçage initial entre le réplica principal et le réplica secondaire se fait en effectuant une sauvegarde complète de la base de données sur le réplica principal, puis en la transférant et en la restaurant sur le réplica secondaire. Lorsque vous effectuez la sauvegarde complète, nous vous recommandons d’utiliser l’option WITH CHECKSUM pour vous assurer que la sauvegarde est valide et n’a aucune altération. Pour plus d’informations, consultez BACKUP (Transact-SQL).

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.

Établir la confiance entre les 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é.

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

Voici une vue d’ensemble du processus de sécurisation des points de terminaison de mise en miroir de bases de données pour les SQL Server et les SQL Managed Instance :

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

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

Créez un certificat sur SQL Server et importez sa clé publique dans 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.

-- 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.

Tout d'abord, vérifiez que vous êtes connecté à Azure et que vous avez sélectionné l'abonnement dans lequel votre instance managée est hébergée. La sélection de l’abonnement approprié est particulièrement importante si vous avez plusieurs Azure abonnement sur votre compte.

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

Utilisez ensuite la commande New-AzSqlInstanceServerTrustCertificate PowerShell ou az sql mi partner-cert create 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> avec 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> avec 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ésumé du certificat de SQL Server chargé sur Azure.

Si vous devez voir tous les certificats SQL Server chargés sur une instance managée, utilisez la commande Get-AzSqlInstanceServerTrustCertificate PowerShell ou az sql mi partner-cert list Azure CLI dans Azure Cloud Shell. Pour supprimer SQL Server certificat chargé sur une instance managée SQL, utilisez la commande Remove-AzSqlInstanceServerTrustCertificate PowerShell ou az sql mi partner-cert delete Azure CLI dans Azure Cloud Shell.

Obtenez la clé publique du certificat à partir de SQL Managed Instance et importez-la dans SQL Server

Le certificat permettant de sécuriser le point de terminaison de liaison est généré automatiquement sur Azure SQL Managed Instance. Récupérez la clé publique du certificat à partir de SQL Managed Instance et importez-la dans SQL Server à l’aide de la commande Get-AzSqlInstanceEndpointCertificate PowerShell ou az sql mi endpoint-cert show Azure CLI, comme l’exemple PowerShell suivant.

Exécutez le script suivant. Remplacez :

• <SubscriptionID> avec 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 pour créer le certificat de point de terminaison MI. Remplacez :

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

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

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

L’importation de clés d’autorité de certification racine approuvées Azure dans SQL Server est requise pour que votre SQL Server approuve les certificats de clé publique SQL Managed Instance émis par Azure.

Vous pouvez télécharger les clés nécessaires de l’autorité de certification racine à partir des détails de l'autorité de certification Azure. Au minimum, téléchargez les certificats DigiCert Global Root G2 et Microsoft RSA Root Certificate Authority 2017 et importez-les dans votre instance de SQL Server. Toutefois, si vous envisagez d’exécuter le lien pendant plus de quelques mois, téléchargez et importez tous les 7 certificats répertoriés dans la section Root Certificate Authorities pour éviter les interruptions potentielles au cas où Azure met à jour sa liste d’autorité de certification approuvée.

Enregistrez les certificats locaux dans l’instance SQL Server, par exemple dans l’exemple C:\Path\To\<name of certificate>.crt chemin d’accès, puis importez les certificats à partir de ce chemin à l’aide du script Transact-SQL suivant. Remplacez <name of certificate> par le nom de certificat réel, tel que DigiCert Global Root G2 ou Microsoft RSA Root Certificate Authority 2017.

-- Run on SQL Server
-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'<name of certificate>')
BEGIN
    PRINT 'Creating <name of certificate> certificate.'
    CREATE CERTIFICATE [<name of certificate>] FROM FILE = 'C:\Path\To\<name of certificate>.crt'

    --Trust certificates issued by <name of certificate> root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('<name of certificate>')
    --For government cloud, use the corresponding SQL Database DNS suffix, e.g. '*.database.usgovcloudapi.net', '*.database.chinacloudapi.cn' etc.
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate <name of certificate> already exists.'
GO

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

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

Valider la chaîne de certificats

Les modifications planifiées ou involontaires apportées aux certificats peuvent dégrader le lien. Pour éviter les interruptions, il est important de valider régulièrement la chaîne de certificats sur SQL Server.

Ignorez cette étape si vous configurez un nouveau lien ou avez récemment importé les certificats, comme décrit dans les sections précédentes.

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

Si vous n'avez pas de groupe de disponibilité existant ou un point de terminaison de mise en miroir de bases de données sur SQL Server, l'étape suivante consiste à créer un point de terminaison de mise en miroir de bases de données sur SQL Server et à le sécuriser avec le 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 un point de terminaison pour la mise en miroir de base de données déjà créé, 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 n'affiche pas de point de terminaison de mise en miroir de bases de données existante, 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 point de terminaison de mise en miroir de bases de données sur le port <EndpointPort> et sécuriser le point de terminaison avec le certificat SQL Server. Remplacez :

• <SQL_SERVER_CERTIFICATE> avec 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=<EndpointPort>, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

Vérifiez 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

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_algorithm_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é pour les groupes de disponibilité et 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 Authentification Windows pour un groupe de disponibilité existant, il est possible de modifier le point de terminaison pour utiliser plusieurs méthodes d'authentification en basculant l'option d'authentification vers NEGOTIATE CERTIFICATE. Cette modification permet au groupe de disponibilité existant d’utiliser 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 montre comment modifier votre point de terminaison de mise en miroir de bases de données existant sur SQL Server. Remplacez :

• <YourExistingEndpointName> avec le nom de votre point de terminaison existant.
• <SQLServerCertName> avec 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=<EndpointPort>, 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 le certificat, utilisez cette requête à nouveau 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 un lien SQL Managed Instance.

Créer un groupe de disponibilité sur SQL Server

Si vous n'avez pas de groupe de disponibilité existant, l'étape suivante consiste à en créer une sur SQL Server, quel que soit le principal initial.

Les commandes permettant de créer le groupe de disponibilité sont différentes si votre SQL Managed Instance est le principal initial, qui est uniquement pris en charge à 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 liens pour la même base de données, utilisez le même groupe de disponibilité pour tous les liens, mais créez un nouveau groupe de disponibilité distribué pour chaque liaison de base de données entre SQL Server et SQL Managed Instance.

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

-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGNameOnSQLServer>]
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>:<EndpointPort>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

-- 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'<AGNameOnSQLServer>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:<EndpointPort>',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<AGNameOnSQLMI>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

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

-- Run on SQL Server 
-- Create the availability group on SQL Server 

CREATE AVAILABILITY GROUP [<AGNameOnSQLServer>] 
WITH (CLUSTER_TYPE = NONE) 
FOR  
REPLICA ON N'<SQLServerName>' 
WITH ( 
    ENDPOINT_URL = N'TCP://<SQLServerIP>:<EndpointPort>', 
    FAILOVER_MODE = MANUAL, 
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
    SEEDING_MODE = AUTOMATIC); 

GO 

-- Run on SQL Server 
-- Grant permission to the availability group to create databases 

ALTER AVAILABILITY GROUP [<AGNameOnSQLServer>] GRANT CREATE ANY DATABASE; 

-- 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'<AGNameOnSQLServer>' WITH  
    ( 
      LISTENER_URL = 'TCP://<SQLServerIP>:<EndpointPort>', 
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, 
      FAILOVER_MODE = MANUAL, 
      SEEDING_MODE = AUTOMATIC, 
      SESSION_TIMEOUT = 20 
    ), 
    N'<AGNameOnSQLMI>' WITH 
    ( 
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>];Database=[<DatabaseName>]', 
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, 
      FAILOVER_MODE = MANUAL, 
      SEEDING_MODE = AUTOMATIC 
    ); 
GO 

Vérifier les groupes de disponibilité

Utilisez le script suivant pour répertorier tous les groupes de disponibilité et les groupes de disponibilité distribués sur l’instance 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 une seule 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 SSMS Explorateur d'objets 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é.

Créer un lien

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 az sql mi link create Azure CLI pour créer le lien, comme l’exemple PowerShell dans cette section. La création du lien à partir d'un SQL Managed Instance principal n'est actuellement pas prise en charge avec le Azure CLI.

Si vous avez besoin de voir tous les liens sur une instance managée, utilisez la commande Get-AzSqlInstanceLink PowerShell ou az sql mi link show Azure CLI dans Azure Cloud Shell.

#  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
$AGNameOnSQLServer = "<AGNameOnSQLServer>"

# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# 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 + ":<EndpointPort>"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI |
-Database @($DatabaseName) -PartnerEndpoint $SourceIP -InstanceLinkRole Secondary

#  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
$AGNameOnSQLServer = "<AGNameOnSQLServer>"

# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# 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>" 

# Enter the Azure subscription ID 
$SubscriptionID = "<SubscriptionID>" 
 
# ==== Do not customize the following cmdlet ==== 

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

# Build properly formatted connection endpoint 
$DestinationIP = "TCP://" + $SQLServerIP + ":<EndpointPort>"  

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI |
-Database @($DatabaseName) -PartnerEndpoint $DestinationIP -InstanceLinkRole Primary

Le résultat de cette opération est un horodatage de l’exécution réussie de la demande de création de liaison.

Vérifier la 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. Actualisez continuellement la vue dynamique jusqu'à ce que la connexion apparaisse comme CONNECTÉE pour le réplica de l’instance gérée SQL.

-- 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 Restoring à mesure que la phase d’amorçage 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.

Effectuez la première sauvegarde du journal des transactions

Si SQL Server est votre principal initial, il est important de prendre la première sauvegarde du journal de transaction sur SQL Server après que l'amorçage initial soit terminé, lorsque la base de données n'est plus dans l'état Restoring... sur Azure SQL Managed Instance. Prenez ensuite sauvegardes du journal des transactions de SQL Server régulièrement pour réduire la croissance excessive du journal, lorsque SQL Server remplit le rôle principal.

Si SQL Managed Instance est votre principal, vous n'avez pas besoin d'effectuer d'action, car Azure SQL Managed Instance effectue automatiquement des sauvegardes de journaux.

Supprimer une liaison

Si vous souhaitez supprimer la liaison, soit parce qu’elle n’est plus nécessaire, soit parce qu’elle est dans un état irréparable et doit être recréée, vous pouvez le faire avec PowerShell et T-SQL.

Tout d’abord, utilisez la commande PowerShell Remove-AzSqlInstanceLink pour supprimer la liaison, comme dans l’exemple suivant :

Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $managedInstanceName -Name $DAGName -Force 

Exécutez ensuite le script T-SQL suivant sur SQL Server pour supprimer le groupe de disponibilité distribué. Remplacez <DAGName> par le nom du groupe de disponibilité distribué utilisé pour créer la liaison :

USE MASTER 
GO 

DROP AVAILABILITY GROUP <DAGName>  
GO 

Enfin, si vous le souhaitez, vous pouvez supprimer le groupe de disponibilité si vous n’en avez plus l’utilité. Pour ce faire, remplacez le <AGName> par le nom du groupe de disponibilité, puis exécutez-le sur l’instance respective :

DROP AVAILABILITY GROUP <AGName>  
GO 

Résolution des problèmes

En cas de message d’erreur lors de la création de la liaison, consultez le message d’erreur dans la fenêtre sortie de la requête pour en savoir plus. Pour plus d’informations, consultez pour résoudre les problèmes concernant le lien.

Contenu connexe

Pour utiliser le lien :

• Préparer l'environnement pour le lien Managed Instance
• Configurer la liaison entre SQL Server et l'Instance SQL managée avec SSMS
• Basculez le lien
• Migrer avec le lien
• Meilleures pratiques pour préserver la liaison
• résoudre les problèmes liés au lien

Pour en savoir plus sur le lien :

• vue d’ensemble du lien Managed Instance
• Reprise après sinistre avec lien vers Managed Instance

Pour d’autres scénarios de réplication et de migration, considérez :

• Réplication transactionnelle avec SQL Managed Instance
• Service de Relecture de Journaux (LRS)