MySQL-Replikation erfolgreich, aber Slave nicht repliziert

8

Ich habe eine MySQL-Master-Slave-Konfiguration erstellt und die Dinge sehen gut aus. der "show master status"; auf Slave zeigt keinen Fehler an. Dies ist die Ausgabe

 Slave_IO_State: Waiting for master to send event
                  Master_Host: 109.123.100.58
                  Master_User: replica
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 106
               Relay_Log_File: relay-bin.000001
                Relay_Log_Pos: 4
        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: 106
              Relay_Log_Space: 106
              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
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error:

Bei der Replikation auf dem Slave scheint dies jedoch nicht zu geschehen, wenn der Master geändert wird

Auf Meister. MASTER STATUS ZEIGEN

+------------------+----------+--------------+-------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB        |
+------------------+----------+--------------+-------------------------+
| mysql-bin.000001 |   639495 |              | mysql,informationschema |
+------------------+----------+--------------+-------------------------+

auf Slave SHOW PROCESSLIST ergibt

+-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------+------------------+
| Id  | User        | Host      | db   | Command | Time  | State                                                                 | Info             |
+-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------+------------------+
| 174 | system user |           | NULL | Connect | 25777 | Waiting for master to send event                                      | NULL             |
| 175 | system user |           | NULL | Connect | 25777 | Has read all relay log; waiting for the slave I/O thread to update it | NULL             |
| 199 | root        | localhost | NULL | Query   |     0 | NULL                                                                  | show processlist |
+-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)

Vermisse ich etwas?

mysql replication

— Soja
quelle

Zwei Fragen. Haben Sie die gleiche Version von MySQL auf Master und Slave? Haben Sie in der Konfiguration eine andere Server-ID für den Master / Slave festgelegt? edit: können wir auch das volle sehen SHOW MASTER STATUS, das oberste bit fehlt meiner denke nach.

Entschuldigung, mein Fehler, das oberste Bit war die Ausgabe für SHOW SLAVE STATUS \ G. Master-Status für Slave-Ausbeuten anzeigen + ------------------ + ---------- + ------------- - + ------------------------- + | Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB | + ------------------ + ---------- + -------------- + ---- --------------------- + | mysql-bin.000004 | 106 | | MySQL, Informationsschema | + ------------------ + ---------- + -------------- + ---- --------------------- +

— Soyeed

Schau nicht SHOW MASTER STATUSauf den Sklaven . Diese Informationen sind nur relevant, wenn der Slave auch als Master für andere weiter stromabwärts gelegene Slaves dient.

— Michael - sqlbot

Wenn Sie SHOW PROCESSLISTam Master sind, sehen Sie die eingehende Verbindung vom Slave? Du solltest. Außerdem würde ich STOP SLAVE IO_THREAD;dann START SLAVE IO_THREAD;auf dem Slave versuchen und sehen, wie sich der Ausgang von SHOW SLAVE STATUS(auf dem Slave) ändert, wenn überhaupt.

— Michael - sqlbot

5

Die von Ihnen präsentierte Ausgabe ist sehr verwirrend. Einerseits zeigt der Meister:

mysql-bin.000001   639495

Der Slave PROCESSLISTzeigt an, dass die Replikation funktioniert (der IO - Thread mit dem Master verbunden ist, wird der SQL - Thread wartet).

Der Sklave SHOW SLAVE STATUSbehauptet erneut, alles sei in Ordnung, aber die Position des Meisters ist 106.

Werden alle diese Ausgaben ungefähr zur gleichen Zeit ausgegeben? Wenn nicht, dann sind sie nicht wertvoll.

Ich würde folgendes überprüfen:

Das Offensichtliche: Ist 109.123.100.58wirklich dein Meister?
Listet SHOW PROCESSLISTauf dem Master die Verbindung auf, die der Slave unter dem replicaBenutzer hergestellt hat?
Haben Sie unterschiedliche server-idEinstellungen für Master und Slave?
Haben Sie irgendwelche replicate-do-*oder replicate-ignore-*Einstellungen in Ihrer mysql.cnfDatei?

— Shlomi Noach
quelle

Ja, die Ausgabe erfolgt gleichzeitig. 1. Ja, 109.123.100.58 ist der Meister. 2. nein 3. ja 4. nein. Prozessliste auf

