Un esclave, plusieurs maîtres MySql

Est-il possible de configurer MySql Replication pour qu'un seul esclave écoute deux maîtres différents?

De par sa conception, un processus mysqld ne peut pas écouter simultanément deux maîtres différents.

La commande CHANGE MASTER TO vous permet uniquement de définir un maître comme source à lire.

Pour émuler cela, vous devez alterner les deux maîtres par programme. Comment tu fais ça ?

J'ai décrit dans StackOverflow comment connecter un esclave manuellement à différents maîtres où chaque maître était un ordinateur portable et l'esclave était un ordinateur central.

Voici l'idée de base

• Master M1
• Master M2
• Esclave S1

Configuration de la réplication de M1 vers S1 puis de M2 ​​vers S1 comme ceci

• 1) Demandez à S1 d'exécuter CHANGE MASTER TO avec M1 comme source
• 2) DÉMARRER ESCLAVE;
• 3) Exécutez la réplication pendant un petit moment
• 4) ARRÊT ESCLAVE;
• 5) Demandez à S1 d'exécuter CHANGE MASTER TO avec M2 comme source
• 6) DÉMARRER ESCLAVE;
• 7) Exécutez la réplication pendant un petit moment
• 8) ARRÊT ESCLAVE;
• 9) Retournez à l'étape 1

Chaque fois que vous passez d'un Master à un autre, vous devez enregistrer deux valeurs de SHOW SLAVE STATUS\G

1. Relay_Master_Log_file
2. Exec_Master_Log_Pos

Ces deux valeurs représentent la dernière instruction SQL qui provenait du maître et qui devait ensuite être exécutée sur l'esclave.

Il y a une grande prudence: tant que M1 et M2 mettent à jour des bases de données s'excluant mutuellement, cet algorithme devrait très bien fonctionner.

Croyez-le ou non, j'ai posé une question comme celle-ci dans ServerFault en mai 2011. J'ai en fait expliqué comment émuler un véritable esclave multimaître / simple en utilisant le moteur de stockage BLACKHOLE basé sur le livre "High Performance MySQL".

La solution de Rolando comporte de nombreuses mises en garde. Le premier étant un flux de réplique ne se réplique pas nécessairement tandis que l'autre fonctionne. Cela vous donnera des périodes où votre esclave n'est pas synchronisé. Vous devez maintenant jouer un délicat exercice d'équilibre pour vous assurer que chacun a suffisamment de temps pour rattraper son retard.

Comme décrit, vous devez également jouer à la tenue de livre des positions de journal pour revenir à. Cela semble vraiment bogué, ouvrant la fenêtre pour les données manquantes ou incohérentes ou même interrompant la réplication quand elle ne va pas (soit causée par une erreur, même `` off by one '' dans la position du journal)

Je recommanderais simplement d'exécuter plusieurs instances mysql. Rien ne vous empêche d'exécuter deux ou plusieurs mysql sur la même machine. Bien entendu, ils ne peuvent pas tous deux fonctionner sur le même port. Je ne vois pas vraiment cela comme un problème, car chaque client et bibliothèque vous permet de spécifier autre chose que 3306.

Spécifiez simplement le port = 3307 (ou quoi que ce soit dans l'un des fichiers .cnf).

Vous devrez également prendre soin de vous assurer que les pools de mémoire tampon configurés individuellement et les autres configurations de mémoire ne sont pas en contradiction les uns avec les autres. Il s'agit en fait d'un avantage, car vous pouvez ajuster plus finement ces paramètres aux exigences spécifiques des bases de données individuelles qui sont répliquées.

De cette façon, vous n'avez que deux flux de réplication exécutés sur le même serveur; jamais derrière, aucune tenue de livre requise, aucun script de "swapping" requis.

Fan in (réplication multi-source) sera pris en charge à partir de MySQL 5.7.

Une version des laboratoires est disponible ici: http://labs.mysql.com/

MariaDB qui peut être utilisé comme remplacement sur place de MySql peut être utilisé. Il le prend en charge à partir de la version 10.2

Le problème avec la prise en charge de Mysql 5.7 est la nécessité de GTID, ce qui signifie que le maître DOIT également être changé, dans le cas de MariaDb, ce n'est pas le cas.

Exemple / lien HowTo: http://www.skysql.com/blogs/dean-ellis/multi-source-replication-mariadb-100