Une réplication de base de données consiste à assurer la cohérence d’informations entre plusieurs bases de données.
L’objectif d’une réplication de base de données est de faciliter la montée charge et d’améliorer la fiabilité du système en réduisant le risque de pannes et les soucis de disponibilités. On se sert de mécanismes de réplications de données sur des systèmes critiques ou très volumineux dans lesquels les pertes de données peuvent avoir des conséquences importantes.
La réplication se fait en continu alors que la sauvegarde correspond à une vue figée à un moment donné. Tout l’enjeu est donc d’arriver à obtenir des copies conforme en quasi temps réel entre différentes bases de données.
Concrètement, la réplication de base de données (dans sa forme la plus simple) nécessite une base de données maître et une base de données esclave. Le maître tient un carnet de bord de toutes les opérations effectuées. Ce journal est lu par la base esclave qui va répercuter de son côté les mêmes opérations. Une fois le traitement réalisé du côté esclave, ce dernier envoie l’information au maître qui peut débloquer l’opération suivante à réaliser. Le délai acceptable et le nombre de bases de données (maîtres et esclaves) dans la configuration souhaitée permet de dimensionner l’infrastructure de réplication.
Types de réplication
La réplication peut être :
- Unidirectionnelle : les données vont toujours du maître vers l’esclave ;
- Bidirectionnelle : les données peuvent être répliquées dans les 2 sens ;
Pour prévenir les tracasseries techniques, il y a deux approches :
- les outils de réplications « synchrones » s’assurent en amont qu’il n’y aura pas de conflit ;
- les outils « asynchrones » de réplication ne vérifient pas au préalable et tentent de résoudre les conflits à posteriori si le cas se présente.
Ainsi, en cumulant les 2 dernières caractéristiques, on obtient 4 modèles de réplications possibles. Il existe d’autres possibilités notamment lorsque aucun serveur n’est maître (masterless).
Pas si simple, la réplication
Les opérations de réplication peuvent devenir vite ardues lorsqu’il y a plusieurs bases de données maîtres. Se pose notamment le problème des transactions et tout particulièrement lorsqu’il faut les défaire.
Lorsque les architectures de réplication sont complexes avec des réplications à la fois verticales et horizontales (plusieurs maîtres et plusieurs esclaves), on dit que la réplication est transparente : il est alors difficile de savoir quel serveur est effectivement utilisé. On se heurte alors au problème de Brewer CAP. Il faut alors faire des choix et sacrifier la cohérence des données au profit de la disponibilité ou de la tolérance au partitionnement.
En cas de panne d’une base de données, que se passe-t-il ?
- Si c’est un esclave qui ne répond plus, la réplication ne se fait plus. Le système doit alors répartir la charge sur les autres machines : le système dans son ensemble peut ralentir ;
- Si c’est le maître qui est en panne, il faut que l’esclave prenne le relais en automatique. Lorsque le maître sera de nouveau accessible, il faudra le répliquer depuis son esclave et basculer temporairement l’esclave ayant pris le relais en maître.
La réplication se fait avec tous les SGBD majeurs. MySQL, PostgreSQL, DynamoDB, MongoDB gèrent les approches avec un seul maître. SQL Server CouchDB, Redis peuvent faire du multi-maître. Enfin Cassandra permet de faire de la réplication masterless.
