Réplication transactionnelle SQL Server est l'une des techniques de réplication les plus couramment utilisées pour copier ou distribuer des données sur plusieurs destinations. Dans l'article précédent, nous avons discuté de la réplication SQL Server, des types de réplication et des éléments internes de base sur le fonctionnement de la réplication transactionnelle. Maintenant, nous allons nous plonger dans les détails internes avancés du fonctionnement de la réplication transactionnelle de SQL Server.
Architecture de réplication transactionnelle
Avant de commencer, je vous recommande de rafraîchir vos connaissances avec mon précédent article ici.
Commençons par examiner l'architecture de réplication transactionnelle SQL Server présentée ci-dessous à partir de la documentation Microsoft.
Dans la base de données des éditeurs , créer une Publication comprenant la liste des articles (Tableaux , Vues , etc.) que vous devez répliquer sur l'Abonné base de données. Une fois les articles activés pour la réplication, toutes les modifications apportées à ces articles seront marquées pour la réplication dans la base de données Transactional Logs of Publisher.
La réplication transactionnelle SQL Server peut être initialisée à partir de l'éditeur au distributeur puis à l'Abonné base de données via Snapshot Agent ou Complet Sauvegardes . L'Agent d'instantané peut effectuer l'Initialisation via l'Assistant de configuration de la réplication . La sauvegarde complète est prise en charge uniquement via les instructions T-SQL.
L'Agent de lecture du journal analyse le journal des transactions de la base de données de l'éditeur pour détecter les modifications suivies marquées pour la réplication. Il ignore les autres modifications capturées dans les journaux transactionnels et copie les modifications de données du journal transactionnel vers la base de données de distribution.
La base de données de distribution peut se trouver dans Publisher ou Subscriber, ou dans une autre instance SQL Server indépendante. Notez les éléments suivants :
- L'agent de lecture du journal s'exécute en continu à partir du serveur de distribution pour rechercher de nouvelles commandes marquées pour la réplication. Toutefois, si vous ne souhaitez pas exécuter en continu et que vous souhaitez plutôt exécuter une planification, nous pouvons modifier la tâche SQL de l'agent de lecture du journal qui sera créée.
- L'agent de lecture du journal récupère tous les enregistrements marqués pour la réplication à partir du journal transactionnel par lots et les envoie à la base de données de distribution.
- L'agent de lecture du journal récupère uniquement les transactions validées dans le journal des transactions de la base de données de l'éditeur. Ainsi, toute requête de longue durée sur la base de données de l'éditeur peut avoir un impact direct sur la réplication car elle attend la fin de la transaction active.
L'agent de distribution récupère toutes les nouvelles commandes non distribuées de la base de données de distribution et les applique à la base de données d'abonnement via Push ou Tirer Mécanisme .
- Poussez l'abonnement – le Distributeur se charge d'appliquer les modifications de la base de données de distribution à l'abonné.
- Abonnement pull – l'Abonné la base de données prend en charge la récupération des modifications de la base de données de distribution vers l'abonné.
Une fois que les enregistrements sont distribués avec succès de la distribution à la base de données des abonnés, ils seront marqués comme Distribué et également marqué pour suppression de la base de données de distribution .
L'un des travaux de maintenance de la réplication clé est le nettoyage de la distribution :La tâche de distribution s'exécute toutes les 10 minutes pour supprimer les enregistrements distribués de la base de données de distribution afin de maintenir la taille de la base de données de distribution sous contrôle.
Par conséquent, notre objectif pour cet article est d'explorer les sujets suivants :
- Base de données de distribution
- Agents de réplication
- Agent d'instantané
- Agent de lecture du journal
- Agent de distribution
- Profils des agents de réplication
- Tâches de maintenance de réplication
- Latence de réplication et jetons traceurs
- Utilitaire TableDiff
- Alertes de l'agent SQL Server
Base de données de distribution SQL Server
Une base de données de distribution est une base de données système créée lors de la configuration de la réplication. C'est le cœur de la réplication puisque la plupart du processus s'exécute à partir d'une base de données de distribution.
En raison de la nature de la base de données de distribution, nous ne pouvons effectuer que des opérations limitées sur celle-ci, telles que la sauvegarde et la restauration. Nous ne pouvons pas le supprimer directement comme les bases de données utilisateur.
Pour une énorme base de données avec beaucoup de données répliquées, nous devons prendre quelques mesures spéciales pour améliorer les performances de débit de réplication :
Par défaut, la base de données de distribution est créée sur le chemin d'installation par défaut configuré dans SQL Server . S'il n'est pas configuré, il sera créé sur le C : lecteur ou dans les dossiers d'installation de SQL Server. Nous vous recommandons de déplacer la base de données de distribution vers un stockage/disque plus rapide pour améliorer les performances.
La taille initiale du fichier et Croissance automatique de la base de données de distribution sera défini en fonction des paramètres de taille de fichier initiale et de croissance automatique de la base de données modèle. Configurez la taille du fichier initial sur une meilleure valeur comme 10 Go en cas de réplication de base de données occupée de manière transactionnelle. Les propriétés Autogrowth doivent atteindre 512 Mo ou 1 Go pour les fichiers de données et les fichiers journaux. Ensuite, il n'y aura pas beaucoup de fragmentation dans les fichiers de données et journaux.
Configurer le Quotidien ou tâches de sauvegarde de routine pour inclure la base de données de distribution à des fins de référence ou de dépannage en cas de corruption ou de perte de données.
Configurer la réorganisation quotidienne de l'index ou Maintenance emplois pour inclure la base de données de distribution. La base de données implique d'énormes insertions de données dans le MSrepl_transactions et MSrepl_commands tableaux.
Remarque :L'interrogation continue de ces 2 tables et leur suppression après l'envoi réussi de données à la base de données de l'Abonné augmentent le risque de fragmentation. La reconstruction de ces tables sur une base planifiée peut améliorer les performances de la base de données de distribution.
Pour afficher et modifier l'un des attributs de la base de données de distribution liés à la réplication, cliquez avec le bouton droit sur Réplication > Propriétés du distributeur :
Cliquez sur les points de suspension sur la droite pour afficher plus de détails sur les options individuelles répertoriées.
Faites attention, la modification des paramètres peut avoir un impact sur les performances de la base de données de distribution. Par conséquent, n'implémentez les modifications qu'après avoir soigneusement évalué tous les paramètres que vous souhaitez modifier.
Conservation des transactions spécifie la quantité de données à conserver dans la base de données de distribution. Les valeurs minimales et maximales peuvent être spécifiées en heures ou en jours.
La valeur Transaction Retention définie sur 0 heures indique qu'une fois les enregistrements correctement répliqués dans la base de données de l'Abonné, ils peuvent être supprimés de la base de données de distribution. Si vous augmentez cette valeur, la taille de la base de données de distribution augmentera. Ainsi, nous devons le planifier en conséquence.
Conservation de l'historique spécifie la période de conservation pour stocker les données de l'historique des performances de la réplication transactionnelle. Par défaut, c'est 48 heures.
Pour supprimer une base de données de distribution , nous devons Désactiver la publication associé à cette base de données de distribution particulière, puis supprimez-le en utilisant l'une des deux méthodes. L'un est une combinaison de Désactiver la publication et de l'assistant Distribution. Un autre utilise sp_dropdistributor ou sp_dropdistributiondb procédures. L'assistant utilise en interne ces 2 procédures pour désactiver la distribution et supprimer la base de données de distribution.
Agents de réplication SQL Server
Agents de réplication sont des programmes autonomes responsables du suivi des modifications de données de l'éditeur et de la propagation de ces modifications aux bases de données des distributeurs et des abonnés. Ils sont exécutés en tant que travaux de l'Agent SQL Server.
Voyons d'abord l'emplacement de ces programmes autonomes.
Pour configurer la réplication, nous avons besoin des composants de réplication installé via le programme d'installation de SQL Server. Une fois terminé, nous pouvons voir les programmes autonomes liés à l'agent de réplication disponibles dans le chemin d'installation :
C:\Program Files\Microsoft SQL Server\130\COM
Dans mon cas, la version de la version de SQL Server est 2016. Par conséquent, elle est inférieure à 130 dans le chemin.
Pour chaque agent de réplication, nous pouvons voir le programme autonome respectif disponible :
- DISTRIB.exe – Agent de distribution
- Logread.exe – Agent de lecture du journal
- Qrdrsvc.exe – Agent de service de lecteur de file d'attente
- Replmerg.exe – Agent de réplication de fusion
- Snapshot.exe – Agent d'instantané
- Tablediff.exe – Utilitaire de comparaison de tableaux. Nous pourrons entrer dans plus de détails plus loin dans cet article.
Maintenant que nous savons de quoi ces programmes autonomes sont responsables et où ils se trouvent, nous pouvons comprendre comment ils sont exécutés via les travaux de l'Agent SQL Server.
Étant donné que nous traitons de la réplication transactionnelle SQL Server, nous allons parcourir les tâches de l'agent d'instantané, de l'agent de lecture du journal et de l'agent de distribution (la même logique s'applique à tous les autres agents).
Agent d'instantané
L'Agent d'instantané s'exécute à partir du serveur contenant la base de données de distribution. Il prépare le schéma et les données initiales de tous les articles inclus dans une publication sur un éditeur, crée les fichiers d'instantanés dans le dossier d'instantanés et enregistre les détails de synchronisation dans la base de données de distribution.
Depuis la distribution MSSnapshot_agents table, nous pouvons identifier le travail de l'Agent SQL Server qui effectue les activités de l'Agent de capture instantanée. Chaque publication implique un travail dédié de l'Agent SQL Server qui doit prendre en charge les responsabilités de l'Agent d'instantané.
Développez Agent SQL Server et ouvrez le nom du travail mentionné ci-dessus. Il affichera les détails et la Catégorie nom – REPL-Instantané
Cliquez sur l'Étape pour voir les activités effectuées par l'agent Snapshot.
Cliquez sur une étape individuelle pour afficher les informations sur le travail de l'agent d'instantané.
Étape 1 enregistre une entrée dans la table d'historique à chaque démarrage de l'agent Snapshot en utilisant sp_MSadd_snapshot_history procédure.
La table qui contient l'historique des détails exécutés par l'agent Snapshot est le MSsnapshot_history table dans la base de données de distribution.
Il correspondra à Afficher le statut de l'agent d'instantané fenêtre de dialogue.
Passez à l'étape 2 – Exécuter l'agent . Il va démarrer le travail de l'Agent d'instantané .
Sous le Commandement , nous n'avons trouvé aucune instruction ou requête T-SQL. Il n'y avait que quelques paramètres répertoriés. Ainsi, la réponse se trouve dans la section en surbrillance sur l'illustration ci-dessus. Cela montre que le type d'étape de tâche est Instantané de réplication qui lance le programme autonome snapshot.exe pour assumer les responsabilités de l'agent d'instantané.
Pour plus de détails sur snapshot.exe, reportez-vous à cet article MSDN. Nous entrerons également dans les détails lors du dépannage des problèmes liés à la réplication ultérieurement.
Enfin, nous allons passer à l'étape 3 – la dernière étape du travail. Il capture tous les arrêts inattendus des tâches d'agent et les déconnecte.
Agent de lecture du journal
Chaque fois que la publication est configurée sur une base de données, toutes les modifications apportées à ces articles sont marquées pour réplication dans le journal des transactions. L'agent de lecture du journal lit ces modifications de données via logread.exe et les stocke dans la base de données de distribution via 2 processus distincts :
- Lire les journaux transactionnels – il utilise le sp_replcmds procédure stockée étendue pour analyser les modifications de données à partir de l'éditeur. Étant donné que cette procédure stockée fait référence aux fichiers DLL, les informations internes sur la manière exacte dont Microsoft lit les fichiers journaux ne sont pas identifiées. Cependant, nous pouvons essayer des fonctions non documentées comme fn_dblog() et fn_dump_dblog() pour comprendre le fonctionnement du fichier journal des transactions.
- Écrire dans la base de données de distribution – il utilise le sp_MSadd_replcmds procédure stockée dans la base de données de distribution pour écrire les données binaires lues à partir des journaux transactionnels de la base de données de l'éditeur. Il écrit les détails de la transaction dans MSrepl_transactions table et commandes individuelles aux MSrepl_commands tableau.
Un seul travail Log Reader SQL Server Agent est disponible pour chaque base de données publiée. Vous pouvez identifier son nom comme indiqué ci-dessous :
Développez l'Agent SQL Server et ouvrez le travail de l'Agent de lecture du journal ci-dessus pour afficher les étapes. Il affichera le travail Сategory sous Lecteur de journal de réplication.
Cliquez sur Étapes pour voir les étapes individuelles effectuées par l'Agent de lecture du journal. Comme pour le travail de l'Agent d'instantané, nous pouvons voir 3 étapes équivalentes pour le travail de l'Agent de lecture du journal.
Étape 1 appelle le sp_MSadd_logreader_history procédure pour consigner les messages d'historique d'état de démarrage de l'agent de lecture du journal dans MSlogreader_history tableau.
Étape 2 démarre le processus de l'agent de lecture du journal à l'aide du programme autonome logread.exe .
Vous pouvez trouver plus de détails sur logread.exe dans l'article MSDN correspondant. Plus tard, nous examinerons également les paramètres de configuration critiques de l'agent de lecture du journal.
Étape 3 capture un arrêt brutal du travail de l'Agent de lecture du journal.
Agent de diffusion
L'agent de distribution (DISTRIB.exe) a été utilisé par la réplication transactionnelle et d'instantané pour appliquer les fichiers d'instantané initiaux et incrémentielle ou appliquer les transactions en attente disponibles de la base de données de distribution à la base de données de l'abonné.
Cet agent s'exécute à partir du serveur de distribution pour les abonnements push et du serveur d'abonnés pour les abonnements pull. Pour trouver le nom du travail de l'Agent SQL Server qui exécute les responsabilités de l'agent de distribution, nous pouvons exécuter la requête spécifique comme indiqué ci-dessous :
Développez le travail de l'Agent SQL Server et ouvrez-le pour afficher plus d'informations et la catégorie attribuée à la distribution de réplication.
Cliquez sur Étapes – vous verrez les étapes similaires aux étapes précédemment exposées des travaux Snapshot et Log Reader Agent.
Étape 1 appelle le sp_MSadd_distribution_history procédure pour consigner les messages d'historique d'état de démarrage de l'agent de lecture du journal dans MSdistribution_history tableau.
Étape 2 démarre le processus de l'agent de distribution (DISTRIB.exe) avec les paramètres par défaut.
Pour plus de détails sur DISTRIB.exe, consultez l'article MSDN. De plus, nous passerons en revue les paramètres de configuration critiques de l'agent de distribution dans les prochains articles.
Étape 3 capture des détails sur l'arrêt brutal du travail de l'Agent de distribution.
Profils des agents de réplication
À partir des propriétés du distributeur , nous pouvons avoir la possibilité d'afficher les Profils des agents de réplication . Laissez les profils d'agent aux valeurs par défaut et modifiez-les uniquement si nécessaire à des fins de dépannage.
Cliquez sur Paramètres par défaut du profil pour afficher les valeurs par défaut configurées pour tous les agents de réplication disponibles sur le serveur.
Sélectionnez les agents de distribution section et cliquez sur les points de suspension bouton à côté du profil d'agent par défaut pour voir les valeurs configurées. Voir l'illustration ci-dessous :
Afficher le profil d'agent par défaut des Agents Snapshot Agent lecteur :
Profil d'agent par défaut pour le lecteur de journal Agent :
Tâches de maintenance de réplication
Outre les agents de réplication, nous avons des tâches de maintenance de réplication .
Il s'agit de travaux de l'Agent SQL Server créés lors de la configuration de la réplication transactionnelle SQL Server. Ils sont disponibles pour s'assurer du bon fonctionnement de la Réplication Transactionnelle.
Certaines tâches de maintenance de la réplication sont essentielles pour la réplication transactionnelle. Passons-les en revue.
- Nettoyage de la distribution : Répartition – exécute le sp_MSdistribution_cleanup procédure pour supprimer les commandes de réplication de MSrepl_transactions et MSrepl_commands les tables. Le nettoyage se produit sur la base de données de distribution une fois que les commandes ont été envoyées avec succès à la base de données de l'abonné en fonction de la valeur de la période de rétention des transactions configurée dans la base de données de distribution. Par défaut, ce travail s'exécute toutes les 10 minutes sur la base de données de distribution. Ne modifiez ces valeurs qu'après une évaluation approfondie.
- Agent Nettoyage de l'historique :Distribution – exécute le sp_MShistory_cleanup procédure dans la base de données de distribution pour nettoyer les enregistrements historiques antérieurs à la période de rétention d'historique configurée dans cette base de données. Par défaut, il est configuré pour 48 jours et exécuté toutes les 10 minutes. Si vous souhaitez modifier ces valeurs, examinez attentivement tous les aspects.
- Expiré Nettoyage des abonnements – exécute le sp_expired_subscription_cleanup procédure dans la base de données master pour supprimer les abonnements qui ont expiré ou qui sont restés inactifs pendant une longue période. Par défaut, cette procédure s'exécute une fois par jour.
Latence de réplication et jetons traceurs
Latence de réplication est le temps requis par le processus de réplication pour suivre les modifications apportées aux articles publiés à partir de la base de données de l'éditeur jusqu'à ce qu'ils soient livrés avec succès à l'abonné via le distributeur.
La latence de réplication est mesurée en millisecondes. La valeur cible de 0 (réplication en temps réel) à une valeur très faible (cas idéaux). C'est l'une des mesures clés pour surveiller les performances de réplication.
Nous pouvons vérifier la latence de réplication à l'aide du moniteur de réplication ou des sp_replcounters dédiés procédure.
Depuis le moniteur de réplication a le rafraîchissement taux, il peut y avoir de légers écarts par rapport aux valeurs observées. Pour surmonter les légers écarts lors du calcul de la latence de réplication, les Tracer Tokens viennent à notre secours.
Cliquez sur les jetons traceurs (voir l'image ci-dessus) pour envoyer un nouvel ensemble de commandes de test depuis l'éditeur. Ensuite, mesurez-le lorsqu'il atteint la base de données du distributeur et lorsqu'il a été envoyé à la base de données de l'abonné. Cliquez sur Insérer un traceur pour envoyer des jetons traceurs depuis la base de données de l'éditeur :
Une fois les enregistrements reçus avec succès dans l'abonné, nous pouvons suivre la latence totale de réplication pour notre configuration actuelle. Dans notre cas, il s'agit de 9 secondes :4 secondes de l'éditeur au distributeur et 5 secondes du distributeur à l'abonné.
Utilitaire Tablediff
Utilitaire Tablediff(tablediff.exe) sera installé dans le chemin C:\Program Files\Microsoft SQL Server\130\COM une fois les composants de réplication installés.
L'utilitaire TableDiff compare 2 tables pour la non-convergence. Cela signifie que nous pouvons comparer 2 tableaux et identifier les différences entre eux. Puis il synchronise la table Destination par rapport à la table Source en générant des scripts INSERT/UPDATE/DELETE dédiés. Plus de détails sont disponibles dans la documentation officielle.
Étant donné que la réplication transactionnelle SQL Server ne se soucie pas des modifications manuelles sur la base de données de l'abonné, cet utilitaire peut aider à synchroniser ces types de tables selon les besoins. Cependant, il n'a pas d'assistant ou d'interface utilisateur - vous ne pouvez y accéder que via l'invite de commande ou à partir de fichiers batch.
D'autres outils peuvent simplifier la comparaison et la synchronisation. Le dbForge Compare Bundle pour SQL Server vérifie les écarts dans les bases de données et des tables spécifiques les identifie et les analyse. Il génère également les scripts nécessaires pour les synchroniser. Il offre une interface visuelle et un tas d'options pour exécuter les tâches rapidement et simplement.
Alertes de l'agent SQL Server
Tous les composants clés liés aux agents de réplication résident en tant que travaux sous les travaux de l'Agent SQL Server. Par conséquent, il est essentiel de surveiller en permanence le fonctionnement des travaux de l'Agent SQL Server pour garantir que la réplication fonctionne sans aucun problème. Les problèmes les plus courants sont indiqués ci-dessous :
- Problème d'autorisations lors de l'exécution de l'une des tâches de l'agent de réplication
- Problème d'autorisations lors de l'exécution de l'une des tâches de maintenance de réplication.
- Problème d'autorisations d'accès à la base de données de l'éditeur, de la distribution ou de l'abonné.
- L'Agent SQL Server n'est pas configuré pour démarrer automatiquement au redémarrage du serveur.
- Plusieurs autres problèmes de données liés à la réplication, tels que des conflits, des données manquantes, etc.
C'est pourquoi nous devons mettre en place un mécanisme d'alerte approprié pour informer immédiatement l'administrateur de bases de données ou toute autre personne de tout problème.
Pour alerter les administrateurs de base de données ou d'autres personnes en cas d'échec ou d'erreur de travail, nous devons configurer la messagerie de base de données pour envoyer des alertes par e-mail. Cela permet au DBA de répondre immédiatement et de résoudre le problème. Nous verrons comment configurer la messagerie et les alertes de la base de données dans un article séparé ultérieurement.
Lors de la configuration de la réplication, SQL Server crée par défaut l'ensemble d'alertes ci-dessous. Vous pouvez les configurer facilement pour les critères requis. Il assure également l'envoi de notifications aux personnes requises pour une action immédiate.
Conclusion
Merci d'avoir parcouru un autre article énorme sur la réplication. J'espère que cela a aidé à clarifier les éléments internes de la réplication transactionnelle et les détails concernant la base de données de distribution, les agents de réplication et les programmes autonomes responsables de ceux-ci. Nous avons également identifié la latence de réplication, les alertes et les jetons traceurs.
Nous pouvons maintenant approfondir et apprendre à traiter et résoudre les problèmes de réplication de manière professionnelle. Restez à l'écoute pour le prochain article !
