19.1 Réplication de base de données
Pour répliquer une base de données, le moyen courant est l'utilisation de l'historique de modification. 9.2 Historique de modification. Cela impose à la base dont les données change d'agir en tant que maître, et des autres bases seront ses clients. Pour modifier une base cliente, il suffit de lancer l'utilitaire mysql < update_log, avec les informations d'hôte, utilisateur et mot de passe.pour accéder à la base cliente, et d'utiliser la base maître comme source.
Si vous n'avez jamais effacé quoique ce soit d'une table, vous pouvez utiliser une colonne de type TIMESTAMP pour savoir quelle colonne a été insérée pour modifiée dans une table depuis la dernière réplication (en comparant les dates de la dernière réplication) : vous pouvez alors ne copier que les nouvelles lignes dans la table.
Il est possible de faire une modification full duplex, en utilisant l'historique de modification (pour les effacements), et les timestamps (pour le reste). Mais, dans ce cas, vous devez être capable de gérer les conflits de données, si les valeurs ont été modifiées dans les deux tables en même temps. Vous souhaiterez probablement garder la vieille version pour pouvoir choisir laquelle est la bonne.
Etant donné que la réplication se fait avec des commandes SQL, vous ne pouvez pas utiliser les fonctions suivantes dans les requêtes lorsque vous modifiez les base de données, car elle risque de ne pas retourner la même valeur que dans la base originale :
DATABASE()GET_LOCK()andRELEASE_LOCK()RAND()USER(),SYSTEM_USER()orSESSION_USER()VERSION()
Toutes les fonctions de temps sont valides, car un timestamp est envoyé au miroir en cas de besoin.. LAST_INSERT_ID() est aussi valide.
