Hmm, maybe an idea by myself on the cause: the initial sync to galera was done as followed:
- dump on the (locked) master - inserted the dumps on a galera node - started replication (change master to...) with the saved state of the master I've read somewhere that galera handles the auto_increments with a offset for each node (by design) - so you cannot rely on it. That is no problem for the application at all. But as i use ROW based replication the autoincrements (created on the master) could exist on the galera side already, right? what would be a way to avoid it? i think i need another migration scenario... Otto Am 05.09.14 um 18:59 schrieb Otto Berger: > > Hi all, > > i'm new to this list :) > > My setup: > > MySQL Server 5.5.37 -> Replication -> Galera 10 Cluster (currently 2 nodes) > > The old MySQL Master is receiving inserts to a table with a > auto_increment field (primary key). The Galera Cluster is configured as > classic slave to the master. From time to time i'm getting duplicate > entry issues on the galera cluster: > > 140905 12:06:15 [ERROR] Slave SQL: Error 'Duplicate entry '16383' for > key 'PRIMARY'' on query. ... > 140905 12:06:15 [Warning] Slave: Duplicate entry '16383' for key > 'PRIMARY' Error_code: 1062 > > I cannot see the problem where there could came from... My thought was > if the insert (auto_increment) succeeds on the master then is must also > succeed on the galera side... > > someone with an idea on it? > > BR > Otto > > > > _______________________________________________ > Mailing list: https://launchpad.net/~maria-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~maria-discuss > More help : https://help.launchpad.net/ListHelp >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
