MySQL Ring-Replikation

bitmuncher

bitmuncher

Foren Gott
Folgende Situation: Ich habe 3 Datenbankserver. server1 ist Master für server2, server2 ist Master für server3 und Server3 ist Master für server1. Also eine einfache Ring-Replikation.

Das Problem ist nur, dass die Replikation problemlos funktioniert, wenn die Datenbank frisch eingerichtet ist. Wird eine Tabelle gelöscht, bekommen das beim ersten Mal auch alle Server mit. Erstellt man danach eine identische Tabelle (gleicher Name, gleiche Felder) nochmal, wird diese Tabelle aber nicht mehr auf den anderen Servern angelegt. Erstelle ich die Tabelle danach auf allen Servern per Hand, werden eingefügte Datensätze nicht mehr repliziert. Die Binlog-Position wird allerdings korrekt von 'show slave status' angezeigt. Lösche ich die Tabelle danach nochmal, bekomme ich beim 'show slave status' die Meldung "Error 'Unknown table 'test'' on query. Default database: 'test'. Query: 'drop table test'". 'log-slave-updates' ist aber aktiviert. Erst nach einer Neu-Einrichtung aller Datenbanken funktioniert die Replikation wieder. Restart der Slaves und erneutes Ausführen von 'change master...' reicht leider nicht aus.

Hat irgendwer eine Idee, woher diese Fehler kommen können und wie man die vermeiden kann?

MySQL-Version: 5.0.45-linux-i686-icc-glibc23
Konfiguration aller Server wie folgt:

Code:
[client]

[mysqld]
datadir              = /usr/local/mysql/data
set-variable         = key_buffer=128M
set-variable         = max_allowed_packet=1M
set-variable         = table_cache=512
set-variable         = sort_buffer=2M
set-variable         = record_buffer=2M
set-variable         = thread_cache=4

log-bin              = /usr/local/mysql/data/toksta1.binlog
log-slave-updates
binlog-do-db         = chatprovider
binlog-do-db         = test

server-id            = 1

master-host          = 123.123.123.123
master-port          = 3306
master-user          = slave_user
master-password      = meinslavepasswort
master-connect-retry = 60

replicate-do-db      = chatprovider
replicate-do-db      = test

[safe_mysqld]
err-log              = /usr/local/mysql/data/mysqld.log

[mysqldump]
quick
max_allowed_packet   = 16M

[mysql]
no-auto-rehash

[isamchk]
key_buffer           = 20M
sort_buffer_size     = 20M
read_buffer          = 2M
write_buffer         = 2M

[myisamchk]
key_buffer           = 20M
sort_buffer_size     = 20M
read_buffer          = 2M
write_buffer         = 2M

[mysqlhotcopy]
interactive-timeout

Natürlich unterscheiden sich auf den einzelnen Servern die Master-Hosts, wobei die in der Konfiguration ja eh irrelevant sind, da ich 'change master to...' verwende, was dann ja in der master.info abgelegt wird.
 
Problem ist gelöst. Ursache war, dass in einem replizierten System normalerweise jedes Query nur einmal ausgeführt werden darf. Da beim Anlegen einer Tabelle aber keine eindeutige ID o.ä. vorhanden ist, was das Query einmalig macht, kann man eine Tabelle nicht einfach löschen und danach mit gleicher Struktur wieder anlegen.
 

Ähnliche Themen

VMWaren und Mysql Sicherung

JBidWatcher: Problem bei loading Auctions in Verbindung mit mySQL

Samba 4.1.9 mit Bind 9.9.4

Akonadi startet nicht mehr

Windows clients können nicht mehr auf lange laufendes System zugreifen

Zurück
Oben