Ich bin sehr neu in der Datenbankverwaltung.
Beim Einrichten der MySQL-Master-Slave-Replikation treten viele Probleme auf.
Ich habe auch Probleme mit der regelmäßigen Fehlerbehebung bei der MySQL-Replikation.
Kann jemand helfen zu verstehen, wie ich mit all diesen umgehen soll?
Ich habe Links zu Tutorials bereitgestellt. Denken Sie daran, dass sich die Datei my.cnf unter Ubuntu in /etc/mysql/my.cnf und nicht in /etc/my.cnf befindet, wie im Tutorial howtoforge. In meinem Setup habe ich keine FLUSH TABLES WITH READ LOCK verwendet. auf den Meister. Wenn Ihr Master-Server viel Schreibaktivität hat, müssen Sie möglicherweise Ihre Tabellen sperren, indem Sie diesen Befehl ausführen, bevor Sie eine Sicherung durchführen. 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:
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 Sie Berechtigungen und erteilen Sie sie dem 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
Speichern Sie die Datenbank in einer Datei:
mysqldump -u root -p databasename > /tmp/databasename-backup.sql
Kopieren Sie den Datenbank-Dump mit scp auf den Slave-Server oder verwenden Sie ftp, wenn Sie möchten:
scp /tmp/databasename-backup.sql [email protected]:/tmp/
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;
Lauf 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 Sie richten 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 zur Verfügung stellen.
Hier ist ein Skript zum Überwachen 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
Anschließend können Sie das folgende Skript verwenden, um die Protokolldatei zu überwachen. Wenn sich das Protokoll in irgendeiner 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="[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
Zu 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 Postfix oder Sendmail installieren.
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 akzeptabel. Eine viel bessere und schnellere Möglichkeit, Slaves einzurichten, ist die Verwendung von Perconas XtraBackup . XtraBackup belastet den Master nur wenig, erfordert keine Sperren und die Wiederherstellung des Slaves ist sehr schnell. Dieser Mechanismus erzeugt einen vollständigen Klon der gesamten Datenbank, einschließlich Benutzertabellen, die einige Dinge beschädigen, die von einer Standardinstallation eingerichtet wurden, wie z. B. den Benutzer debian-sys-wart, was nicht unbedingt eine schlechte Sache ist !
Als Bonus können Sie, sobald Sie wissen, wie das geht, genau den gleichen Mechanismus für Ihre täglichen Backups verwenden. Backups sind langsamer als mysqldump, aber Wiederherstellungen sind viel schneller. Dies ist genau das, was Sie brauchen, wenn Sie in Panik sind und ein Backup wiederherstellen müssen! Wenn Sie jemals einen schwerwiegenden Replikationsfehler erhalten, 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 dann das Paket xtrabackup
sowohl auf dem Master als auch auf dem Slave installieren. Ich empfehle außerdem dringend die Verwendung des Komprimierungsdienstprogramms pigz (paralleles gzip, verfügbar in den meisten Standard-Repos), da es die Sicherungsgeschwindigkeit erheblich verbessert.
Der Vorgang läuft folgendermaßen ab (unter Ubuntu können andere Distributionen geringfügig variieren) und setzt voraus, dass Sie MySQL bereits auf Ihrem Slave installiert haben:
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 Drosselklappenwert an, um die Auswirkungen des Backups auf den Live-Service zu begrenzen.)scp -l 400000
, Um den Master der Netzwerkbandbreite für Live-Clients nicht zu hungern).service mysql stop
mv /var/lib/mysql /var/lib/mysql2
(Oder komprimieren Sie es irgendwo, wenn Sie wenig Speicherplatz haben)mkdir /var/lib/mysql; cd /var/lib/mysql
tar xvzif /path/to/backup/mysql.tgz
. Beachten Sie die Option i
für die Teeroperation - ohne sie funktioniert sie nicht . Dies dauert eine Weile, wenn Sie eine große Datenbank haben./usr/bin/innobackupex --apply-log --use-memory=6G --ibbackup=xtrabackup /var/lib/mysql
. Dadurch wird effektiv eine Absturzwiederherstellung für die Dateien aus den Binärprotokollen ausgeführt. Dies dauert nur wenige Sekunden. Verwenden Sie eine kleinere Speichermenge, wenn Sie sich auf einem kleineren Server befinden.rm /path/to/backup/mysql.tgz; chown -R mysql:mysql /var/lib/mysql
service mysql start
cat xtrabackup_binlog_info
. Es wird so etwas wie mysql-bin.000916 13889427
Sagen.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;
(Änderung entsprechend den tatsächlichen DB-Serverdetails)START SLAVE;
SHOW SLAVE STATUS\G
Dein Sklave ist jetzt fertig. Bei Bedarf können Sie jetzt die zirkuläre Replikation einrichten:
FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;
Notieren Sie den Namen und die Position der Protokolldatei (so etwas wie mysql-bin.000031 und 17244785).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 aus dem Slave, den wir uns gerade angesehen haben.START SLAVE;
UNLOCK TABLES;
Sie sollten jetzt mit einer zirkulären Replikation fertig sein.
In Bezug auf die Fehlerbehebung bietet Perconas Toolkit alle möglichen Hilfestellungen, z. B. Prüfsummen, um stille Korruption, Verzögerungsmessung und mehr zu erkennen. Die häufigsten Formen der Replikationsbeschädigung können vermieden werden, indem Sie in Ihrer my.cnf binlog_format = MIXED
Setzen. Nach meiner Erfahrung ist die Replikation jedoch im Allgemeinen nicht problematisch.