Réplication des bases de données MySQL (installation et configuration)

Intérêt
La réplication de bases de données MySQL est un processus qui fait intervenir deux serveurs ou plus, dont les bases de données (sélectionnées) se synchronisent entre elles. L’objectif est de fournir un mécanisme de reprise sur incidents (failover) ou de participer à la haute disponibilité du service (high availability). Une réplication de bases de données MySQL peut suivre différents schémas : le plus simple, que nous désignerons par A → B est constitué par un serveur maître (A) et un serveur esclave (B) dont les bases de données se synchronisent à partir de A. Un autre schéma populaire est celui d’une réplication circulaire, de type A → B → A, dans laquelle le serveur A et le serveur B sont à la fois maître et esclave : dans ce schéma, les bases de données de A sont synchronisées sur B, et réciproquement.

L’implémentation de ces deux schémas, avec la configuration du maître, de l’esclave, et les commandes MySQL servant pour initialiser et pour relancer une réplication seront décrits ici. Nous nous intéresserons ensuite à la configuration spécifique des serveurs pour que les requêtes d’insertion (INSERT statements) dans des tables avec des champs en AUTOINCREMENT puissent être répliquées même en cas d’interruption momentanée de la réplication.

Le contenu de cet article s'appuie sur différentes sources, ainsi que sur l'expérience des auteurs : nous n'avons pas trouvé, en effet, de tutoriel récent en Français sur le sujet. Si la syntaxe a légèrement évolué depuis les versions 4.x de MySQL (quelques commandes sont notamment tombées en désuétude), elle demeure cependant identique dans les grandes lignes : nous mentionnerons les principaux changements introduits avec MySQL 5.x.

Enfin, les documents utilisés comme référence (en Anglais) seront listés en annexe.

Si vous disposez déjà de deux machines configurées avec MySQL et pouvant se connecter l’une à l’autre, vous pouvez continuer la lecture à partir de la section Mise-en-œuvre de la réplication de bases de données, sinon lisez ce qui suit pour savoir quels sont les prérequis, comment installer MySQL et éventuellement PhpMyAdmin.


Table des matières

1. Prérequis : installation des serveurs et des clients MySQL sous Linux

Pour suivre ce tutoriel, vous devez avoir accès à deux machines (physiques ou virtuelles) placées sur le même réseau ou du moins, pouvant communiquer entre elles sur le port 3306. Ces machines, pour l'exemple, seront simplement nommées A et B.

