2009/7/31 Dan Pascu <[email protected]>: > On Thursday 30 July 2009, Razvan Pistolea wrote: >> 2. Synchronization between dbs will be lost. >> >> 3b. use database managers (that know how to merge databases) >> 3c. use a cluster db > > That sounds good in theory, but in practice fails in so many ways. I've worked > with this for years and even after so much time bidirectional database > replication is extremely fragile and fails easily. Just one example: > > You start writing to db1, it performs the operation just fine, but right after > it finished and is about to return you the success response to your query you > lose the connection. If never see the answer, assume it failed and go on to > write the record to db2, which succeeds as well and also returns the answer. > Now you have the same record in both databases and when they will try to > replicate from each other they'll fail. The problem gets even worse with > multiple databases that replicate from each other. > > This is not just a theoretical example. I've seen this on a constant basis > when performing a simple operation like heartbeat stop on the master to move > the services to the slave, while somebody writes into the database as the same > time (like for example opensips writing accounting requests for something as > modest as 1.5 calls per second). This is so common, that you can consider > yourself lucky if replication is not broken between the 2 databases when you > stop one to activate the other, without taking measures to stop the influx of > write operations to them during the switch.
Very good points. master-master replication or master-slave becoming inactive-master is really a pain, I've also suffered it a lot. I wonder if filesystem based replication (i.e. BRBD) is a more reliable choice even if it could seem fragile (it's a binary replication, so a single error could entirely corrupt the database). About it, I've listened every kind of opinions, so... :) -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
