Tweet
Ich habe heute morgen einen (gestern abend generierten) Dump auf einem Slave eingespielt, mit korrekter CHANGE MASTER-Anweisung natürlich; im Laufe des Vormittags holte er dann langsam die seitdem gemachten Änderungen nach.
Währenddessen löschte eine Kollegin auf einer Log-Tabelle auf dem Master allte Daten aus 2011 und fügte anschließend eine Spalte hinzu (eine PK-Spalte, die Tabelle hatte noch keine). Die Tabelle sieht nun so aus:[highlight=sql]CREATE TABLE `lgf_log_not_found` (
`lgf_timestamp` datetime DEFAULT NULL,
`lgf_ip` varchar(255) COLLATE latin1_german1_ci DEFAULT NULL,
`lgf_url` varchar(255) COLLATE latin1_german1_ci DEFAULT NULL,
`lgf_referrer` varchar(255) COLLATE latin1_german1_ci DEFAULT NULL,
`lgf_id` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`lgf_id`)
) ENGINE=InnoDB AUTO_INCREMENT=3221921 DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci
[/highlight]Wie gesagt, die ID-Spalte ist neu.
Eine halbe Stunde später bekomme ich jedoch Replikationsfehler dieser Art:
Error 'Duplicate entry '3221689' for key 'PRIMARY'' on query. Default database: 'awz'. Query: 'INSERT INTO lgf_log_not_found SET lgf_timestamp='2012-02-09 10:05:36' ,lgf_ip='6X.249.XX.XX' ,lgf_url='irgendeine URL' ,lgf_referrer='''
Auf dem Slave sind zu dem Zeitpunkt die Daten von 2011 noch da, die ID-Spalte ist jedoch auch schon da.
Daraus ergeben sich mMn zwei Fragen:
1. Warum ist der Löschbefehl nicht repliziert worden? Es gab keinen Fehler oder so, aber die Tatsache, dass die Daten von 2011 noch da und die ID-Spalte schon da ist, weist doch darauf hin, dass der Löschbefehl übergangen wurde.
2. Weshalb bekomme ich diesen Fehler? Es stimmt, dass ein Eintrag mit der genannten ID bereits vorhanden ist (tatsächlich noch ein Eintrag aus 2011), aber im INSERT ist keine eindeutige ID angegeben, mMn sollte er doch einfach eingefügt werden, egal unter welcher ID. Ist schon klar, dass dann die Tabellen nicht mehr synchron wären, oder wird bei der Replikation stillschweigend auch der PK in einen INSERT mit eingefügt? Ich dachte, der Slave arbeitet einfach nur das SQL ab, das auch der Master bekommt, und dann hätte bei dem INSERT dieser Fehler nicht auftreten dürfen.
Kann mir da jemand weiterhelfen?
Dave
Währenddessen löschte eine Kollegin auf einer Log-Tabelle auf dem Master allte Daten aus 2011 und fügte anschließend eine Spalte hinzu (eine PK-Spalte, die Tabelle hatte noch keine). Die Tabelle sieht nun so aus:[highlight=sql]CREATE TABLE `lgf_log_not_found` (
`lgf_timestamp` datetime DEFAULT NULL,
`lgf_ip` varchar(255) COLLATE latin1_german1_ci DEFAULT NULL,
`lgf_url` varchar(255) COLLATE latin1_german1_ci DEFAULT NULL,
`lgf_referrer` varchar(255) COLLATE latin1_german1_ci DEFAULT NULL,
`lgf_id` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`lgf_id`)
) ENGINE=InnoDB AUTO_INCREMENT=3221921 DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci
[/highlight]Wie gesagt, die ID-Spalte ist neu.
Eine halbe Stunde später bekomme ich jedoch Replikationsfehler dieser Art:
Error 'Duplicate entry '3221689' for key 'PRIMARY'' on query. Default database: 'awz'. Query: 'INSERT INTO lgf_log_not_found SET lgf_timestamp='2012-02-09 10:05:36' ,lgf_ip='6X.249.XX.XX' ,lgf_url='irgendeine URL' ,lgf_referrer='''
Auf dem Slave sind zu dem Zeitpunkt die Daten von 2011 noch da, die ID-Spalte ist jedoch auch schon da.
Daraus ergeben sich mMn zwei Fragen:
1. Warum ist der Löschbefehl nicht repliziert worden? Es gab keinen Fehler oder so, aber die Tatsache, dass die Daten von 2011 noch da und die ID-Spalte schon da ist, weist doch darauf hin, dass der Löschbefehl übergangen wurde.
2. Weshalb bekomme ich diesen Fehler? Es stimmt, dass ein Eintrag mit der genannten ID bereits vorhanden ist (tatsächlich noch ein Eintrag aus 2011), aber im INSERT ist keine eindeutige ID angegeben, mMn sollte er doch einfach eingefügt werden, egal unter welcher ID. Ist schon klar, dass dann die Tabellen nicht mehr synchron wären, oder wird bei der Replikation stillschweigend auch der PK in einen INSERT mit eingefügt? Ich dachte, der Slave arbeitet einfach nur das SQL ab, das auch der Master bekommt, und dann hätte bei dem INSERT dieser Fehler nicht auftreten dürfen.
Kann mir da jemand weiterhelfen?
Dave