Was ist der beste Weg, um ein MySQL Master-Slave-Replikations-Setup zu erstellen und Fehler zu beheben?


14

Ich bin sehr neu in der Datenbankverwaltung.

Beim Einrichten der MySQL-Master-Slave-Replikation treten viele Probleme auf.

Ich habe auch mit regelmäßigen Problemen bei der Fehlerbehebung bei der MySQL-Replikation zu kämpfen.

Kann jemand helfen zu verstehen, wie ich mit all diesen umgehen soll?


Ein paar Fragen: Warum müssen Sie replizieren, was wollen Sie erreichen? Welches Betriebssystem hat jeder Computer, der an der Replikation teilnimmt? Was ist die Version von MySQL auf jedem Computer? Sind die Tabellen MyISAM, InnoDB noch etwas anderes?
Craig Efrein

@CraigEfrein Ich muss die Replikation einstellen, da diese Server in der Produktion verwendet werden sollen. Ich verwende Debian / Ubuntu auf jeder Maschine. mysql5.1 als vaersion.Primärtabellen sind InnoDB.
Abdul Manaf

Ok, ich werde gleich eine Konfiguration veröffentlichen, die ich zwischen zwei Debians verwendet habe. Dies setzt natürlich voraus, dass Sie MySQL auf allen Computern installiert haben und dass alle dieselbe Version verwenden und über ausreichend Speicherplatz verfügen. Wenn Sie die MySQL-Replikation verwenden, müssen Sie sich überlegen, wo Sie Ihre Bin-Protokolle ablegen. Dies kann in Abhängigkeit von mehreren Faktoren recht umfangreich werden. Ich werde diese Informationen in meinen Beitrag aufnehmen
Craig Efrein

Antworten:


19

Ich habe Links zu Tutorials bereitgestellt. Beachten Sie jedoch, dass sich die Datei my.cnf unter Ubuntu in /etc/mysql/my.cnf und nicht wie im Tutorial in /etc/my.cnf befindet. In meinem Setup habe ich FLUSH TABLES WITH READ LOCK nicht verwendet. auf den Meister. Wenn Ihr Masterserver über viele Schreibaktivitäten verfügt, müssen Sie möglicherweise Ihre Tabellen sperren, indem Sie diesen Befehl ausführen, bevor Sie eine Sicherungskopie erstellen. Wenn Sie FLUSH TABLES WITH READ LOCK verwenden, möchten Sie nach der Sicherung UNLOCK TABLES ausführen. Wenn Sie auf Probleme stoßen, lassen Sie es mich wissen.

Hier ist das Tutorial, das ich in Howto Forge für Redhat / CentOS gefunden habe: http://www.howtoforge.com/mysql_database_replication

Ein weiteres Tutorial, das für Ubuntu in Ordnung aussah http://www.srcnix.com/2010/10/14/simple-mysql-replication-with-ubuntu-master-to-slave/

Hier ist die Konfiguration, die ich verwendet habe:

Auf dem MASTER Server

Konfigurieren Sie den Master-Server:

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

Starten Sie MySQL neu:

/etc/init.d/mysql restart

Stellen Sie eine Verbindung zur Konsole von mysql her: mysql -u root -ppassword

Erstellen und erteilen Sie Berechtigungen für den Replikationsbenutzer.

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

Stellen Sie sicher, dass Sie diese Informationen irgendwo kopieren oder sichtbar lassen

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

mysql> quit 

Dump die Datenbank in eine Datei:

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

Kopieren Sie den Datenbankspeicherauszug mit scp auf den Slave-Server oder verwenden Sie ftp, wenn Sie möchten:

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

Auf dem SLAVE Server

Bearbeiten Sie die MySQL-Konfiguration:

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

Starten Sie MySQL neu: /etc/init.d/mysql restart

Stellen Sie die Sicherung wieder her:

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

Stellen Sie eine Verbindung zu MySQL her:

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;

Ausführen 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)

Beachten Sie anschließend, dass die Replikation aus verschiedenen Gründen fehlschlagen kann. Auf dem Slave können Sie den Status überwachen, indem Sie den Befehl SHOW SLAVE STATUS \ G ausführen. Oder richten Sie einen Cron-Job ein, um den Status zu überwachen und E-Mails zu senden, wenn dies fehlschlägt. Machen Sie sich mit der Ausgabe dieses Befehls vertraut. Wenn die Replikation ordnungsgemäß ausgeführt wird, sollte "Slave_IO_State: Warten auf das Senden des Ereignisses durch den Master" angezeigt werden.

