Les meilleures pratiques de connexion pour Managed Instance - Azure SQL Managed Instance

Applies to :Azure SQL Managed Instance

Cet article décrit les meilleures pratiques d’utilisation du lien Managed Instance pour répliquer des données entre Azure SQL Managed Instance et vos instances de SQL Server hébergées n’importe où. Le lien fournit une réplication de données à quasi temps réel entre les répliques liées.

Effectuer régulièrement des sauvegardes des journaux de transaction

Si SQL Server est votre serveur principal initial, effectuez la première sauvegarde du journal sur SQL Server après la fin du seeding initial, lorsque la base de données n’est plus dans l'état Restoring... sur Azure SQL Managed Instance. Prenez ensuite des sauvegardes régulières du journal des transactions SQL Server pour maintenir la taille du fichier journal des transactions à un niveau sain pendant que SQL Server est dans le rôle principal.

La fonctionnalité de liaison réplique les données à l’aide de la technologie des groupes de disponibilité distribués basée sur des groupes de disponibilité Always On. La réplication des données du groupe de disponibilité distribué est basée sur la réplication des enregistrements du journal des transactions. L'instance de SQL Server principale ne peut pas tronquer les enregistrements du journal des transactions de la base de données tant qu'elles ne sont pas répliquées vers la base de données sur le réplica secondaire. Si les problèmes de connexion réseau entraînent la lenteur ou le blocage de la réplication des enregistrements du journal des transactions, le fichier journal continue de croître sur l’instance principale. L’intensité de la charge de travail et la vitesse du réseau déterminent la vitesse de croissance. Si une panne de connexion réseau est prolongée et que la charge de travail sur l’instance principale est importante, le fichier journal peut prendre tout l’espace de stockage disponible.

L’utilisation de sauvegardes régulières du journal des transactions tronque le journal des transactions et réduit le risque d’épuisement de l’espace sur l’instance de SQL Server principale en raison de la croissance du fichier journal. Aucune action supplémentaire n’est nécessaire lorsque SQL Managed Instance est le principal, car les sauvegardes de log sont déjà effectuées automatiquement. En effectuant régulièrement des sauvegardes de journaux sur votre SQL Server principal, vous rendez votre base de données plus résiliente aux événements de croissance des journaux non planifiés. Envisagez de planifier des tâches quotidiennes de sauvegarde des journaux à l’aide d’une tâche SQL Server Agent.

Vous pouvez utiliser un script Transact-SQL (T-SQL) pour sauvegarder le fichier journal, tel que l’exemple fourni dans cette section. Remplacez les espaces réservés dans l’exemple de script par le nom de votre base de données, le nom et le chemin d’accès du fichier de sauvegarde, ainsi que la description.

Pour sauvegarder votre journal des transactions, utilisez l’exemple de script de Transact-SQL (T-SQL) suivant sur SQL Server :

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

Utilisez la commande Transact-SQL (T-SQL) suivante pour vérifier l’espacement du journal utilisé par votre base de données sur SQL Server :

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE);

Le résultat de la requête ressemble à l’exemple suivant pour un exemple de base de données tpcc :

Capture d’écran avec les résultats de la commande montrant la taille de fichier journal et l’espace utilisé

Dans cet exemple, la base de données a utilisé 76 % du journal disponible, avec un fichier journal d’une taille absolue d’environ 27 Go (27 971 Mo). Les seuils d’action peuvent varier en fonction de votre charge de travail. Dans l’exemple précédent, la taille du journal des transactions et le pourcentage d’utilisation du journal indique généralement que vous devez effectuer une sauvegarde du journal des transactions pour tronquer le fichier journal et libérer de l’espace, ou vous devez effectuer des sauvegardes de journal plus fréquentes. Il peut également s'agir d'une indication que la troncation du journal des transactions est bloquée par des transactions ouvertes. Pour plus d’informations sur la résolution des problèmes liés à un journal des transactions dans SQL Server, consultez Troubleshoot a Full Transaction Log (SQL Server Error 9002). Pour plus d’informations sur la résolution des problèmes liés à un journal des transactions dans Azure SQL Managed Instance, consultez Troubleshoot transaction log errors with Azure SQL Managed Instance.

