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


14

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?


Quelques questions: Pourquoi avez-vous besoin de faire de la réplication, qu'essayez-vous de réaliser? Quel est le système d'exploitation de chaque ordinateur participant à la réplication? Quelle est la version de MySQL sur chaque ordinateur? Les tables MyISAM, InnoDB, sont-elles autre chose?
Craig Efrein

@CraigEfrein J'ai besoin de définir la réplication car ces serveurs doivent être utilisés en production. J'utilise Debian / ubuntu sur chaque machine. mysql5.1 comme vaersion. Les tables sont principalement InnoDB.
Abdul Manaf

Ok, je posterai une configuration que j'ai utilisée entre deux debians dans un peu. Cela suppose bien sûr que MySQL est installé sur tous les ordinateurs et qu'ils utilisent tous la même version et disposent d'un espace disque suffisant. Lorsque vous utilisez la réplication MySQL, vous devez penser à l'endroit où vous placez vos journaux de bacs, qui peuvent devenir assez gros en fonction de plusieurs facteurs. Je vais inclure cette information dans mon message
Craig Efrein

Réponses:


19

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="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.


merci beaucoup j'ai fait ça et j'ai pu mettre en place la réplication ...
Abdul Manaf

pouvez-vous me fournir le script pour surveiller la réplication.
Abdul Manaf

Juste une note rapide, le script que je viens d'ajouter est quelque chose que vous installeriez sur les serveurs esclaves. Vous pouvez l'installer sur le serveur maître, mais le journal des erreurs sur le serveur esclave sera celui qui vous intéresse le plus en fonction de votre question.
Craig Efrein

merci pour votre attention.Mais en gros, j'étais intéressé par le dépannage des erreurs de réplication, je pense que ce script surveillera les modifications du journal des erreurs pour lesquelles je le définirai
Abdul Manaf

Étant donné que votre serveur esclave ne recevra que des données et ne les mettra pas à jour, la plupart des informations enregistrées dans le journal des erreurs concerneront la réplication. Si par exemple une table sur le maître est corrompue, l'esclave ne répliquera pas la table et arrêtera essentiellement la réplication. Si vous voyez une erreur dans le journal des erreurs du serveur esclave. C'est généralement une assez bonne indication que quelque chose ne va pas avec la réplication.
Craig Efrein

7

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.


Quelle est votre allégeance?
Pacerier

Aucun, sauf en tant qu'utilisateur satisfait.
Synchro
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.