Sobald Sie dieses Setup korrekt erhalten haben, kann ich Ihnen ein Skript zur Überwachung dieser Replikation bereitstellen.

Hier ist ein Skript zur Überwachung des Fehlerprotokolls in MySQL. Wenn Sie die Zeile hinzufügen

[mysqld]

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

Starten Sie mysql neu: /etc/init.d/mysql restart

Dann können Sie das folgende Skript verwenden, um die Protokolldatei zu überwachen. Wenn sich das Protokoll auf irgendeine Weise ändert, erhalten Sie eine E-Mail, in der Sie darüber informiert werden, dass auf dem Slave-Server ein Fehler aufgetreten ist. Wenn Sie möchten, dass das Fehlerprotokoll regelmäßig überprüft wird, müssen Sie dieses Skript zu Ihrer crontab hinzufügen.

Hier ist ein Beispielskript: /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

Crontab hinzufügen.

Machen Sie das Skript ausführbar:

chmod +x /somepath/monitor_mysql_log.sh

Crontab aktualisieren:

crontab -e

* * * * * /somepath/monitor_mysql_log.sh

Und das Skript wird jede Minute ausgeführt.

Das Skript, das ich bereitgestellt habe, ist ein Skript, das ich gerade schnell zusammengestellt habe. Damit Ihr Server E-Mails senden kann, müssen Sie außerdem etwas wie Postfix oder Sendmail installieren.


Vielen Dank, das hat mir gefallen und ich konnte die Replikation einrichten ...
Abdul Manaf

Können Sie mir das Skript zur Überwachung der Replikation zur Verfügung stellen?
Abdul Manaf

Nur eine kurze Anmerkung, das Skript, das ich gerade hinzugefügt habe, ist etwas, das Sie auf den Slave-Servern installieren würden. Sie könnten es auf dem Master-Server installieren, aber das Fehlerprotokoll auf dem Slave-Server ist dasjenige, das Sie aufgrund Ihrer Frage am meisten interessiert.
Craig Efrein

Vielen Dank für Ihre Aufmerksamkeit. Aber im Grunde war ich an der Behebung von Replikationsfehlern interessiert. Ich denke, dieses Skript wird die Änderungen des Fehlerprotokolls überwachen, für das ich es festlegen werde.
Abdul Manaf

Da Ihr Slave-Server nur Daten empfängt und nicht aktualisiert, handelt es sich bei den meisten im Fehlerprotokoll aufgezeichneten Informationen um Replikation. Wenn beispielsweise eine Tabelle auf dem Master beschädigt wird, repliziert der Slave die Tabelle nicht und beendet im Wesentlichen die Replikation. Wenn Sie einen Fehler im Fehlerprotokoll des Slave-Servers sehen. Es ist normalerweise ein ziemlich guter Hinweis darauf, dass etwas mit der Replikation nicht stimmt.
Craig Efrein

7

Mysqldump ist schnell, aber das Wiederherstellen von Dumps kann für eine große Datenbank sehr langsam sein, und das Sperren von Tabellen ist auf einer Live-Site nicht zulässig. Eine viel bessere und schnellere Methode zum Einrichten von Slaves ist die Verwendung von Perconas XtraBackup . XtraBackup belastet den Master nur wenig, erfordert keine Sperren und die Wiederherstellung auf dem Slave ist sehr schnell. Dieser Mechanismus erzeugt einen vollständigen Klon der gesamten Datenbank, einschließlich Benutzertabellen, die einige Dinge zerstören, die durch eine Standardinstallation eingerichtet wurden, wie z. B. der Benutzer debian-sys-maint, was nicht unbedingt eine schlechte Sache ist !

Als Bonus können Sie genau den gleichen Mechanismus für Ihre täglichen Sicherungen verwenden, sobald Sie wissen, wie dies gemacht wird. Backups sind langsamer als mysqldump, aber Wiederherstellungen sind viel schneller. Dies ist genau das, was Sie brauchen, wenn Sie in einer Situation sind, in der Sie in Panik geraten und ein Backup wiederherstellen müssen! Wenn jemals ein schwerwiegender Replikationsfehler auftritt, verwenden Sie einfach dieses Verfahren, um den Slave in den Papierkorb zu werfen und neu zu erstellen. es dauert wirklich nicht lange.

