> Tech > Annexe 1 : Principes de base de la réplication

Annexe 1 : Principes de base de la réplication

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

La réplication permet d'offrir les données où et quand elles sont nécessaires. Elle est particulièrement utile dans les scénarios suivants:

  • Epauler une force de ventes mobile déconnectée
  • Maintenir un serveur en « warm-standby », en secours
  • Maintenir un serveur OLAP (online analytical processing)
  • Agréger les

ventes provenant de serveurs distribués dans
l’entreprise, dans une seule base de données

  • A partir d’une base de données, se déployer vers plusieurs
    serveurs de bases de données du e-Commerce
  • On distingue trois types principaux de réplication: par instantané,
    transactionnelle et par fusion. Chacun d’eux applique
    divers degrés de latence des données : des mises à  jour en
    temps réel aux modes offline ou déconnectés. La réplication
    par instantané, le genre le plus simple, consiste à  capturer une
    vue instantanée d’une publication comme un instantané des
    données et à  le transférer vers l’abonné (Subscriber). La réplication
    par instantané est intéressante quand les données sont
    relativement statiques ou quand une haute latence est acceptable.
    On utilise aussi la réplication par instantané pour fournir
    les données initiales aux deux autres modes de réplication: par
    fusion et transactionnelle.
    La réplication transactionnelle commence par un instantané
    des données de publication que l’on veut transférer vers le
    Subscriber. A partir de là , la réplication envoie au fur et à  mesure
    les changements au Subscriber. Bien qu’on utilise généralement
    la réplication transactionnelle pour la transmission du
    Publisher vers le Subscriber, il est également possible de propager
    les mises à  jour effectuées chez le Subscriber vers le
    Publisher – c’est ce qu’on appelle des abonnements actualisables.
    Le processus de réplication peut même mettre ces
    changements de Subscriber en file d’attente en cas d’interruption
    de la connexion. Toutefois, si l’on a affaire à  un scénario
    dans lequel les utilisateurs apportent beaucoup de modifications
    aux données chez le Subscriber ou dans lequel le
    Subscriber sera déconnecté pendant une longue durée, il vaut
    mieux se tourner vers la réplication par fusion.
    Dans la réplication par fusion, les utilisateurs peuvent librement
    modifier les données publiées aussi bien chez le
    Publisher que chez le Subscriber, même en mode entièrement
    déconnecté. Quand la connexion entre le Publisher et le
    Subscriber est établie, la réplication par fusion transfère les
    changements du Subscriber vers le Publisher, utilise des règles
    prédéfinies pour résoudre les éventuels changements du
    Subscriber qui seraient en conflit avec ceux effectués chez le
    Publisher, et transfère en aval les changements du Publisher (y
    compris les éventuels conflits résolus) vers le Subscriber. C’est
    ce qu’on appelle la synchronisation. La réplication par fusion
    supporte également SQL Server 2000 Windows CE Edition
    Subscribers, ce qui en fait la solution idéale pour répliquer des
    données sur des appareils portatifs.
    La réplication de SQL Server est effectuée par un ensemble de
    tables de système de réplication chez le Publisher et le
    Distributor (et chez le Subscriber, dans le cas de réplication par
    fusion), un groupe de procédures stockées du système de réplication
    et un groupe d’agents de réplication. Ces agents, que
    le SQL Server Agent peut héberger et planifier, gèrent le flux
    des données de réplication et assument la fonction de réplication.
    Les principaux agents de réplication sont les suivants:

    • Snapshot Agent. Cet agent, qui intervient dans tous les types
      de réplication, fonctionne chez le Distributor et gère l’instantané
      des données.

    • Log Reader Agent. En réplication transactionnelle, chaque
      base de données de publication a son propre Log Reader
      Agent, qui fonctionne chez le Distributor et lit les données
      provenant du journal sur la base de données de publication.

    • Distribution Agent. Cet agent, utilisé dans la réplication par
      instantané et transactionnelle, fonctionne soit chez le
      Distributor soit chez le Subscriber et est chargé de transférer
      les données du Distributor vers le Subscriber.

    • Merge Agent. Il fonctionne chez le Distributor ou chez le
      Subscriber pour appliquer l’instantané initial chez le
      Subscriber. Après quoi il transfère et rapproche tous les changements
      de données pendant une synchronisation de fusion.

    Le comportement des agents Distribution et Merge
    dépend aussi du genre d’abonnements qu’ils gèrent. La réplication
    a deux types principaux d’abonnements: abonnements
    pull, qui sont gérés par le Subscriber, et abonnement push, gérés
    par le Distributor. Pour les abonnements push, ces agents
    fonctionnent sur le Distributor et le Publisher/Distributor gère
    le comportement des agents. Pour des abonnements pull, les
    agents fonctionnent chez le Subscriber. Les abonnements pull
    anonymes sont un type spécial d’abonnement pull dans lequel
    le Publisher n’a pas besoin de maintenir le jeu complet de
    métadonnées concernant les Subscribers.
    Vous pouvez superviser tous ces agents au moyen du composant
    Replication Monitor de Enterprise Manager. En outre, vous
    pouvez accéder à  la plupart de leurs fonctionnalités par programme,
    en utilisant des procédures stockées de réplication ou
    des utilitaires ligne de commande, ou encore en utilisant des
    contrôles de réplication ActiveX, comme on le voit dans l’article
    principal. Pour plus d’informations sur la programmation de la
    réplication et sur la réplication SQL Server en général, voir la
    masse d’informations qui se trouvent dans SQL Server 2000
    Books Online (BOL).

    Téléchargez cette ressource

    Guide de Sécurité IA et IoT

    Guide de Sécurité IA et IoT

    Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

    Tech - Par Renaud ROSSET - Publié le 24 juin 2010