Cours introduction à la réplication de bases de données, tutoriel & guide de travaux pratiques en pdf.

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.

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.