Quel que soit le(s) système(s) que vous utiliserez, des paquets binaires de MySQL existent très probablement : cet article suppose que vous utiliserez la version 5.x du serveur de bases de données (et le client correspondant). Pour des raisons évidentes, il est recommandé que la version installée sur chaque serveur soit identique (et donc, que le système d'exploitation de chaque serveur soit identique).

En outre, pour toute utilisation sérieuse de MySQL, un système GNU / Linux est fortement recommandé.

Selon la distribution GNU / Linux que vous utilisez, l’installation de MySQL s’effectue via les commandes apt-get (Debian et dérivés, comme Ubuntu), pacman (Archlinux), ou yum (Redhat / CentOS / Fedora / Mandriva...) : veuillez utiliser la commande man pour en obtenir la syntaxe.


1.1. Installation de MySQL (serveur et client) sur Arch Linux

Par exemple, dans le cas d'un système Arch Linux, installez MySQL (client et serveur) à l'aide de :

pacman -S mysql
pacman -S mysql-clients

Ensuite, ajoutez le service si ce n'est déjà à /etc/rc.conf pour qu'il démarre automatiquement :

# -----------------------------------------------------------------------
# DAEMONS
# -----------------------------------------------------------------------
#
# Daemons to start at boot-up (in this order)
#   - prefix a daemon with a ! to disable it
#   - prefix a daemon with a @ to start it up in the background
#
DAEMONS=(syslog-ng netfs crond dbus networkmanager sshd laptop-mode httpd mysqld)


1.2. Installation de l'interface d'administration PhpMyAdmin (optionnel)

Si vous souhaitez avoir recours à une interface graphique pour administrer vos bases de données MySQL, nous vous recommandons fortement d'installer PhpMyAdmin : http://www.phpmyadmin.net/

Cette application web entièrement libre nécessite un serveur web (comme Apache 2.x), PHP (PHP 5.3+ est recommandé pour les versions récentes) avec l’extension Mcrypt et... Un serveur de bases de données MySQL. L’installation et la configuration de ces différents composants sort du cadre de cet article, mais sous Archlinux, sachez qu’il vous suffira de suivre à la lettre la procédure pour installer et configurer un serveur Lamp qui est détaillée ici : http://wiki.archlinux.fr/Lamp ; puis celle-ci pour installer et configurer PhpMyAdmin : http://wiki.archlinux.fr/Phpmyadmin


2. Configuration du réseau pour les serveurs MySQL A et B

Pour la suite — et dans le cadre d’une utilisation normale de vos serveurs MySQL— vous aurez besoin que ces derniers soient accessibles via le réseau (en TCP/IP) et non seulement en local via un port (socket).

Pour que MySQL accepte les connexions depuis le réseau, il faut vérifier que le fichier de configuration de MySQL, /etc/mysql/my.cnf, a bien la directive skip-networking commentée (i.e. désactivée), comme dans l’extrait suivant :

# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking

Veuillez noter que le port utilisé par le service MySQL est (en principe) 3306 : les serveurs A et B doivent pouvoir communiquer sur ce port : il devra donc être ouvert sur un éventuel pare-feu qui serait placé entre les deux machines.


3. Mise-en-œuvre de la réplication de bases de données

À partir de maintenant, nous mettre en place la réplication de bases de données : que ce soit dans le cas d’un schéma A → B ou dans le cas d’un schéma A → B → C, la réplication de bases de donnés implique une configuration différente sur chaque serveur. Cette configuration dépend de leur rôle et nécessite (entre autres) un identifiant unique dans la chaîne de réplication. Elle consiste à éditer le fichier /etc/mysql/my.cnf et à lancer quelques commandes dans la console SQL.

Nous allons d’abord nous intéresser à la configuration de la réplication de bases de données MySQL A → B (schéma dans lequel A est le serveur maître (master) et B le serveur esclave (slave)).

Ensuite, nous ajouterons à ce schéma la configuration pour la réplication de bases de données B → A, ce qui aura pour effet de mettre en place un schéma de réplication croisée ou circulaire, c'est-à-dire du type A → B → A.


3.1. Configuration de la réplication A → B

Le type le plus élémentaire de réplication de bases de données qui peut être mis en œuvre est une réplication A → B : un serveur esclave B réplique les bases de données d’un serveur maître A. Cette configuration peut évoluer très simplement vers une configuration A → B, A → C, A → n en lui ajoutant autant d’esclaves que nécessaire : la configuration de chaque esclave sera identique à celle de B (en prenant soin de leur attribuer un server-id unique : voir ci-après).


3.1.1. Ajout d'un utilisateur MySQL pour la réplication de bases de données sur le serveur A

La réplication, ou synchronisation, de bases de données entre deux serveurs présuppose l’existence d’un utilisateur MySQL ayant des droits suffisants sur chaque serveur maître (que nous nommerons ici replication) : le serveur esclave (B) doit pouvoir se connecter au maître (A) avec cet utilisateur. L’utilisateur créé doit en outre posséder le privilège spécial de REPLICATION.

La première étape consiste donc à créer l’utilisateur replication sur le serveur A et à lui octroyer des privilèges suffisants (nous nous contenterons ici du privilège de REPLICATION, mais vous devrez en ajouter d’autres).

Voici les requêtes SQL à exécuter sur le serveur A pour créer l’utilisateur replication :

GRANT REPLICATION,<d'autres privilèges> SLAVE ON *.* TO 'replication'@'%' IDENTIFIED BY '<saisissez ici le mot de passe souhaité>';
FLUSH PRIVILEGES;

Notez que les privilèges sont ici accordés à l’utilisateur replication depuis n’importe quel hôte sur le réseau à l’aide du caractère % (valant pour toutes les adresses, ce qui est bien plus simple si on veut ajouter ensuite ou déplacer des serveurs MySQL).

Vous devez bien entendu remplacer <d’autres privilèges> par la liste des privilèges MySQL à accorder à l’utilisateur replication.


3.1.2. Configuration du serveur maître A (master de réplication)

La configuration d’un serveur maître ou master de réplication doit, comme dans les versions précédentes de MySQL, s’effectuer dans le fichier /etc/mysql/my.cnf.

Directives à ajouter ou à éditer dans le fichier de configuration /etc/mysql/my.cnf du serveur maître A :

server-id=1
log-bin = /home/mysql/logs/mysql-bin.log
binlog-do-db=<base de données a>
binlog-do-db=<base de données b>
binlog-do-db=<base de données c>

Notez que server-id, un nombre entier quelconque, doit être unique dans la chaîne de serveurs mise en place pour la réplication : il s’agit d’un identifiant unique pour le serveur MySQL et non pour son rôle en tant que maître (dans ce cas) ou en tant qu’esclave (s’il s’agissait du serveur B) : il ne doit donc y avoir qu’un identifiant server-id par fichier de configuration my.cnf, et cela même si le serveur est à la fois maître et esclave (comme nous le verrons ensuite).

log-bin et binlog-do-db servent respectivement à indiquer qu’un fichier journal binaire des requêtes SQL doit être créé sur le serveur maître (il sera utilisé par l’esclave pour rejouer les requêtes) et à indiquer que ce fichier journal doit être utilisé (dans l’exemple) pour les bases de données a, b, et c (remplacez pour chaque entrée <base de données n> par le nom d’une base de données à synchroniser).

Pour que le serveur MySQL joue son rôle de maître, il faut ensuite le redémarrer.

Redémarrer le serveur maître A sur Arch Linux :

/etc/rc.d/mysql restart

Sur Debian et autres :

/etc/init.d/mysql restart

ou

service mysql restart


3.1.3. Configuration du serveur B comme esclave de A (slave)

Il faut ensuite faire savoir au serveur B qu'il est l'esclave de A pour la réplication des bases de données sélectionnées. Dans notre exemple, ces bases de données sont <base de données a>, <base de données b> et <base de données c>.

Le serveur B, serviteur zélé s’il en est, devra aller lire le fichier journal binaire du maître pour créé pour ces bases. Il les copiera automatiquement dans un fichier tampon, ou fichier « relais » (relay) en terminologie MySQL, et il en jouera les requêtes.

Notez que la réplication des bases se déroule de manière asynchrone, ce qui n'est pas sans pouvoir poser un certain nombre de problèmes, notamment dans le cas de la réplication croisée.

Pour configurer un serveur esclave, il fallait précédemment —comme pour le maître— éditer le fichier my.cnf. Pour simplifier le processus (et pour faciliter l'ajout de nouveaux esclaves à un maître), les versions récentes de MySQL (5.x) permettent d'effectuer cette opération « à chaud » directement dans la console SQL, à l'aide de la commande CHANGE MASTER TO. C'est cette dernière méthode, plus récente, que nous allons employer ici.

Dans tous les cas, cependant, le serveur esclave B doit être configuré au préalable avec : – un server-id unique, comme il a été dit précédemment, – il est utile, en outre, d’indiquer dans la configuration de l’esclave quel sera le nom du fichier relais qu’il emploiera. Notez que si tel n’était pas le cas, le nom du fichier relais serait automatiquement créé par MySQL à partir du nom d’hôte (hostname) de la machine, ce qui poserait problème au cas où cette dernière serait renommée par la suite.

Aussi, vous devez commencer par éditer le fichier /etc/mysql/my.cnf du serveur esclave B comme suit :

server-id=2
#Les trois directives suivantes ne sont plus obligatoires, mais peuvent encore être utilisées ici : 
#master-host=<ip du serveur a>
#master-user=replication
#master-password=<mot de passe de l'utilisateur replication>
#La directive suivante est recommandée : 
#   elle indique combien de tentatives successives de connexion pour la réplication seront effectuées  
master-connect-retry=60
#Les directives suivantes indiquent, comme sur le maître, quelles sont les bases de données à répliquer :
replicate-do-db=<base de données a>
replicate-do-db=<base de données b>
replicate-do-db=<base de données c>
#Le nom du fichier relais et de son index sur l'esclave
relay-log = /var/lib/mysql/slave-relay.log
relay-log-index = /var/lib/mysql/slave-relay-log.index


Lorsque vous aurez terminé, il faudra synchroniser manuellement les bases de données de A vers B (si ce n'est déjà fait), indiquer à B ce qu'il doit répliquer à partir de A, puis démarrer l'esclave sur B.


3.1.4. Synchronisation initiale des bases de données de A vers B

Avant le démarrage de la réplication (i. e. le lancement du processus esclave), il est nécessaire que les bases de données à répliquer soient identiques sur A et sur B (ou sur le maître et sur l’esclave).

Pour être certain que ce sera bien le cas, il est souhaitable de verrouiller en écriture les bases de données à copier (sur le maître), puis de les copier vers l'esclave.

Pour verrouiller les bases de données sur le serveur maître (A), exécutez :

FLUSH TABLES WITH READ LOCK;

Plusieurs procédés permettent ensuite de copier une base de données d’un serveur sur un autre. Depuis l’abandon de la syntaxe spéciale LOAD DATA FROM MASTER avec la version 5.0 de MySQL (cette dernière ne fonctionnait qu’avec des tables MyISAM), la manière canonique de copier des bases de données MySQL consiste à utiliser le binaire mysqldump (sur le maître A) :

mysqldump <base de données a> -u <utilisateur avec privilèges> -p > dump.sql;

Il vous faudra ensuite copier ce fichier vers le serveur cible (c'est-à-dire l'esclave B), par exemple à l'aide de scp :

cd <dossier ou se trouve le fichier sql>
scp dump.sql root@<ip du serveur cible>:/tmp/

Et importer le contenu du fichier copié dans MySQL (à nouveau, sur l'esclave B) :

mysql --user=<utilisateur avec privilèges> --password=<mot de passe de l'utilisateur> <base de données a> < /tmp/dump.sql

Dans les exemples ci-dessus, vous devez bien entendu remplacer <utilisateur avec privilèges>, <mot de passe de l'utilsateur> et <base de données a> par les paramètres correspondants.

Notez qu'à ce stade les bases de données à répliquer sont encore verrouillées en écriture sur le maître et qu'elles ne pourront donc pas changer avant que la réplication ne démarre.


3.1.5. Démarrage du processus esclave sur le serveur B

Pour lancer effectivement la réplication, il faut en premier trouver quel est le fichier journal qu'utilise actuellement le serveur maître et à quelle position du fichier journal il se trouve.

Dans la console SQL du serveur maître A :

SHOW MASTER STATUS;

renverra ces informations (seules les trois premières nous intéressent) :

*************************** 1. row ***************************
            File: mysql-bin.00001
        Position: 123435
    Binlog_Do_DB: <base de données a>,<base de données b>,<base de données c>
Binlog_Ignore_DB: 
1 row in set (0.00 sec)

La/les base(s) à répliquer, précédemment indiquées dans le fichier my.cnf doivent apparaître dans le listing (au vu des informations de l’exemple ci-dessus, ce peuvent être <base de données a>,<base de données b> et/ou <base de données c>).

Ensuite, il faut indiquer au serveur esclave B : – à partir de quel serveur maître il doit répliquer ses bases de données (on utilisera l'ip de A), – en lisant quel fichier journal de requêtes (dans l’exemple, mysql-bin.00001) – à partir de quelle position dans ce fichier journal (dans l'exemple ci-dessus, 123435) – et enfin, avec quel utilisateur (dans notre configuration, replication).

Tout ceci est effectué en une seule ligne avec la syntaxe spéciale CHANGE MASTER TO.

Important ! Le processus esclave, s’il existait, doit être arrêté auparavant.

Pour ce faire, dans la console SQL du serveur esclave B, exécutez :

SLAVE STOP;
CHANGE MASTER TO MASTER_HOST='<ip du serveur maître A>', MASTER_USER='replication', MASTER_PASSWORD='<mot de passe de l'utilisateur replication>', MASTER_LOG_FILE='mysql-bin.00001', MASTER_LOG_POS=123435;
SLAVE START;

Vous n’avez probablement pas oublié que nous avions verrouillé les bases de données en écriture sur le serveur maître A (le temps d’effectuer la synchronisation initiale des bases de données et de démarrer l’esclave) : à ce stade, il faut donc déverrouiller les bases de données sur le serveur maître A :

UNLOCK TABLES;


3.1.6. Test de la réplication A → B

Les tests exacts que vous devriez effectuer pour contrôler que la réplication fonctionne dépendent des privilèges accordés.

Le plus simple consiste à utiliser une table de test avec deux champs (ID, INT(11) en AUTOINCREMENT et contenu, VARCHAR(15)), à y insérer un enregistrement puis à le supprimer (toujours sur le maître A) en vérifiant à chaque étape que la requête SQL correspondante a bien été jouée sur B (i. e. que la base de données répliquée sur B est identique à celle sur A).

INSERT INTO test VALUES (NULL,'test');

puis :

DELETE FROM test WHERE contenu='test';


Vous pouvez également, après chaque requête, vérifier sur le maître que sa position dans le fichier journal a bien été incrémentée (à l’aide d’un SHOW MASTER STATUS;) et vérifier sur l’esclave que c’est bien cette position qui est lue. Pour cela, sur l’esclave B, il faut exécuter :

SHOW SLAVE STATUS \G;

Notez que le \G sert à force un affichage ligne par ligne, pour éviter un tableau trop grand pour pouvoir être lu confortablement.

Le résultat retourné est relativement complexe mais il contient (notamment) les informations à vérifier (fichier journal lu sur le maître, position, fichier relais, position), ainsi que l’état du processus esclave (Slave_IO_State) et la dernière erreur rencontrée :

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: <ip du maître A>
                  Master_User: replicate
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.00001
          Read_Master_Log_Pos: 12345
               Relay_Log_File: relay-bin.00001
                Relay_Log_Pos: 13
        Relay_Master_Log_File: mysql-bin.000023
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: <base de données a>,<base de données b>,<base de données c>
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 479
              Relay_Log_Space: 554
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
1 row in set (0.00 sec)


3.2. Configuration de la réplication B → A

L'ajout d'une réplication B → A à la configuration précédente implique que les serveurs A et B seront à la fois maître et esclave l'un de l'autre : ce type de réplication est parfois nommé « réplication croisée », ou « réplication circulaire ».

Les étapes pour la mettre en œuvre sont, à peu de choses près, les mêmes que précédemment, mais en sens inverse. Cependant, il faut désormais gérer l'existant...


3.2.1. Configuration du serveur B comme maître (master de réplication)

La configuration du serveur B comme maître revient à effectuer à nouveau les étapes Ajout d’un utilisateur MySQL pour la réplication de bases de données sur le serveur A et Configuration du serveur maître, mais sur B.

Il faut faire attention, cependant, à ne pas ajouter un nouveau server-id à B. Aussi, après avoir ajouté l’utilisateur replication sur B, on éditera son fichier /etc/mysql/my.cnf en lui ajoutant simplement les lignes suivantes :

log-bin = /home/mysql/logs/mysql-bin.log
binlog-do-db=<base de données a>
binlog-do-db=<base de données b>
binlog-do-db=<base de données c>


3.2.2. Configuration du serveur A comme esclave de B pour la réplication (slave)

Là encore, il faut répéter les étapes Configuration du serveur B comme esclave de A, mais sur le serveur A. On prendra garde à ne pas ajouter un nouveau server-id dans son fichier /etc/mysql/my.cnf :

#Les trois directives suivantes ne sont plus obligatoires, mais peuvent encore être utilisées ici : 
#master-host=<ip du serveur B>
#master-user=replication
#master-password=<mot de passe de l'utilisateur replication>
#La directive suivante est recommandée : 
#   elle indique combien de tentatives successives de connexion pour la réplication seront effectuées  
master-connect-retry=60
#Les directives suivantes indiquent, comme sur le maître, quelles sont les bases de données à répliquer :
replicate-do-db=<base de données a>
replicate-do-db=<base de données b>
replicate-do-db=<base de données c>
#Le nom du fichier relais et de son index sur l'esclave
relay-log = /var/lib/mysql/slave-relay.log
relay-log-index = /var/lib/mysql/slave-relay-log.index

Il sera en principe inutile de resynchroniser les bases de données à répliquer. Les tests pour vérifier la réplication B → A seront indentiques, mais exécutés en sens inverse (insertion et suppression d'enregistrement sur B, contrôle que la table correspondante est identique sur A).


3.3. Relance de la réplication après un incident ou en cas d'erreur

Lorsqu'une interruption a lieu dans le service MySQL, par exemple à la suite d'un incident réseau, il peut arriver que les bases de données soient désynchronisées et la réplication interrompue.

Il peut alors être utile de réinitialiser la réplication : pour cela, il faut arrêter le service, purger les journaux de réplication qui se trouvent en principe dans /var/lib/mysql sur l’esclave :

rm *relay*
rm master.info

Enfin, on purgera les journaux binaires qui se trouvent en principe dans /var/log/mysql sur le maître :

rm mysql-bin*

À chaque fois, il faudra observer le statut du maître et de l'esclave pour savoir s'il n'y a pas d'incohérence dans la lecture des journaux et/ou la position. Il faudra en outre s'assurer que les bases de données sont indentiques.


3.4. Configuration spécifique pour la réplication croisée des requêtes d'insertion dans une table avec des champs en AUTOINCREMENT

Afin d'éviter des conflits d'ID sur des champs en AUTOINCREMENT, dans le cas d'une réplication circulaire ou croisée et après une reprise sur incident, il est conseillé de configurer les serveurs pour qu'ils utilisent des IDs différents. Cela s'effectue avec les directives suivantes :

auto_increment_increment      = 10
auto_increment_offset         = 1

et, par exemple :

auto_increment_increment      = 10
auto_increment_offset         = 2

à placer respectivement dans le fichier /etc/mysql/my.cnf du serveur A et du serveur B (source : Advanced MySQL Replication Techniques, voir en annexe).


4. Annexe : configurations spécifiques et InnoDb

Pour comprendre quelle(s) architecture(s) peu(ven)t être mise(s) en œuvre avec la réplication MySQL, il faut lire ce document.

Si les bases de données synchronisées comportent des tables innoDB, il est recommandé d’ajouter les lignes suivantes au fichier /etc/mysql/my.cnf :

innodb_flush_log_at_trx_commit=1
sync_binlog=1

(Source : Step-by-step: How to setup MySQL Database replication, voir ci-après.)


5. Annexe : sources

Illustration : en guise d’icône, Le Serment de Spartacus, d’Ernest Barrias (gravure v. 1870)



Les droits de ce document sont régis par un contrat Creative Commons

et plus précisement par le contrat Creative Commons Paternité - Partage des Conditions Initiales à l’Identique Licence France 2.0 de Creative Commons, plus connue sous le nom de "CC-BY-SA".


Droits d'auteur © Fabrice Philibert-Caillat (G+) et Christophe Reboul.



Catégorie (1) Logiciel 
 
Catégorie (2) GNU Linux, Unix 
 
Évaluation 100.00 %
Contenu sous droits d'auteur — Dernière mise-à-jour : 2017-05-31 09:55:37




Commentaires


*


Anti-robot
Veuillez résoudre l'opération suivante :


* obligatoire

vendredi 18 septembre 2015 – Fabrice
Intérêt
Vous avez vraisemblablement commis une erreur. Peut-être que votre base de travail n’était pas vierge (serveurs de bases de données nouvellement installés, sans configuration spécifique) ? Ne connaissant pas votre environnement, je vérifierai si je n’aurais pas a) créé une réplication inverse sur des machines possédant déjà une réplication simple auparavant (elle aurait pu être activée dans PhpMyAdmin) ; b) inversé les rôles A et B dans l’une des étapes de configuration, en premier lieu 3.1.5. ; c) effectué par mégarde tout ou partie de la configuration présentée aux étapes 3.2.1 et 3.2.2...



jeudi 17 septembre 2015 – christophe
Intérêt
Bonjour et merci du tuto.

J'ai bien mis en place une réplication A->B avec 1 seul maitre et 1 seul esclave, et pourtant si je fait un test sur l'esclave la réplication se fait sur le maitre ! chose que je ne souhaite pas. ai-je mal fait quelque chose ? comment est-ce possible ? merci de toute aide cordialement





jeudi 02 avril 2015 – Eddy
Intérêt
ça fait déjà un bon nombre de fois que je suis revenu ici pour reprendre mes repères ou rapidement retrouver une commande.

Très instructif et très clair Excellent boulot





jeudi 07 novembre 2013 – Fabrice
Intérêt
Pour répondre à Jul : merci pour votre commentaire.

Si on souhaite que toute nouvelle base de données créée sur le serveur maître soit automatiquement répliquée, il suffit d'indiquer que la réplication concerne *toutes* les bases de données.

Pour cela, au lieu d'utiliser:

binlog-do-db=<nom de la base à répliquer>

dans la configuration du maître, il suffit d'une entrée unique avec un wildcard:

binlog-do-db=*




lundi 08 octobre 2012 – jul
Intérêt
merci pour ce tuto ça ma beaucoup aidé aussi.

par contre j'ai une question.

y a t'il une possibilité de rajouter des bases au fur et à mesure. sans avoir besoin de redémarrer MySQL.

on utilise cette solution dans nôtres société sur des serveur mutualisé web. avec pas mal de base de données. et aujourd'hui chaque ajout de base et vraiment problématique car il y a systématiquement une coupure de production ...

si jamais vous avez une idée sur la question je suis preneur. Merci pour ce tuto dans tous les cas.





mercredi 08 février 2012 – Fabrice
Intérêt
Merci pour votre message, je suis ravi d'avoir pu vous aider.



mercredi 30 novembre 2011 – Anonyme
Intérêt
Merci pour ce tuto. C'est clair. j'ai suivi à lettre et ça marche.

Bravo!!!!







Découvrez nos contenus

par catégories

par mots-clés

par dates d'ajout et de modification

Index alphabétique

Partagez vos connaissances !
Pour publier durablement et librement sur Internet, contactez-nous.





/a>