+-------+------+-----------+------+---------+------+-------+------------------+ | Id    | User | Host      | db   | Command | Time | State | Info             | +-------+------+-----------+------+---------+------+-------+------------------+ | 23243 | root | localhost | NULL | Query   |    0 | NULL  | SHOW PROCESSLIST | +-------+------+-----------+------+---------+------+-------+------------------+

— Mastershows anzeigen

3

2-nein ?? Von Minute zu Minute seltsamer. Ich bin mir nicht sicher, ob Ihr Slave tatsächlich mit dem richtigen Master verbunden ist.

— Shlomi Noach

1

Danke für den Tipp! In meinem Fall hatte ich M-> S1-> S2-Replikation und meine S2-Server-ID stimmte mit meiner M-Server-ID überein.

— Aaron R.

1

Besser als die Verwendung von binlog-ignore-db ist die Verwendung der Slave-seitigen Filterung. Ich war in einer ähnlichen Situation gefangen, ja, ich habe einen ganzen Tag gebraucht, um herauszufinden:

Ich habe etwas Großes verpasst !!!

Der Unterschied zwischen

--replicate-do-db=
--replicate-do-table=

Auf der Sklavenseite. Und

--replicate-do-table='mydb.%'

hat bei mir auf -do-table nicht funktioniert. Ich musste benutzen

--replicate-do-db='mydb'

Ich denke, das hätte für eine Wildcard funktioniert

--replicate-wild-do-table='mydb.%'

... Nun erfahren Sie, wie Sie dieselbe Tabelle von mehreren Mastern replizieren können. Okay, ich habe es herausgefunden, MySQL unterstützt es nicht von Haus aus. MariaDB 10 tut es.

Anfangs hatte ich auch ein anderes Problem: Mein Passwort war länger als 32 Zeichen. Boo!

— Dagelf
quelle

1

Ich bin auch auf dieses Problem gestoßen. Die Hauptursache war, den Meister zu haben server_id=0. MariaDB hat ein spezielles Verhalten, bei server_id=0dem die Replikation nicht funktioniert.

Die Server-ID muss für jeden Server in der Replikationsgruppe eindeutig sein. Wenn bei 0, der Standardeinstellung bis MariaDB 10.2.1, belassen wird, stellt ein Slave keine Verbindung zu einem Master her und ein Master lehnt alle Slave-Verbindungen ab.

Als ich anfing, basierend auf 1 zu indizieren, funktionierte alles einwandfrei.

— Ryan Goodfellow
quelle

-2

Sie haben dem Slave nicht mitgeteilt, welche Datenbank repliziert werden soll: Die Variable Replicate_Do_DB ist leer.

Versuchen Sie, die Zeile hinzuzufügen

replicate-do-db = name_of_db (wobei "name_of_db" der Name der zu replizierenden Datenbank ist)

in Ihrer my.cnf (auf Slave) und starten Sie den Slave-Server neu.

EDIT: Ich denke nicht, dass meine Antwort die richtige Lösung ist ;-)

Vielleicht schauen Sie sich stattdessen diese Seite an: http://dev.mysql.com/doc/refman/5.1/en/replication-problems.html

— Chris
quelle

Ich denke nicht, dass das richtig ist. Sie können sehen, dass 639495 Bytes im Binlog des Masters protokolliert wurden

Die Frage ist, warum die Replikation nicht funktioniert - nicht, wenn etwas in das Binlog geschrieben wurde. Normalerweise zeigt der Befehl SHOW MASTER STATUS keine weiteren Informationen an.

Entschuldigung, mein schlechtes .. Show Master Status ergibt

+------------------+----------+--------------+-------------------------+ | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB        | +------------------+----------+--------------+-------------------------+ | mysql-bin.000004 |      106 |              | mysql,informationschema | +------------------+----------+--------------+-------------------------+

— Soyeed

Außerdem wurde mir gesagt, dass wenn ich nicht replizieren-do-db meinte, es alle Datenbanken repliziert. Stattdessen hatte ich dieentry binlog_ignore_db = mysql binlog_ignore_db = informationschema

— Soyeed

1

Befolgen Sie die Anweisungen in dieser Antwort nicht, da Sie der Datenbank nicht mitteilen müssen, welches Schema repliziert werden soll (standardmäßig alle Schemas). Dies würde möglicherweise Ihre Replikation unterbrechen und höchstwahrscheinlich nicht das, wonach Sie suchen. Sie möchten (99,999%) alle Schemas replizieren.

— Shlomi Noach