Have a look at: http://www.iptel.org/ser/doc/modules/html/usrloc.html#AEN153
However, this probably does not do all you need, as you still need lookup to synchronize with the db. This could maybe be done with the timer_interval parameter (lower it). I haven't had a look at the code implementing the flush/synchronization, but that could be a start.
I haven't really validated the idea of using database replication/cluster, so there are probably other things to consider as well. I wouldn't worry about heavy SIP load and lost registers because you should a long time before that have taken measures to keep your systems at a lower load... However, synchronization of servers that went down is an issue. Haven't really seen any discussions on the list on replication in itself as a redundancy issue. Anyone?
Locations are not really that critical, are they? If you use registration intervals of ex. 10 minutes, how do you even manage to synchronize the databases manually?
Any more thoughts on your usage scenario and why you would put the effort into moving t_replicate to SQL replication? g-)
Andreas Granig wrote:
Hi,
Is there a simple way to lookup contacts directly from a DB table instead of memory? A quick look into the register module doesn't show anything like that.
The idea behind that is to build a redundant SER cluster. All nodes write their registrations directly into a MySQL master database, which replicates the contacts to the slave databases. The SERs then lookup contacts from their local slave databases. The master database will be secured by a MySQL cluster.
This is because if I replicate registers on SIP layer (for example with t_replicate()), I have to synchronize the location databases manually from time to time, because register replications get lost on heavy SIP load, and there is actually no way to automatically load contacts which are stored on other nodes while one SER was down. Their is also no need to send replicated registers over the net which reduces SIP messages.
I don't really know how much impact this approach will have regarding performance (going around the internal location memory), but I think it will not hurt as much as having out-of-synch location tables on the SER nodes.
Any comments on this approach? Anybody who is also interested in such approach?
Andy
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers