Quelle est la meilleure façon de créer la configuration de la réplication maître-esclave MySQL et de la résoudre?

Je suis très nouveau dans l'administration des bases de données.

Je fais face à beaucoup de problèmes lors de la configuration de la réplication maître-esclave mysql.

Je suis également confronté à des problèmes de résolution de problèmes de réplication mysql.

Quelqu'un peut-il aider à comprendre comment dois-je gérer tout cela?

J'ai fourni des liens vers des tutoriels. N'oubliez pas que sur Ubuntu, le fichier my.cnf se trouve dans /etc/mysql/my.cnf et non dans /etc/my.cnf comme dans le tutoriel howtoforge. Dans ma configuration, je n'ai pas utilisé de TABLEAUX DE RINÇAGE AVEC VERROUILLAGE EN LECTURE; sur le maître. Si votre serveur maître a beaucoup d'activité d'écriture, vous devrez peut-être verrouiller vos tables en exécutant cette commande avant de sauvegarder. Si vous utilisez FLUSH TABLES WITH READ LOCK ;, puis après votre sauvegarde, vous voudrez exécuter UNLOCK TABLES. Si vous rencontrez des problèmes, faites-le moi savoir.

Voici le tutoriel que j'ai trouvé sur la façon de forger, fait pour Redhat / CentOS: http://www.howtoforge.com/mysql_database_replication

Un autre tutoriel qui semblait correct pour Ubuntu http://www.srcnix.com/2010/10/14/simple-mysql-replication-with-ubuntu-master-to-slave/

Voici la configuration que j'ai utilisée:

Sur le serveur MASTER

Configurez le serveur maître:

vi /etc/mysql/my.cnf

[mysqld]

# bind-address = 127.0.0.1 (comment this out)
server_id           = 1
log_bin             = /var/log/mysql/mysql-bin.log
log_bin_index       = /var/log/mysql/mysql-bin.log.index
max_binlog_size     = 100M
expire_logs_days    = 1

Redémarrez MySQL:

/etc/init.d/mysql restart

Connectez-vous à la console de mysql: mysql -u root -ppassword

Créez et accordez des autorisations à l'utilisateur de la réplication.

GRANT REPLICATION SLAVE ON *.* TO 'replication'@'ipaddressofslave' IDENTIFIED BY 'replicationuserpassword';

Assurez-vous de copier ces informations quelque part ou de les laisser visibles

SHOW MASTER STATUS \G;
mysql> show master status \G;
            File: mysql-bin.000001
        Position: 100
    Binlog_Do_DB: 
Binlog_Ignore_DB:

mysql> quit 

Vider la base de données dans un fichier:

mysqldump -u root -p databasename > /tmp/databasename-backup.sql

Copiez le vidage de la base de données sur le serveur esclave à l'aide de scp ou utilisez ftp si vous le souhaitez:

scp /tmp/databasename-backup.sql root@ipaddressofslave:/tmp/

Sur le serveur SLAVE

Modifiez la configuration mysql:

vi /etc/mysql/my.cnf
[mysqld]

# slave server configuration
server_id           = 2

# this is optional, but I find it useful to specify where the relay logs go to control.  
# Don't forget to create the /var/log/mysql directory and give mysql rights to it.  
# chown mysql:mysql -R /var/log/mysql
# disk space
relay_log           = /var/log/mysql/mysql-relay-bin
relay_log_index     = /var/log/mysql/mysql-relay-bin.index
relay_log_space_limit = 2000M

Redémarrez MySQL: /etc/init.d/mysql restart

Restaurez la sauvegarde:

mysql -u root -ppassword nameofthedatabase < /tmp/databasename-backup.sql

Connectez-vous à MySQL:

mysql -u root -ppassword

stop slave;

# master log file and master_log_pos taken from show master status above
CHANGE MASTER TO master_host='ipaddressmaster', master_port=3306, master_user='replication', master_password='replicationuserpassword', master_log_file='mysql-bin.000001', master_log_pos=100;

start slave;

Exécuter SHOW SLAVE STATUS\G:

mysql> show slave status\G;
             Slave_IO_State: Waiting for master to send event
                Master_Host: ipaddressmaster
                Master_User: replication
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.0000001
        Read_Master_Log_Pos: 100
             Relay_Log_File: mysql-relay-bin.000001
              Relay_Log_Pos: 1
      Relay_Master_Log_File: mysql-bin.000001
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB: 
        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: 17324288
            Relay_Log_Space: 17324425
            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
1 row in set (0.02 sec)

Ensuite, gardez à l'esprit que la réplication peut échouer pour diverses raisons. Sur l'esclave, vous pouvez surveiller l'état en exécutant la commande SHOW SLAVE STATUS \ G; Ou en configurant une tâche cron pour surveiller l'état et envoyer des e-mails en cas d'échec. Familiarisez-vous avec la sortie de cette commande. Si la réplication s'exécute correctement, vous devriez voir "Slave_IO_State: Attendre que le maître envoie l'événement".

Une fois que vous obtenez cette configuration correctement, je peux vous fournir un script pour surveiller cette réplication.

Voici un script pour surveiller le journal des erreurs dans MySQL. Si vous ajoutez la ligne

[mysqld]

log-error = /var/log/mysql/mysql.err

redémarrez mysql: /etc/init.d/mysql restart

Ensuite, vous pouvez utiliser le script suivant pour surveiller le fichier journal. Si le journal change de quelque façon que ce soit, vous recevrez un e-mail vous informant qu'une erreur s'est produite sur le serveur esclave. Si vous souhaitez que le journal des erreurs soit vérifié régulièrement, vous devrez ajouter ce script à votre crontab.

Voici un exemple de script: /somepath/monitor_mysql_log.sh

#! /bin/sh
MAIL_TO="[email protected]"

# This is the log that will be monitored.
# If any changes occur to this, then take appropriate action.
MONITORED_LOG=/var/log/mysql/mysql.err

# We will need this log to see whether any changes occured to /tmp/goreb.log
TEMP_LOG=/tmp/.mysql.err.1

# This is a 1-time command i.e. create the log file if it does nto exist.
[ ! -f $TEMP_LOG ] && touch -r $MONITORED_LOG $TEMP_LOG

[ $MONITORED_LOG -nt $TEMP_LOG ] && echo "an error occurred in mysql" | mail -s "Error on MySQL" $MAILTO

# Update $TEMP_LOG with the new modified date of $MONITORED_LOG
touch -r $MONITORED_LOG $TEMP_LOG

Pour ajouter à crontab.

Rendez le script exécutable:

chmod +x /somepath/monitor_mysql_log.sh

Mettre à jour crontab:

crontab -e

* * * * * /somepath/monitor_mysql_log.sh

Et le script sera exécuté toutes les minutes.

Le script que j'ai fourni est un script que j'ai rapidement assemblé. De plus, pour que votre serveur puisse envoyer des e-mails, vous devez installer quelque chose comme postfix ou sendmail.

Mysqldump est rapide, mais la restauration des vidages peut être très lente pour une grande base de données, et le verrouillage des tables n'est pas acceptable sur un site en direct. Une façon bien meilleure et plus rapide de configurer des esclaves est d'utiliser XtraBackup de Percona . XtraBackup impose peu de charge au maître, ne nécessite aucun verrou et la restauration sur l'esclave est très rapide. Ce mécanisme produit un clone complet de toute la base de données, y compris des éléments comme les tables d'utilisateurs, qui cassent certaines choses qui sont configurées par une installation en stock, comme l'utilisateur debian-sys-maint, ce qui n'est pas nécessairement une mauvaise chose !

En prime, une fois que vous savez faire cela, vous pouvez utiliser exactement le même mécanisme pour vos sauvegardes quotidiennes. Les sauvegardes sont plus lentes que mysqldump, mais les restaurations sont bien plus rapides, ce dont vous avez besoin si vous êtes dans une situation de panique et que vous devez restaurer une sauvegarde! Si jamais vous obtenez une erreur de réplication majeure, utilisez simplement cette procédure pour jeter l'esclave et le reconstruire; ça ne prend vraiment pas longtemps.

Vous devrez configurer le repo apt / yum de Percona pour votre distribution, puis installer le xtrabackuppackage sur le maître et l'esclave. Je recommande également fortement l'utilisation de l' utilitaire de compression pigz (gzip parallèle, disponible dans la plupart des référentiels standard) car il fait une énorme différence sur la vitesse de sauvegarde.

Le processus se déroule comme ceci (sur Ubuntu, les autres distributions peuvent varier légèrement), et suppose que vous avez déjà installé MySQL sur votre esclave:

1. Tout d'abord, effectuez une sauvegarde sur le maître: mkdir -p /var/xtrabackup; /usr/bin/innobackupex --slave-info --stream=tar --throttle=1500 /var/xtrabackup 2> /tmp/xtrabackup.out | /usr/bin/pigz -p 4 -c --best -q > /var/backups/mysql.tgz(ajustez la valeur de limitation pour limiter l'impact de la sauvegarde sur le service en direct)
2. Copiez le fichier de sauvegarde sur l'esclave (à utiliser scp -l 400000pour ne pas affamer le maître de la bande passante réseau pour les clients actifs)
3. Arrêtez mysql sur l'esclave: service mysql stop
4. Éloignez l'ancien répertoire de données MySQL: mv /var/lib/mysql /var/lib/mysql2(ou compressez-le quelque part si vous manquez d'espace disque)
5. Créez un nouveau répertoire de données et accédez-y: mkdir /var/lib/mysql; cd /var/lib/mysql
6. Décompressez le fichier de sauvegarde dans le nouveau dossier: tar xvzif /path/to/backup/mysql.tgz. Notez l' ioption sur l'opération tar - elle ne fonctionnera pas sans elle . Cela prendra un certain temps si vous avez une grosse base de données.
7. Exécutez l'outil Innobackupex sur les fichiers extraits: /usr/bin/innobackupex --apply-log --use-memory=6G --ibbackup=xtrabackup /var/lib/mysql. Cela exécute efficacement une récupération après incident sur les fichiers à partir des journaux binaires. Cela ne prend que quelques secondes; utilisez une plus petite quantité de mémoire si sur un serveur plus petit.
8. En supposant que cela se termine avec succès, supprimez la sauvegarde et définissez la propriété des fichiers: rm /path/to/backup/mysql.tgz; chown -R mysql:mysql /var/lib/mysql
9. Démarrez mysql: service mysql start
10. Obtenez le nom du fichier journal maître et la position de la sauvegarde (note pas l'information en xtrabackup_slave_info): cat xtrabackup_binlog_info. Cela dira quelque chose commemysql-bin.000916 13889427
11. Connectez-vous à MySQL et vérifiez que tout est là.
12. Réinitialisez les paramètres de réplication en utilisant les détails que vous avez obtenus sur les journaux: CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='replica', MASTER_PASSWORD='r3plica', MASTER_LOG_FILE='mysql-bin.000916', MASTER_LOG_POS=13889427;(Modifier pour correspondre aux détails réels du serveur DB)
13. Redémarrez l'esclave: START SLAVE;
14. Vérifiez l'état de l'esclave lorsqu'il rattrape le maître jusqu'à ce que 'seconds_behind_master' soit 0: SHOW SLAVE STATUS\G

Votre esclave est maintenant prêt. Si nécessaire, vous pouvez maintenant configurer la réplication circulaire:

1. Sur l'esclave: FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;notez le nom et la position du fichier journal (quelque chose comme mysql-bin.000031 et 17244785).
2. Sur le maître CHANGE MASTER TO MASTER_HOST='192.168.0.2', MASTER_USER='replica', MASTER_PASSWORD='r3plica', MASTER_LOG_FILE='mysql-bin.000031', MASTER_LOG_POS=17244785;:, en insérant des valeurs de l'esclave que nous venons de regarder.
3. Sur le maître: START SLAVE;
4. Sur l'esclave: UNLOCK TABLES;

Vous devriez maintenant être prêt pour une réplication circulaire.

En ce qui concerne le dépannage, la boîte à outils de Percona a toutes sortes de choses à aider, telles que la somme de contrôle pour détecter la corruption silencieuse, la mesure du retard et plus encore. Les formes les plus courantes de corruption de réplication peuvent être évitées en définissant binlog_format = MIXEDvotre my.cnf. Cela dit, d'après mon expérience, la réplication n'est généralement pas gênante.