[SR-Users] db_cluster together with the registrar module = signal 11

Daniel-Constantin Mierla miconda at gmail.com
Thu Aug 30 11:32:18 CEST 2012


On 8/30/12 10:29 AM, Øyvind Kolbu wrote:
> On 2012-08-30 at 10:09, Daniel-Constantin Mierla wrote:
>> On 8/29/12 9:15 PM, Øyvind Kolbu wrote:
>>> On 2012-08-29 at 20:16, Daniel-Constantin Mierla wrote:
>>>> is usrloc module configured in db only mode?
>>> Yes, db_mode is 3.
>> this might not be very suitable for db_cluster usage if one db server is
>> done, because right now the reading is done to the first available server.
> I choose 3 because of the usrloc documentation: «The mode is useful if you
> configure more servers sharing the same DB without any replication at SIP
> level.» As I want multiple servers to write to the same database it seemed
> as the best option.

Yes, it is what it says, but you have two database servers. Your two 
kamailios don't connect to a single instance of DB server.

>
>> No, you have to do some C coding. The target was to offer high
>> availability to access a database server, when one is down, try next.
> OK, will see if I get the time to do that.
>
>> Perhaps you can add some cross replication at database server layer.
> Yes, I've asked our DBAs for that, but they are not ready yet.
>
>>> Hm, perhaps I was a bit confused on how the affected rows works. Anyhow
>>> if a row is missing on a secondary server the UPDATE will fail and it
>>> will never be fixed with an INSERT.
>> IIRC, if the operation was successful, affected rows checks the last
>> used connection. In a cluster, the operation is considered to be
>> successful when int succeeded on a db server node.
>>
>> I think you are looking more for replication, rather that high
>> availability of the db layer. This is not done by db_cluster, if the
>> nodes are up, then all should be fine, but if one goes down and then
>> back up, its content is not synchronized, should be done by the db
>> server itself.
> Yes, I actually want both, HA + replication, by using db_cluster as the
> replicator. And as I've demonstrated the location-table on non-primary
> servers will lack entries after downtime, which is bad.
Replication is done with parallel writing as long as all nodes are 
available, but, better said, you look for re-synchronization after 
downtime, which is another story, not easy to code, because it is db 
specific.

>
> If this indeed is impossible I've have to continue our current scheme with
> SIP level replication.
If you use db mode 3, then you can do database level replication, is the 
same.

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat




More information about the sr-users mailing list