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. -- Dan _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