Sie müssen Perconas Apt / Yum Repo für Ihre Distribution einrichten und das xtrabackupPaket dann auf Master und Slave installieren . Ich empfehle außerdem nachdrücklich die Verwendung des Pigz- Komprimierungsdienstprogramms (paralleles gzip, das in den meisten Standard-Repos verfügbar ist), da dies einen großen Unterschied zur Backup-Geschwindigkeit darstellt.

Der Prozess läuft wie folgt ab (unter Ubuntu können andere Distributionen geringfügig abweichen) und setzt voraus, dass Sie MySQL bereits auf Ihrem Slave installiert haben:

  1. Erstellen Sie zunächst eine Sicherungskopie auf dem Master: 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(Passen Sie den Drosselungswert an, um die Auswirkungen der Sicherungskopie auf den Live-Dienst zu begrenzen.)
  2. Kopieren Sie die Sicherungsdatei auf den Slave (verwenden Sie scp -l 400000diese Option, um den Master nicht an Netzwerkbandbreite für Live-Clients zu verlieren).
  3. Stoppen Sie MySQL auf dem Slave: service mysql stop
  4. Verschieben Sie das alte MySQL-Datenverzeichnis aus dem Weg: mv /var/lib/mysql /var/lib/mysql2(oder komprimieren Sie es irgendwo, wenn Sie wenig Speicherplatz haben)
  5. Erstelle ein neues Datenverzeichnis und verschiebe es: mkdir /var/lib/mysql; cd /var/lib/mysql
  6. Entpacken Sie die Backup - Datei in den neuen Ordner: tar xvzif /path/to/backup/mysql.tgz. Beachten Sie dasi Option für die Teer-Operation - ohne sie wird es nicht funktionieren . Dies dauert eine Weile, wenn Sie eine große Datenbank haben.
  7. Führen Sie das Innobackupex-Tool für die extrahierten Dateien aus: /usr/bin/innobackupex --apply-log --use-memory=6G --ibbackup=xtrabackup /var/lib/mysql . Dies führt effektiv eine Absturzwiederherstellung für die Dateien aus den Binärprotokollen durch. Dies dauert nur wenige Sekunden. Verwenden Sie auf einem kleineren Server einen kleineren Speicher.
  8. Wenn dies erfolgreich abgeschlossen wurde, löschen Sie die Sicherung und legen den Besitz der Dateien fest: rm /path/to/backup/mysql.tgz; chown -R mysql:mysql /var/lib/mysql
  9. Starten Sie MySQL: service mysql start
  10. Holen Sie sich die Master - Protokolldateinamen und die Position der Backup (Note NICHT die Informationen in xtrabackup_slave_info): cat xtrabackup_binlog_info. Es wird so etwas sagenmysql-bin.000916 13889427
  11. Stellen Sie eine Verbindung zu MySQL her und überprüfen Sie, ob das Zeug da ist.
  12. Setzen Sie die Replikationseinstellungen mit den Details , die Sie über die Protokolle einsehen: 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;(Change übereinstimmen Details echten DB - Server)
  13. Starten Sie den Slave neu: START SLAVE;
  14. Überprüfen Sie den Status des Slaves, während dieser den Master einholt, bis 'seconds_behind_master' den Wert 0 hat: SHOW SLAVE STATUS\G

Dein Sklave ist jetzt fertig. Bei Bedarf können Sie jetzt die Umlaufreplikation einrichten:

  1. Auf dem Sklaven: FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS; Notieren Sie den Namen und die Position der Protokolldatei (etwa mysql-bin.000031 und 17244785).
  2. Auf dem Meister: 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; Einfügen von Werten vom Slave, den wir uns gerade angesehen haben.
  3. Auf dem Meister: START SLAVE;
  4. Auf dem Sklaven: UNLOCK TABLES;

Sie sollten jetzt alle mit einer Umlaufreplikation festgelegt werden.

Was die Fehlerbehebung angeht , bietet das Percona-Toolkit eine Vielzahl von Hilfsmitteln, wie beispielsweise Prüfsummen zur Erkennung stiller Korruption, Verzögerungsmessungen und mehr. Die häufigsten Formen der Replikationsbeschädigung können vermieden werden, indem Sie binlog_format = MIXEDin Ihrer my.cnf festlegen. Nach meiner Erfahrung ist die Replikation jedoch nicht generell problematisch.


Was ist Ihre Treue?
Pacerier

Keine, außer als zufriedener Benutzer.
Synchro
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.