17 Jan
2005
17 Jan
'05
2:38 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers