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

Question

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 rencontre également des problèmes de dépannage de réplication mysql réguliers.

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

Craig Efrein · Accepted Answer

J'ai fourni des liens vers des tutoriels. Gardez simplement à l'esprit que sur Ubuntu, le fichier my.cnf est 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;

Courir 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 configurer 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 avez correctement installé cette configuration, 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="addressemail@something.com" # 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.

Synchro · Answer

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 manière 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 verrouillage 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 tels que les tables d'utilisateurs, ce qui cassera 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, c'est exactement 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 repo apt/yum de Percona pour votre distribution, puis installer le package xtrabackup 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 cela 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:

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)
Copiez le fichier de sauvegarde sur l'esclave (utilisez scp -l 400000 afin de ne pas affamer le maître de la bande passante réseau pour les clients actifs)
Arrêtez mysql sur l'esclave: service mysql stop
É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)
Créez un nouveau répertoire de données et accédez-y: mkdir /var/lib/mysql; cd /var/lib/mysql
Décompressez le fichier de sauvegarde dans le nouveau dossier: tar xvzif /path/to/backup/mysql.tgz. Notez l'option i sur l'opération tar - cela ne fonctionnera pas sans elle . Cela prendra un certain temps si vous avez une grosse base de données.
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.
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
Démarrez mysql: service mysql start
Obtenez le nom du fichier journal principal et la position de la sauvegarde (notez PAS les informations dans xtrabackup_slave_info): cat xtrabackup_binlog_info. Il dira quelque chose comme mysql-bin.000916 13889427
Connectez-vous à MySQL et vérifiez que tout est là.
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)
Redémarrez l'esclave: START SLAVE;
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:

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).
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 voir.
Sur le maître: START SLAVE;
Sur l'esclave: UNLOCK TABLES;

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

En ce qui concerne le dépannage, boîte à outils de Percona a toutes sortes de choses pour aider comme 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 = MIXED dans votre my.cnf. Cela dit, d'après mon expérience, la réplication n'est généralement pas gênante.