Replication Mysql master/master en utilisant Multi-Master Replication Manager

Cette page est dans les cartons depuis bien trop longtemps je profite d'un peu de disponibilité pour la mettre en ligne

Nous allons donc voir comment mettre en oeuvre un cluster MySQL haute disponibilité en utilisant une réplication master/maseter et Multi-Master Replication Manager for MySQL

L'installation sera effectuée sur une ubuntu 10.04.2 LTS lucid, elle nécessite au moins 3 machines :

• serveur MySQL 1
• serveur MySQL 2
• serveur de monitor MMM

Sur chacun des deux noeuds mysql :

apt-get install mysql-server

• ajouter sur chaque noeud la configuration suivante :
  • Noeud 1 : fichier /etc/mysql/conf.d/mysqld_master_master_1.cnf

    [mysqld]
    #bind-address = 10.41.51.163
    bind-address =0.0.0.0
    
    server-id = 1
    auto-increment-increment = 2
    auto-increment-offset = 1
    
    master-host=10.41.51.145
    master-user=replicationUser
    master-password=replicationPass
    master-port=3306
    
    #replicate-ignore-db : which database must NOT be replicated by the server as slave.
    replicate-ignore-db = mysql
    replicate-ignore-db = information_schema
    #binlog-ignore-db : specifies on which databases the binary logging must NOT be active
    binlog-ignore-db = mysql
    binlog-ignore-db = information_schema
    
    log_bin = /var/log/mysql/mysql-bin.log

  • Noeud 2 : fichier /etc/mysql/conf.d/mysqld_master_master_2.cnf

    [mysqld]
    #bind-address = 10.41.51.145
    bind-address = 0.0.0.0
    
    server-id = 2
    auto-increment-increment = 2
    auto-increment-offset = 2
    
    master-host=10.41.51.163
    master-user=replicationUser
    master-password=replicationPass
    master-port=3306
    
    #replicate-ignore-db : which database must NOT be replicated by the server as slave.
    replicate-ignore-db = mysql
    replicate-ignore-db = information_schema
    #binlog-ignore-db : specifies on which databases the binary logging must NOT be active
    binlog-ignore-db = mysql
    binlog-ignore-db = information_schema
    
    log_bin = /var/log/mysql/mysql-bin.log

• ajouter l'utilisateur de replication sur les 2 noeuds :
  • noeud 1 (IP 10.41.51.163)

    mysql> grant replication slave, replication client on *.* to 'replicationUser'@'10.41.51.145' identified by 'replicationPass';
    mysql> flush privileges;

  • noeud 2 (IP 10.41.51.145)

    mysql> grant replication slave, replication client on *.* to 'replicationUser'@'10.41.51.163' identified by 'replicationPass';
    mysql> flush privileges;

• redémarrer les services mysql sur les deux noeuds :

  /etc/inid.d/mysql restart

• On peut vérifier le status de la replication master/master à l'aide des commandes suivantes : la position sur un noeud du “show master status” doit correspondre avec Read_Master_Log_Pos obtenu sur le “show slave status” sur l'autre noeud, et vice et versa, par exemple :
  • noeud 1 :

    mysql> show master status\G
    *************************** 1. row ***************************
    File: mysql-bin.000001
    Position: 348
    Binlog_Do_DB: kikoo
    Binlog_Ignore_DB:
    1 row in set (0.00 sec)
    
    mysql> show slave status\G
    *************************** 1. row ***************************
    Slave_IO_State: Waiting for master to send event
    Master_Host: 10.41.51.145
    Master_User: replicationUser
    Master_Port: 3306
    Connect_Retry: 60
    Master_Log_File: mysql-bin.000001
    Read_Master_Log_Pos: 106
    Relay_Log_File: frtls-testmysql-1-relay-bin.000002
    Relay_Log_Pos: 251
    Relay_Master_Log_File: mysql-bin.000001
    Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
    Replicate_Do_DB: kikoo
    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: 106
    Relay_Log_Space: 418
    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)

  • noeud 2 :

    mysql> show slave status\G
    *************************** 1. row ***************************
    Slave_IO_State: Waiting for master to send event
    Master_Host: 10.41.51.163
    Master_User: replicationUser
    Master_Port: 3306
    Connect_Retry: 60
    Master_Log_File: mysql-bin.000001
    Read_Master_Log_Pos: 348
    Relay_Log_File: frtls-testmysql-2-relay-bin.000002
    Relay_Log_Pos: 493
    Relay_Master_Log_File: mysql-bin.000001
    Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
    Replicate_Do_DB: kikoo
    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: 348
    Relay_Log_Space: 660
    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)
    
    mysql> show master status ;
    +------------------+----------+--------------+------------------+
    | File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +------------------+----------+--------------+------------------+
    | mysql-bin.000001 | 106 | kikoo | |
    +------------------+----------+--------------+------------------+
    1 row in set (0.00 sec)

On dispose maintenant d'un cluster MySQL en replication Master/Master qui fonctionne

stop slave ;
CHANGE MASTER TO MASTER_USER='replicate_user' ;
start slave ;

MMM nécessite un agent sur chaque noeud MySQL et un moniteur tournant sur une machine tierce qui sert a détecter les erreurs de disponibilité et/ou réplication des noeuds, et basculer le service entre les noeuds (en utilisant une IP flottante)

Les paquets .deb sont disponibles ici

• Sur chaque noeud MySQL :
  • Installation des prérequis :

    apt-get install liblog-log4perl-perl libmailtools-perl liblog-dispatch-perl iproute libnet-arp-perl libproc-daemon-perl libalgorithm-diff-perl libdbi-perl libdbd-mysql-perl

  • Installation de mmm-agent à l'aide des paquets récupérés :

    dpkg -i mysql-mmm-common_2.2.1-1_all.deb mysql-mmm-agent_2.2.1-1_all.deb

• Sur la machine moniteur :
  • Installation des prérequis :

    apt-get install liblog-log4perl-perl libmailtools-perl liblog-dispatch-perl libclass-singleton-perl libproc-daemon-perl libalgorithm-diff-perl libdbi-perl libdbd-mysql-perl

  • Installation de mmm-monitor à l'aide des paquets récupérés : </code>dpkg -i mysql-mmm-common_2.2.1-1_all.deb mysql-mmm-monitor_2.2.1-1_all.deb</code>

• Sur chaque noeud MySQL
  • Editer le fichier /etc/mysql-mmm/mmm_agent.conf et modifier la directive “this db1” pour refléter le nom de chaque noeud (respectivement “this db1” et “this db2” sur le noeud 1 et le noeud 2 par exemple)
  • ajouter les droits mysql sur les bases pour les agents et le mmm-monitor :

    grant replication client on *.* to 'mmm_monitorUser'@'10.41.51.184' IDENTIFIED BY 'mmm_monitorPass' ;
    grant super, replication client, process on *.* to 'mmm_agentUser'@'10.41.51.163' IDENTIFIED BY 'mmm_agentPass';
    grant super, replication client, process on *.* to 'mmm_agentUser'@'10.41.51.145' IDENTIFIED BY 'mmm_agentPass';
    flush privileges ;

• Sur le moniteur, ajouter un fichier /etc/mysql-mmm/mmm_mon.conf :

  include mmm_common.conf
  
  <monitor>
  ip 127.0.0.1
  pid_path /var/run/mmm_mond.pid
  bin_path /usr/lib/mysql-mmm/
  status_path /var/lib/misc/mmm_mond.status
  ping_ips 10.41.51.254, 10.41.51.145, 10.41.51.163
  </monitor>
  
  <host default>
  monitor_user mmm_monitorUser
  monitor_password mmm_monitorPass
  </host>
  
  debug 0

