MySQL Slave-I / O-Thread nicht ausgeführt werden

Question

Ich habe Replikation für MySQL-Server einrichten. Ich kann mit dem Replikation Benutzer / Passwort auf den Master-Server von der Slave-Maschine angeschlossen werden. Ich habe den Slave-SQL-Thread läuft bekam, aber der Sklave I / O Faden ist nicht ausgeführt wird und der Slave-E / A-Status kommt als leer, wenn ‚Show Slave-Status‘ überprüft werden. Was könnte das Problem sein?

Wie kann ich dieses Problem lösen? die Slave-Neustart nicht hilft.

Dies war mein schlecht. Anstatt ein ‚Replikations-Slave‘ Privileg *.* geben, ich war nur für my_db.* geben

Answer 1

  

Statt eine ‚Replikation des Gebens   Slave‘Privileg. Ich war nur   gibt es für my_db. *.

Replication Slave ist nur ein globales Privileg (das heißt pro Benutzer nur), bedeutet dies, dass ein Befehl wie

GRANT REPLICATION SLAVE on mydb.* TO 'someuser'@'%';

hat keine Auswirkung, da Sie nicht es pro-Datenbank gewähren kann / Spalte / Tabelle.

Der Befehl Sie ausführen müssen, ist:

GRANT REPLICATION SLAVE on *.* TO 'someuser'@'%';

tun Sie dann eine START SLAVE. Man könnte es auch im MySQL-Fehlerprotokoll zu suchen.

nützlich finden

würde ich eine gute lesen vorschlagen der Replikationskonfiguration Dokumentation , wie es dies alles im Detail erklärt.

Answer 2

ich konfrontiert gleiche Problem und fixiert mit folgenden Schritten. Gewindevervollständigungs Link http://www.percona.com/forums/questions-discussions/percona-xtrabackup/11842-backup-stopped-working-slave-sql-running-no

Die Schritte sind die gleichen wie 2. von @ Luxknight007 außer seinen Schritt erwähnt jedoch dieses Themas näher enthält, die sehr hilfreich ist. Es folgt Lösung, die ich verwendet, und es funktionierte.

"Das erste Problem ist, dass Sie die Replikation Position geändert, anstatt die Fehler der Befestigung und verwendet eine falsche binlog Dateinamenformat (Sie wahrscheinlich verwendet nur die eine von dieser Stelle Sie ich denke, verknüpft würde)., Um wieder wo Sie begonnen hat, müssen Sie die binlog Datei und Position finden, dass der Slave SQL_THREAD bei gestoppt. Basierend auf dem Slave-Status-Ausgang, es sieht aus wie der Sklave von einer neuen binlog Datei zu lesen ist (kann man sehen, dass der Read_Master_Log_Pos Wert kleiner als der Exec_Master_Log_Pos Wert, das heißt, es hat eine neuere binlog Datei als in dem der Slave SQL_THREAD gestoppt at) zu lesen, so dass Sie die binlog Datei finden müssen, dass der Slave auf tatsächlich ausgefallen SQL_THREAD. so Blick in dem Fehlerprotokoll für so etwas wie die unten:

Code:

2013-10-08 12:48:51 37545 [ERROR] Slave SQL: Error 'Table 'testdb.test2' doesn't exist' on query. Default database: 'testdb'. Query: 'insert into test1 select * from test2', Error_code: 1146
2013-10-08 12:48:51 37545 [Warning] Slave: Table 'testdb.test2' doesn't exist Error_code: 1146
2013-10-08 12:48:51 37545 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000001' position 3427

Dies ist ein Beispiel ich neu erstellt, so Sie ein bisschen anders sein werden. Hinweis Der Fehler ist ähnlich dem, was Sie in Ihrem Slave-Status. So Ihre spezifische Fehlermeldung in der Fehlerprotokolldatei finden, und dann das Endteil lokalisieren, wo ist gibt Ihnen die Dateinamen und Position ( „Wir hielten an lügt‚mysql-bin.000001‘Position 3427“ in meinem Beispiel). Die Position 315098143 sollte Ihre Show Slave-Status basiert auf, wie das ist, wenn es der Slave SQL_THREAD Ausführung gestoppt Ereignisse (Exec_Master_Log_Pos), aber die io_thread gehalten in neue zu lesen (Read_Master_Log_Pos).

Wenn Sie die richtigen binlog Dateinamen und Position zu finden, wieder läuft Ihren Änderungsstamm Anweisung auf Ihrem Slave mit den Informationen, die Sie im Fehlerprotokoll befinden. Beachten Sie, dass Sie den Dateinamen so etwas wie „newcrmdb1-bin.XXXXXX“ sein sollte, nicht mysql-bin.XXXXXX (können Sie diese Namenskonvention Ihrer Show Slave-Status siehe oben).

Code:

mysql> change master to MASTER_LOG_FILE='newcrmdb1-bin.XXXXXX', Master_Log_Pos=315098143;

change master to MASTER_LOG_FILE='mysql-bin.000082' , Master_Log_Pos=47914844;

Wenn Sie spitzen wieder auf den ursprünglichen Replikations Standort zu erhalten, wo die Slave SQL_THREAD ausgefallen ist, müssen Sie dann den Fehler beheben, dass es etwa beschwerte sich, mit zu beginnen.

Die erste Replikation Fehler angezeigt Sie werden sagen, dass die Tabelle asteriskcdr.bpleadcf nicht auf dem Slave nicht vorhanden ist, so dass die Insert-Anweisung fehlschlägt, wenn es versucht, die Daten aus der Tabelle auszuwählen. So das Problem ist, dass Ihre Slave-out bereits synchron mit dem Master zu sein scheint. Wenn die betreffende Tabelle auf dem Master statisch ist oder meist statisch, könnten Sie wahrscheinlich dieses Problem lösen, indem die Daten von nur, dass Tabelle Export auf dem Master mit mysqldump und Laden es in den Slave. Wenn das nicht möglich ist, oder Sie kümmern sich nicht um diese Daten, können Sie immer, lassen Sie die Replikation Anweisung mit SQL_SLAVE_SKIP_COUNTER, aber dann würde der Slave weiter sein nicht synchron mit dem Master.

Und wenn alle Stricke reißen, können Sie immer den Slave vom Master als letztes Mittel auch wieder aufzubauen. =) "

Answer 3

Ich habe das gleiche Problem gestoßen, und ich versuche diese Schritte

Zuerst diesen Code irgendwo unter [mysqld] fügen Sie in my.cnf oder my.ini slave-skip-errors=1046 Dies wird alle doppelten Eintrag überspringen, da wir die ganze Binärlogdatei ausgeführt werden, wo die Replikation beenden, Sie nach erfolgreicher Replikation dieses Code Stellung nehmen können.

1.STOP SLAVE;

2. Rücksetzen SLAVE;

3.Ändern MASTER TO MASTER_LOG_FILE = 'mysql-bin.000049';

Note: MASTER_LOG_FILE must be the last file where it stop from replicating

4.Change MASTER TO MASTER_LOG_POS = 98;

5.Start SLAVE;

Überprüfen Sie, ob Sie sind erfolgreich