Recommend Me


Vendredi 17 février 2006

Introduction à la réplication de bases de données

(Linux Magazine France HS n°18 - Février 2004)

Etre capable de faire de la haute disponibilité de machines est une chose qui présente de nombreux avantages. Malheureusement elle ne résout pas à elle seule la disponibilité des services hébergés, et la solution peut parfois être fort complexe dans le cadre des bases de données. Ceci est dû au fait que, contrairement à un serveur web, un site ftp ou tout autre service, il s’agit de gérer un jeu de données qui peuvent être modifiées à fréquence élevée.

1. Définition

Une application de base de données repose sur un modèle client-serveur. Dans ce modèle, le client se connecte au SGBD pour passer des ordres. Ces ordres sont de deux natures : lecture (on parle alors de requêtes) ou mise à jour (on parle alors de transactions). Pour les transactions il y a une modification des données sur le serveur, mais cela reste des ordres de courte durée. A l’inverse, dans le cas d’une lecture, il n’y a pas de modification des données mais les traitements peuvent être longs et porter sur une grande masse de données. On comprend donc aisément que, dans le cadre d’un site web par exemple, un nombre important de requêtes peut emboliser partiellement (ou complètement) le serveur. Il existe plusieurs solutions pour palier à ce genre de problèmes et, ça tombe bien, la réplication en est une ;).

L’objectif principal de la réplication est de faciliter l’accès aux données en en augmentant la disponibilité. Soit parce que les données sont copiées sur différents sites permettant de répartir les requêtes, soit parce qu’un site peut prendre la relève lorsque le serveur principal s’écroule. Une autre application tout aussi importante est la synchronisation des systèmes embarqués non connectés en permanence.

Ce qui peut se résumer à l’aide des trois types de scénarii suivants :

  • deux serveurs distants sur lesquels les données doivent être consistantes ;
  • deux serveurs, un comme serveur principal, l’autre comme serveur de backup à chaud ;
  • plusieurs serveurs en cluster utilisés pour de l’équilibrage de charge et de la tolérance à la panne.

2. Principe

Le principe de la réplication, qui met en jeu au minimum deux SGBD, est assez simple et se déroule en trois temps :

  1. La base maître reçoit un ordre de mise à jour (INSERT, UPDATE ou DELETE).
  2. Les modifications faites sur les données sont détectées et stockées (dans une table, un fichier, une queue) en vue de leur propagation.
  3. Un processus de réplication prend en charge la propagation des modifications à faire sur une seconde base dite esclave. Il peut bien entendu y avoir plus d’une base esclave.

Bien entendu il est tout à fait possible de faire de la réplication dans les deux sens (de l’esclave vers le maître et inversement). On parlera dans ce cas-là de réplication bidirectionnelle ou symétrique. Dans le cas contraire la réplication est unidirectionnelle (seulement du maître vers l’esclave) et on parle de réplication en lecture seule ou asymétrique. De plus la réplication peut être faite de manière synchrone ou asynchrone. Dans le premier cas la résolution des conflits éventuels entre deux sites intervient avant la validation des transactions ; Dans le second cas, la résolution est faite dans des transactions séparées. Il est donc possible d’avoir quatre modèles de réplication :

  • Réplication asymétrique (maître/esclave) avec propagation asynchrone ;
  • Réplication asymétrique (maître/esclave) avec propagation synchrone ;
  • Réplication symétrique ou Peer-to-peer (update everywhere) avec propagation asynchrone ;
  • Réplication symétrique avec propagation synchrone.

3. La mise à jour synchrone

La réplication synchrone est aussi appelée “réplication en temps réel”. La synchronisation est effectuée en temps réel puisque chaque requête est déployée sur l’ensemble des bases de données avant la validation (commit) de la requête sur le serveur où la requête est exécutée. Ce type de réplication assure un haut degré d’intégrité des données mais requiert une disponibilité permanente des serveurs et de la bande passante. Ce type de réplication, fortement dépendant des pannes du systèmes, nécessite de gérer des transactions multisites coûteuses en ressources.

La réplication synchrone asymétrique

Une modification sur le site primaire sera propagée aux sites secondaires à l’aide par exemple d’un trigger sur la table modifiée. La table est modifiée en temps réel sur les autres sites, ces modifications faisant parties de la transaction.

La réplication synchrone symétrique

Dans ce cas, il n’y a pas de table maître, mais chaque table possède ses triggers, déclenchés lors d’une modification. Il est alors nécessaire de définir des priorités et de gérer les blocages des tables en attendant qu’une modification soit entièrement propagée. D’autre part, les triggers doivent différencier les mises à jour issues d’une réplication des mises à jour de requête directes.

4. La mise à jour asynchrone

La réplication asynchrone (aussi appelée “Store and Forward” pour << stocker et propager >> ) stocke les opérations intervenues sur une base de données dans une queue locale pour les propager plus tard à l’aide d’un processus de synchronisation.

Ce type de réplication est plus flexible que la réplication synchrone. Il permet en effet de définir les intervalles de synchronisation, ce qui permet à un site de fonctionner même si un site de réplication n’est pas accessible. L’utilisateur peut ainsi déclarer que la synchronisation sera effectuée la nuit, à une heure de faible affluence. Si le site distant est victime d’une panne, l’absence de synchronisation n’empêche pas la consistance de la base maître. De même une panne de réseau laissera les deux bases, maître et esclave dans des états de consistance. Les opérations sur les données sont plus rapides, puisqu’une requête n’est pas immédiatement déployée. Le traffic sur le réseau est de ce fait plus compact. Par contre, le planning de réplication est dans ce cas plus complexe, puisqu’il s’agit de gérer les conflits émanant d’un éventuel accès en écriture sur une base esclave entre deux mises à jour.

La réplication asynchrone asymétrique

Les mises à jour sont stockées dans une file d’attente et ne seront propagées que lors d’un déclenchement programmé.

La réplication asynchrone symétrique

Toute modification sur toute table de toute base est stockée dans une file pour être rejouée ultérieurement. De fortes incohérences des données sont à craindre.

5. En théorie et en pratique

Dans les deux articles suivant nous allons vous présenter les solutions existantes pour faire de la réplication avec PostgreSQL avant d’aborder la pratique avec MySQL. Sachez cependant que la réplication est possible avec n’importe quel base (libre ou non), mais que le prix de sa mise en place varie énormément d’un système à l’autre.

Stéphane SCHILDKNECHT
Grégoire Lejeune

• • •

Pas de commentaire »

Pas encore de commentaire.

RSS des commentairesTrackBack URI

Laisser un commentaire

You must be logged in to post a comment.

Powered by: WordPress • Template adapted from the Simple Green' Wench theme - RSS