ein von mehreren Schemata wird nicht repliziert

[Dave_Bowman]

Hallo,

ich habe einen MySQL-Server mit einem guten Dutzend Schemata, manche sollen repliziert werden, manche nicht. Dies realisiere ich über diverse replicate-wild-do-table = schema.% - Einträge in der my.ini des Slaves. Funktioniert alles wie es soll. Abgesehen von einem Schema, welches einfach nicht repliziert wird. Woran kann das liegen? Es gibt keinen Filter in der my.ini des Masters, und ein entsprechender replicate-wild-do-table-Eintrag beim Slave ist selbstverständlich vorhanden. Gibt es weitere Konfigurationsmöglichkeiten, um die Replikation eines Schemas zu verhindern? Oder irgendwelche wilden Konstellationen, die das verhindern könnten? Stehe vor einem Rätsel.

Weiß jemand Rat?

Dave

[Dave_Bowman]

Ja, sorry, dass ich das Thema nochmal anspreche. Hat wirklich niemand eine Idee? Offenbar funktioniert die Replikation prinzipiell, denn Änderungen, die ich mit der Workbench auf dem Master vornehme, werden repliziert. Scheinbar sind 'nur' alle Änderungen betroffen, die innerhalb eines bestimmten Programms vorgenommen werden. Also scheint das an diesem Programm zu liegen. Der ConnectionString jedoch sieht völlig normal aus, es werden keine zusätzlichen exotischen Parameter übergeben, Standard-Schema ist das betreffende, und die Applikation funktioniert ja auch auf dem Master, alle Änderungen werden korrekt auf Platte geschrieben. Nur irgendwie so, dass die Replikation diese Änderungen ignoriert. Habe zwischenzeitlich auf Eigenheiten beim binlog-Format (MIXED) getippt, aber dann würden diese Probleme ja auch in anderen Schemata vorkommen.

... ich kapier's nicht ... jemand noch eine Idee?

Dave

Edit: Der Vollständigkeit halber hier der ConnectionString: DRIVER={MySQL ODBC 3.51 Driver};SERVER=localhost;PORT=xx;DATABASE=knw;USER =root;PASSWORD=pw;

[Michael Bieri]

Hmm, du verbindest aus einer Applikation über den Root User?

Geh mal dieses Dokument durch:
http://dev.mysql.com/doc/refman/5.1/...ion-rules.html

Was meint ein "SHOW MASTER STATUS;" (auf dem Slave natürlich)?

[Dave_Bowman]

Das Dokument bin ich schon durchgegangen, wenn auch nicht detailliert. Im Grunde aber würden ja die Kriterien auf alle Schemata zutreffen, das Problem tritt aber nur bei einem auf. Ein Schema von 13. Alle anderen 12 werden wunderbar repliziert. Auch würde dann die Tatsache, dass Änderungen in der Workbench übernommen werden, keine Rolle spielen. Oder?

Ja, das mit dem 'root' ist mir bewußt. Ist hier aber gängige Praxis.

Ich meine, dass es was mit der Applikation zu tun haben muss. Würde ich zumindest sagen ...

Master Status ist leer, weil wir auf dem Slave kein BinLog führen.

[Dave_Bowman]

[Problem erledigt]

nur für's Protokoll, ich habe das Rätsel gelöst ...

... es lag am Dump, der (immer gleich) mittels Batch in der Nacht erstellt wurde. Irgendwann wurde ein Schema vom Server entfernt, welches jedoch noch in der Batch als zu dumpendes Schema enthalten war. Die Folge: Der Dump wurde insofern abgebrochen, als dass alle weiteren Schemata ignoriert wurden (betraf aber nur dieses eine letzte). Also wurde nie ein neuer Dump dieses Schemas auf dem Backup-Server eingespielt. Das erklärt, warum meine Änderungen auf dem Server immer repliziert wurden, die Checksummen dennoch nie stimmten und ich also auf das Programm als Fehlerursache schloss.