Remarque

Lorsque vous participez à un lien, SQL Managed Instance effectue des sauvegardes complètes et automatisées du journal des transactions, qu'il s'agisse ou non du réplica principal. Les sauvegardes différentielles ne sont pas effectuées. Cela peut entraîner des temps de restauration plus longs.

Harmoniser la capacité de performance entre les réplicas

Lorsque vous utilisez la fonctionnalité de liaison, faites correspondre la capacité de performances entre SQL Server et SQL Managed Instance. Cet alignement vous permet d’éviter les problèmes de performances si le réplica secondaire ne peut pas suivre la réplication à partir du réplica principal ou après le basculement. La capacité de performances inclut les cœurs processeur (ou vCores dans Azure), la mémoire et le débit d’E/S.

Vous pouvez surveiller les performances de la réplication en vérifiant la taille de la file d'attente de redo sur le réplica secondaire. La taille de la file d’attente de réexécution indique le nombre d’enregistrements de journal qui attendent d’être réexécutés sur la réplique secondaire. Une taille de file d’attente de restauration à rétablissement élevée montre que le réplica secondaire ne peut pas suivre le réplica principal. Vous pouvez vérifier la taille de la file d'attente de réexécution de la manière suivante :

Si la taille de la file d'attente de redo est constamment élevée, envisagez d’augmenter les ressources sur la réplique secondaire.

Surveiller le décalage de réplication

La surveillance du décalage de réplication vous aide à déterminer la vitesse à laquelle le réplica secondaire se synchronise avec le réplica principal. Une différence importante indique que le réplica secondaire rencontre des problèmes avec le réplica principal, ce qui est généralement dû à un débit réseau lent dans le lien entre les deux instances, l’allocation de ressources incompatible entre les deux réplicas ou par une charge de travail excessivement élevée sur le réplica principal.

La surveillance du décalage de réplication est particulièrement importante lors de l’exécution d’un basculement planifié, ce qui nécessite que la réplique secondaire soit entièrement synchronisée avec la réplique principale avant que le basculement soit exécuté. Si le décalage de réplication est élevé, le basculement peut prendre plus de temps et, dans certains cas, il peut même échouer.

Utilisez la requête T-SQL suivante sur SQL Server et SQL Managed Instance pour surveiller le décalage de réplication entre les réplicas :

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Effectuer une rotation du certificat

Vous devrez peut-être faire pivoter manuellement le certificat utilisé pour sécuriser le point de terminaison de mise en miroir de bases de données sur SQL Server. Étant donné que le service gère et fait pivoter automatiquement le certificat utilisé pour sécuriser le point de terminaison de mise en miroir de bases de données sur SQL Managed Instance, vous n'avez pas besoin de le faire pivoter manuellement.

SQL Server

Le certificat que vous utilisez pour sécuriser le point de terminaison de mise en miroir de bases de données sur SQL Server peut expirer. Si le certificat expire, il peut entraîner une dégradation des liens. Pour éviter ce problème, faites pivoter le certificat avant son expiration.

Utilisez la commande Transact-SQL (T-SQL) suivante pour vérifier la date d’expiration du certificat actuel :

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

Si votre certificat est sur le point d’expirer ou a déjà expiré, créez un certificat, puis modifiez le point de terminaison existant pour remplacer le certificat actuel.

Après avoir configuré le point de terminaison pour utiliser le nouveau certificat, vous pouvez supprimer le certificat expiré.

SQL Managed Instance

Le certificat de point de terminaison de mise en miroir de bases de données sur SQL Managed Instance est automatiquement renouvelé régulièrement. Vous n'avez pas besoin de surveiller la date d'expiration du certificat de point de terminaison de mise en miroir de bases de données sur SQL Managed Instance, tant que vous pouvez valider la chaîne de certificats sur SQL Server correctement.

Valider la chaîne de certificats sur SQL Server

Remarque

Validez régulièrement la chaîne de certificats pour les liens existants ou pour résoudre les problèmes liés à un lien détérioré. Si vous configurez un nouveau lien ou que vous avez récemment effectué les étapes des sections Getez la clé publique du certificat à partir de SQL Managed Instance et importez-la dans SQL Server et Importez les clés d'autorité de certification racine approuvées Azure à SQL Server, ignorez cette section.

Les problèmes liés à la chaîne de certificats peuvent dégrader le lien. Pour éviter ce problème, validez régulièrement la chaîne de certificats sur SQL Server.

Les scénarios suivants peuvent entraîner des problèmes avec la chaîne de certificats sur SQL Server :

  • Rotation planifiée des certificats sur SQL Managed Instance.
  • Modifications involontaires ou accidentelles apportées aux certificats sur SQL Server, telles que la suppression ou la modification du certificat utilisé pour sécuriser le point de terminaison de mise en miroir de bases de données.

Tout d’abord, déterminez la certificate_id du certificat de point de terminaison MI importé en remplaçant la valeur de <ManagedInstanceFQDN>, puis en exécutant la requête suivante sur SQL Server :

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO

Ensuite, validez le certificat en remplaçant la valeur de <certificate_id> à partir du résultat de la requête précédente, puis en exécutant la requête suivante sur SQL Server :

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO

Une réponse de Commands completed successfully. Completion time: ... indique que le certificat de l'endpoint MI est validé avec succès.

Important

La procédure sp_validate_certificate_ca_chain stockée s’appuie sur les services de système d’exploitation hôte pour effectuer la validation des certificats, ce qui peut impliquer une vérification de révocation de certificats en ligne. Si le système d’exploitation hôte n’est pas configuré pour accéder à Internet, l’exécution échoue même si la chaîne de certificats est valide.

Si vous rencontrez une erreur, la mesure d'atténuation la plus fiable consiste à restaurer la chaîne de certificats en commençant par supprimer tous les certificats créés dans les sections Obtenir la clé publique de certificat de SQL Managed Instance et l'importer dans SQL Server et Importer les clés d'autorité de certification racine approuvées Azure sur SQL Server, puis à les réimporter.

Ajouter des indicateurs de trace de démarrage

Dans SQL Server, il existe deux indicateurs de trace (-T1800 et -T9567) qui, lorsqu’ils sont ajoutés en tant que paramètres de démarrage, peuvent optimiser les performances de la réplication des données via le lien. Pour en savoir plus, consultez Activer les indicateurs de trace de démarrage.

Utiliser la validation synchrone avec précaution

Le mode de validation par défaut pour le lien est asynchrone. Bien qu’il soit possible de changer le mode de validation en mode synchrone, il n’est pas recommandé et n’est pas nécessaire de sécuriser contre la perte de données potentielle.

Pendant un basculement lié planifié, la réplication bascule temporairement vers le mode de validation synchrone jusqu’à ce que le basculement se termine. Après le basculement, le mode de validation revient à asynchrone, même s’il est explicitement défini sur le mode de validation synchrone avant le basculement.

L’utilisation du mode de validation synchrone pour le lien peut avoir un impact sur les performances de la réplique principale, en particulier s’il existe une latence réseau élevée entre les répliques. En mode de validation synchrone, les transactions sur le réplica principal doivent attendre la confirmation que les enregistrements du journal des transactions sont renforcés sur le réplica secondaire avant que la transaction puisse être validée sur le réplica principal. Ce temps d’attente augmente avec une latence réseau plus élevée, ce qui peut entraîner une augmentation des temps de réponse des transactions et un débit réduit sur le réplica principal.

Contenu connexe

Pour utiliser le lien :

Pour en savoir plus sur la liaison :

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

  • Last updated on