Il existe une application de librairie universitaire en ligne où de nombreux étudiants peuvent acheter des livres. Chaque fois qu'un étudiant se connecte, il affiche une liste de suggestions basées sur son historique d'achat précédent. Le serveur SQL qui stocke les données client se trouve à Seattle, mais ces étudiants se connectent depuis le monde entier. Par conséquent, les performances peuvent en souffrir et ceux qui sont plus éloignés sur le WAN peuvent subir un décalage dans le temps pour les requêtes.
Au lieu de faire subir aux étudiants les plus éloignés des temps de chargement de page lents, la réplication peut être utilisée pour copier et maintenir les objets de la base de données sur plusieurs sites et les synchroniser ultérieurement afin de maintenir la cohérence. Chaque site conserve la partie de la base de données qui contient les données les plus pertinentes pour eux et les plus fréquemment utilisées. Désormais, chaque élève peut acheter des livres sur le site Web et les données seront synchronisées ultérieurement.
Fonctionnement de la réplication de données
Il existe plusieurs composants serveur, et ils assument différents rôles afin de mettre en œuvre la réplication. Un rôle d'éditeur est une instance de base de données où réside la source des données et qui contient des objets conçus comme des articles de réplication. Ces articles sont regroupés et publiés dans une publication afin que les données soient répliquées comme une unité. L'éditeur peut avoir plusieurs publications.
Un rôle de distributeur est une instance de base de données qui contient les bases de données de distribution. Chaque éditeur est mappé à une seule base de données de distribution qui stocke les données répliquées de l'éditeur qui doivent être transmises à l'abonné. Le distributeur peut être configuré en tant que distributeur local, ce qui signifie qu'une seule instance de serveur peut jouer à la fois les rôles d'éditeur et de distributeur. Si un distributeur est configuré sur des serveurs distincts, il est appelé distributeur distant.
Un rôle d'abonné est la ou les instances qui reçoivent les données répliquées en s'abonnant aux publications. L'abonné n'est pas limité et peut recevoir des données de plusieurs éditeurs, et les objets peuvent être mis à jour en fonction du type de réplication. Le cas échéant, l'éditeur recevrait ces modifications de l'abonné et republierait les données.
En général, l'abonné reçoit les modifications apportées aux données de deux manières :via un abonnement push ou un abonnement pull. La différence réside dans le composant serveur qui effectue les mises à jour. Avec push, le distributeur pousse ou met directement à jour la base de données des abonnés. Avec pull, l'abonné se connecte au distributeur pour voir s'il y a eu des changements, et il effectuera lui-même la mise à jour.
Trois types de réplication de données
Pour implémenter la réplication, plusieurs agents sont utilisés pour effectuer les tâches associées à la copie des modifications, au suivi des modifications et à la distribution des données. Les agents nécessaires dépendent du type de réplication utilisé. Il existe trois principaux types de réplication.
1. Réplication d'instantané
La réplication de snapshot est le type de réplication de données le plus simple et est utilisée si les données ne sont pas modifiées aussi souvent ou si de petits volumes de données doivent être répliqués. Par exemple, s'il y a des tables qui ne sont pas souvent mises à jour, les Snapshot Agents peuvent être utilisés pour copier l'intégralité de la base de données une ou plusieurs fois selon un calendrier. Ensuite, un Agent de Distribution se charge de transférer ces fichiers à l'abonné.
Cette technique nécessite peu de maintenance car ce qui est distribué est un instantané des données à un moment précis dans le temps. De plus, il n'est pas nécessaire de surveiller les modifications car chaque fois qu'un abonné reçoit une mise à jour, il écrase la copie entière des données.
Malheureusement, la copie d'une base de données entière peut contribuer à une latence élevée ou à plus d'attentes que souhaitable. La génération d'instantanés nécessite de détenir des verrous sur les objets. Ce n'est pas pratique si les données sont souvent modifiées et susceptibles d'avoir un impact sur les performances, par exemple, si l'éditeur a beaucoup d'activités d'insertion, de mise à jour et de suppression.
En plus d'utiliser les Snapshot Agents pour créer les snapshots, les réplications transactionnelles tirent également parti des Log Reader Agents qui s'exécutent au niveau du distributeur. L'agent de lecture du journal lit les journaux de transactions de la base de données de l'éditeur et ne fournit que les modifications marquées au lieu d'attendre sur une base de données entière. Cela offre de la flexibilité car cela vous donne la possibilité de décider de la quantité de base de données à publier (par exemple, une colonne). Ensuite, l'agent de distribution déplace les transactions vers les abonnés, et là où il s'exécute, il s'adaptera respectivement aux stratégies d'abonnement push et pull.
2. Réplication transactionnelle
La réplication transactionnelle standard implique que les données de l'abonné sont en lecture seule. Cependant, il existe différents types de publication qui permettent d'effectuer des modifications chez l'abonné. Si ces modifications sont apportées, elles peuvent être transmises à l'éditeur pour republier. L'agent de lecture de la file d'attente est utilisé pour la réplication transactionnelle bidirectionnelle, et il lira les modifications de la file d'attente et les appliquera à l'éditeur.
La réplication transactionnelle est très avantageuse dans un environnement de serveur à serveur où des modifications peuvent être apportées au niveau de l'éditeur et de l'abonné en temps réel, par exemple, des données en temps réel concernant les vols actuellement disponibles pour une compagnie aérienne. Il n'est pas logique d'utiliser la réplication d'instantané dans ce cas, car les mises à jour sont généralement synchronisées une fois par jour ou selon une planification.
3. Réplication de fusion
La réplication de fusion ressemble à la réplication de transaction, mais elle permet de fusionner les mises à jour de l'abonné et de l'éditeur. De nombreux abonnés peuvent se déconnecter, effectuer des mises à jour des données à différents moments, puis revenir en ligne et synchroniser ces modifications ultérieurement.
Ce type de réplication est susceptible d'être utilisé dans des environnements serveur à client tels que les clients mobiles. Comme pour la réplication d'instantané et de transaction, l'instantané initial est créé par l'Agent d'instantané, mais ensuite l'Agent de fusion suivra les modifications et résoudra les conflits avec les déclencheurs. Si plusieurs abonnés mettent à jour les mêmes lignes, ils peuvent causer un problème. Par conséquent, la résolution des conflits doit être prise en compte.