• Sur toutes les machines (les 2 noeuds et le moniteur), ajouter un fichier /etc/mysql-mmm/mmm_common.conf contenant :

  active_master_role writer
  
  <host default>
  cluster_interface eth0
  
  pid_path /var/run/mmm_agentd.pid
  bin_path /usr/lib/mysql-mmm/
  
  replication_user replicationUser
  replication_password replicationPass
  
  agent_user mmm_agentUser
  agent_password mmm_agentPass
  </host>
  
  <host db1>
  ip 10.41.51.163
  mode master
  peer db2
  </host>
  
  <host db2>
  ip 10.41.51.145
  mode master
  peer db1
  </host>
  
  <role writer>
  hosts db1, db2
  ips 10.41.51.240
  mode exclusive
  </role>
  
  <role reader>
  hosts db1, db2
  ips 10.41.51.241
  mode balanced
  </role>

  où 10.41.51.240 et 10.41.51.241 sont les IPs flottantes respectives pour les roles “ecrivain” et “lecteur”. Le lecteur sera utilisé si l'application le permet pour effectuer les requêtes en lecture sur un noeud non chargé par le role d'ecrivain

• activer et demarrer tout ca :
  • sur les noeuds mysql :

    sed -i "s/ENABLED=0/ENABLED=1/" /etc/default/mysql-mmm-agent
    /etc/init.d/mysql-mmm-agent start

  • sur le monitor :

    sed -i "s/ENABLED=0/ENABLED=1/" /etc/default/mysql-mmm-monitor
    /etc/init.d/mysql-mmm-monitor start

• pour verifier que tout va bien, lancer depuis le moniteur :

  mmm_control show<code> qui doit retourner un résultat similaire à :<code>
  db1(10.41.51.163) master/AWAITING_RECOVERY. Roles:
  db2(10.41.51.145) master/AWAITING_RECOVERY. Roles:

• jusqu'ici le awaiting recovery est normal, il faut mettre les noeuds en ligne manuellement grace a la commande

  mmm_control set_online db1

• le status doit maintenant etre le suivant :

  mmm_control show
  db1(10.41.51.163) master/ONLINE. Roles: reader(10.41.51.241), writer(10.41.51.240)
  db2(10.41.51.145) master/AWAITING_RECOVERY. Roles:

• enfin activer le second noeud

  mmm_control set_online db2

• le status doit maintenant etre le suivant :

mmm_control show
db1(10.41.51.163) master/ONLINE. Roles: writer(10.41.51.240)
db2(10.41.51.145) master/ONLINE. Roles: reader(10.41.51.241)

il est possible d'utiliser la directive auto_set_online du monitor pour définir une valeur en seconde pour passer automatiquement de l'etat AWAITING_RECOVERY a l'etat ONLINE. Pour moi cette manipulation doit rester manuelle : si on en est la c'est qu'il y a eu un problème sur un des noeuds, et s'il y a eu un problème autant le réparer avant d'aller plus loin

Et voila on a un cluster mysql-mmm opérationnel : il ne reste plus qu'a y créer des bases.

• Une base de donnée crée sur l'un des nœuds est automatiquement crée sur les autres
• La creation des utilisateurs ainsi que leurs GRANT doit impérativement être effectuée sur tous les nœuds

• mysql replication master-master :
  • http://www.howtoforge.com/mysql_master_master_replication
  • http://www.neocodesoftware.com/replication/
  • http://www.lefred.be/?q=node/45
  • http://blogs.reliablepenguin.com/2011/03/27/mysql-master-master-ha-cluster
  • http://lists.mysql.com/replication/386
• monitoring :
  • http://exchange.nagios.org/components/com_mtree/attachment.php?link_id=203&cf_id=24 : check_replication.pl - Check if a MySQL slave is running (IO thread), plus check the master and server to see their current replication BINLOG positions. These are a few useful Nagios style checks we use for doing MySQL database and interface stuff. Please send comments, patches, and chocolate to: james_AT_rcpt.to.
• mysql-mmm :
  • http://kovyrin.net/2007/04/23/master-master-replication-example-using-mmm/
  • http://mysql-mmm.org/mmm2:guide
  • http://mysql-mmm.org/mysql-mmm.html#SEC12
  • http://blog.mysql-mmm.org/2009/10/mmm-nagios-plugin/
  • http://code.openark.org/blog/mysql/mmm-for-mysql-single-reader-role