[OpenSIPS-Devel] [Fwd: Re: [NEW] Virtual DB module]

[Thomas Gelf]

Dan Pascu wrote:
> 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:

I must agree, it is. Nonetheless I'm still using it with some
heavvy-loaded 100GB+ replication setups with hundreds of (mostly
write) queries per second - there are too many things that should
never happen, but they do. But such setups are still ways better
then all the alternatives I discovered for the given scenarios.

But: of course it strongly depends on what kind of data you're
handling. I do not consider usrloc critical, issues with dialog
entries could lead to dropped calls - I must confess I'm not
using presence-related stuff, so no idea about that part. Acc
data is usually useless without cleanup / aggregation jobs, so
duplicate entries shall be catched.

I'd like to say THANK YOU for this great module - even if it
is (combined with the components it depends on) far from being
perfect, it will help me to get a more reliable system.

> 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.

Please correct me if I'm wrong - I always thought in case of a clean
shutdown a DB server would:

- block new connections
- let active transactions finish cleanly
- kill too-long-running transactions

Of course, this is different in case of a crash, network outage or
whatever. And if you are telling me that this does not happen because
of a MySQL bug not fixed since 4 years I'll believe you withoug even
checking the bug database to see whether your statement is true. Once
again: we are not living in a perfect world, but in my believes this
module will allow us to make it just a little bit better ;-)

Regards,
Thomas Gelf