Mariadb Synchronisation
Moin in die Runde, ich bin gerade ziemlich am verzweifeln, weil ich hier einen Fehler habe, den ich mir nicht erklären kann. Ich habe auf zwei Ubuntu-Kisten (24.04.01 LTS) einen Mariadb-10.11 server laufen und seit dem Upgrade von 22.04 kriege ich die 2-Wege-DB-Synchronisation zwischen den beiden Kisten nicht mehr an den Start. Ich schreib das mal in Spalten pro Kiste: Rechner: *MBIRIBUKU* Rechner: *LAPUTOPU* In der /etc/mysql/my.cnf: [mariadb] log-bin *server-id=2* log-basename=mbiribuku binlog-format=mixed In der /etc/mysql/my.cnf: [mariadb] log-bin *server-id=1* log-basename=laputopu binlog-format=mixed MariaDB [(none)]> show variables like 'server_id'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | s*erver_id | 2 * | +---------------+-------+ MariaDB [(none)]> show variables like 'server_id'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ |*server_id | 1* | +---------------+-------+ MariaDB [(none)]> SHOW SLAVE STATUS \G; *************************** 1. row *************************** Slave_IO_State: *Master_Host: laputopu* Master_User: replicator Master_Port: 3306 Connect_Retry: 60 Master_Log_File: Read_Master_Log_Pos: 4 Relay_Log_File: mbiribuku-relay-bin.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: *Slave_IO_Running: No* 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: 4 Relay_Log_Space: 256 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: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 1593 Last_IO_Error: Fatal error: *The slave I/O thread stops because master and slave have equal MariaDB server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).* Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: *Master_Server_Id: 2* Master_SSL_Crl: Master_SSL_Crlpath: Using_Gtid: Slave_Pos Gtid_IO_Pos: Replicate_Do_Domain_Ids: Replicate_Ignore_Domain_Ids: Parallel_Mode: optimistic SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Slave_DDL_Groups: 0 Slave_Non_Transactional_Groups: 0 Slave_Transactional_Groups: 0 Replicate_Rewrite_DB: MariaDB [(none)]> SHOW SLAVE STATUS \G; *************************** 1. row *************************** Slave_IO_State: *Master_Host: mbiribuku* Master_User: replicator Master_Port: 3306 Connect_Retry: 60 Master_Log_File: Read_Master_Log_Pos: 4 Relay_Log_File: laputopu-relay-bin.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: *Slave_IO_Running: No* 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: 4 Relay_Log_Space: 256 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: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Error: connecting slave requested to start from GTID 0-2-1983, which is not in the master's binlog' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: *Master_Server_Id: 2* Master_SSL_Crl: Master_SSL_Crlpath: Using_Gtid: Slave_Pos Gtid_IO_Pos: 0-2-1983 Replicate_Do_Domain_Ids: Replicate_Ignore_Domain_Ids: Parallel_Mode: optimistic SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Slave_DDL_Groups: 0 Slave_Non_Transactional_Groups: 0 Slave_Transactional_Groups: 0 Replicate_Rewrite_DB: Ich begreife nicht, dass die Kisten sich mit den Server-Ids behaken. In der Config und in der DB sind die doch klar verschieden. Beide Kisten melden jeweils die andere als Master-Host, aber im Slave-Status steht beide Male eine Master_Server_ID:2. Und bevor das nicht geklärt ist komme ich wohl auch kaum mit dem GTID Sync-Fehler weiter ... Hat da zufällig jemand von Euch noch einen schlauen Tipp? Danke & Gruß Stefan. -- Stefan U. Hegner <stefan@hegner-online.de> * * * D-32584 Löhne --- good ole Germany internet:http://www.hegner-web.de * * * GPG-Key | 048D 7F64 0BEB 73B1 2725 F-Print | C05E 4F77 9674 EF11 55FE
Hola, On Sat, Nov 23, 2024 at 09:48:07PM +0100, Stefan U. Hegner wrote:
Moin in die Runde,
ich bin gerade ziemlich am verzweifeln, weil ich hier einen Fehler habe, den ich mir nicht erklären kann. Ich habe auf zwei Ubuntu-Kisten (24.04.01 LTS) einen Mariadb-10.11 server laufen und seit dem Upgrade von 22.04 kriege ich die 2-Wege-DB-Synchronisation zwischen den beiden Kisten nicht mehr an den Start.
Last_IO_Error: Fatal error: *The slave I/O thread stops because master and slave have equal MariaDB server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).*
Also das wird dein Fehler sein. Die Frage ist - Sicher das die Kisten nicht jeweils auf sich selber connecten? So das Thema IP Addressen vertauscht oder so?
Hat da zufällig jemand von Euch noch einen schlauen Tipp?
So tief stecke ich jetzt nicht im Mysql Thema - Kann auch nur "Raten". Ansonsten baue ich sowas mittlerweile alles mit Ansible - so das ich jetzt einfach einen von beiden wegwerfen würde ... Der synced dann schon wieder. Flo -- Florian Lohoff f@zz.de Any sufficiently advanced technology is indistinguishable from magic.
Moin Flo, Am 24.11.24 um 22:20 schrieb Florian Lohoff:
Hola,
On Sat, Nov 23, 2024 at 09:48:07PM +0100, Stefan U. Hegner wrote:
Last_IO_Error: Fatal error: *The slave I/O thread stops because master and slave have equal MariaDB server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).* Also das wird dein Fehler sein.
Die Frage ist - Sicher das die Kisten nicht jeweils auf sich selber connecten? So das Thema IP Addressen vertauscht oder so?
Ja, das ist korrekt, aber ich schrieb ja schon:
Ich begreife nicht, dass die Kisten sich mit den Server-Ids behaken.
In der Config und in der DB sind die doch klar verschieden. Beide Kisten melden jeweils die andere als Master-Host, aber im Slave-Status steht beide Male eine Master_Server_ID:2.
Sprich: es steht (zumindest scheinbar) richtig in der Config und auch in der DB. Und beide Kisten verweisen jeweils auf die andere.
In meiner ersten Mail hatte ich das so schön nebeneinder drapiert, aber unser list-server mag scheinbar noch immer kein HTML ... kann ich verstehen, aber dafür wäre es hilfreich gewesen ...
So tief stecke ich jetzt nicht im Mysql Thema - Kann auch nur "Raten".
Ansonsten baue ich sowas mittlerweile alles mit Ansible - so das ich jetzt einfach einen von beiden wegwerfen würde ... Der synced dann schon wieder.
Das Problem ist, das cqrlog, die Anwendung, die die DB benutzt, leider einen mysql-server braucht. Und die cqrlog community ist auch nur begrenzt tief bewandert in sql-Spezifika. - Muss vielleicht mal nach einer mariadb Liste oder einem Formum dafür suchen ... Danke & Gruß Stefan. -- Stefan U. Hegner <stefan@hegner-online.de> * * * D-32584 Löhne --- good ole Germany internet:http://www.hegner-web.de * * * GPG-Key | 048D 7F64 0BEB 73B1 2725 F-Print | C05E 4F77 9674 EF11 55FE
Hola, On Sun, Nov 24, 2024 at 10:46:03PM +0100, Stefan U. Hegner wrote:
Moin Flo,
Die Frage ist - Sicher das die Kisten nicht jeweils auf sich selber connecten? So das Thema IP Addressen vertauscht oder so?
Ja, das ist korrekt, aber ich schrieb ja schon:
Ich begreife nicht, dass die Kisten sich mit den Server-Ids behaken.
In der Config und in der DB sind die doch klar verschieden. Beide Kisten melden jeweils die andere als Master-Host, aber im Slave-Status steht beide Male eine Master_Server_ID:2.
Sprich: es steht (zumindest scheinbar) richtig in der Config und auch in der DB. Und beide Kisten verweisen jeweils auf die andere.
Ich habe gerade mal hier in meine installationen geguckt. Zugegebenermaßen sind das Galera Cluster - Da hab ich keine server-id's configuriert in /etc/mysql - Da steht eine "1" und ist auskommentiert.
In meiner ersten Mail hatte ich das so schön nebeneinder drapiert, aber unser list-server mag scheinbar noch immer kein HTML ... kann ich verstehen, aber dafür wäre es hilfreich gewesen ...
Dann hätte ICH die mail aber nicht gelesen. Ich kann auf einem Terminal mit Mutt keine HTML Mails lesen und dafür mache ich keinen Browser auf. Das wird dann nur mit dem fast-read-button-D gelesen.
So tief stecke ich jetzt nicht im Mysql Thema - Kann auch nur "Raten".
Ansonsten baue ich sowas mittlerweile alles mit Ansible - so das ich jetzt einfach einen von beiden wegwerfen würde ... Der synced dann schon wieder.
Das Problem ist, das cqrlog, die Anwendung, die die DB benutzt, leider einen mysql-server braucht. Und die cqrlog community ist auch nur begrenzt tief bewandert in sql-Spezifika. - Muss vielleicht mal nach einer mariadb Liste oder einem Formum dafür suchen ...
Ja - Einen der beiden (Die sich ja gegenseitig synchronisieren) wegwerfen, und neu synchronisieren lassen. So würde ich das sowas versuchen zu heilen. Was ich beim googeln sofort finde ist das der master (bei master-master) jeweils der replikations sendende Partner seine ID in die binary logs schreibt die er ja dann repliziert. Wenn die mal irgendwann zufällig einen update geschrieben haben als sie mal eine doppelte ID hatten - dann stehen da noch binlogs die dann die replikation abbrechen lassen. https://dba.stackexchange.com/questions/9756/mysql-thinks-master-slave-have-... Die wird man loswerden müssen. das einfachste ist Datenbanken dumpen, mysql komplett wegwerfen, neu installieren und Datenbanken wieder importieren. Wenn das nicht gerade mehrere hundert Gigabyte sind ist das ja schnell gemacht. Deshalb automatisiere ich so zeugs mit ansible. Wenn es kaputt geht - Dumpen, VMs wegwerfen, VMs neu erzeugen, ansible loslaufen lassen, datenbanken importieren - gut ist. Dauer - 10 Minuten ohne den DB Import. Flo -- Florian Lohoff f@zz.de Any sufficiently advanced technology is indistinguishable from magic.
Moin Flo, Am 24.11.24 um 22:46 schrieb Stefan U. Hegner:
Moin Flo,
Am 24.11.24 um 22:20 schrieb Florian Lohoff:
On Sat, Nov 23, 2024 at 09:48:07PM +0100, Stefan U. Hegner wrote:
Last_IO_Error: Fatal error: *The slave I/O thread stops because master and slave have equal MariaDB server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).* Also das wird dein Fehler sein.
Die Frage ist - Sicher das die Kisten nicht jeweils auf sich selber connecten? So das Thema IP Addressen vertauscht oder so?
Dieses Thema hatte sich dann auch mit dem Reparieren der /etc/hosts und dem korrekten Eintrag für 127.0.0.1 erledigt bzw. gelöst ... Nur fürs Protokoll. VG Stefan. -- Stefan U. Hegner <stefan@hegner-online.de> * * * D-32584 Löhne --- good ole Germany internet:http://www.hegner-web.de * * * GPG-Key | 048D 7F64 0BEB 73B1 2725 F-Print | C05E 4F77 9674 EF11 55FE
Am 23.11.24 um 21:48 schrieb Stefan U. Hegner:
Ich begreife nicht, dass die Kisten sich mit den Server-Ids behaken.
In der Config und in der DB sind die doch klar verschieden. Beide Kisten melden jeweils die andere als Master-Host, aber im Slave-Status steht beide Male eine Master_Server_ID:2.
Und bevor das nicht geklärt ist komme ich wohl auch kaum mit dem GTID Sync-Fehler weiter ...
Hat da zufällig jemand von Euch noch einen schlauen Tipp?
Danke & Gruß
Stefan.
-- Stefan U. Hegner <stefan@hegner-online.de> * * * D-32584 Löhne --- good ole Germany internet: http://www.hegner-web.de * * * GPG-Key | 048D 7F64 0BEB 73B1 2725 F-Print | C05E 4F77 9674 EF11 55FE
Hallo, On 23.11.24 21:48, Stefan U. Hegner wrote:
MariaDB [(none)]> SHOW SLAVE STATUS \G; *************************** 1. row *************************** Slave_IO_State: *Master_Host: laputopu* [...] Relay_Log_File: mbiribuku-relay-bin.000001 [...] Replicate_Ignore_Server_Ids: *Master_Server_Id: 2*
MariaDB [(none)]> SHOW SLAVE STATUS \G; *************************** 1. row *************************** Slave_IO_State: *Master_Host: mbiribuku* [...] Relay_Log_File: laputopu-relay-bin.000001 [...] Replicate_Ignore_Server_Ids: *Master_Server_Id: 2*
Ich begreife nicht, dass die Kisten sich mit den Server-Ids behaken.
In der Config und in der DB sind die doch klar verschieden. Beide Kisten melden jeweils die andere als Master-Host, aber im Slave-Status steht beide Male eine Master_Server_ID:2.
Bei beiden mysql-Servern die gleiche ''Replicate_Ignore_Server_Ids'' gesetzt. Somit sieht Server1 nur seine Replikationsdaten, die von Server2 ignoriert er. https://mariadb.com/kb/en/show-replica-status/ Replicate_Ignore_Server_Ids List of server_ids that are currently being ignored for replication purposes, or an empty string for none, as specified in the IGNORE_SERVER_IDS option of the CHANGE MASTER TO statement. Gruss, Juergen
Teilnehmer (3)
-
Florian Lohoff
-
Juergen Raschke
-
Stefan U. Hegner