30 May
2005
30 May
'05
11:07 a.m.
Good point. So then perhaps t_replicate() [AND] save_memory() should be used
as normal. And SER should then just start up using a lazy-loading mechanism.
Eventually all SER routers in the farm would then have a fully populated
cache and the problem would be solved.
In other words the SER server that physically recieves the original REGISTER
message would save() and t_replicate().
All the peers in the farm that receive a REGISTER via the t_replicate()
function would only use save_memory().
MySQL replication still occurs and if a SER server is restarted it doesn't
attempt to load usrloc info upon startup, but rather loads it over a period
of time. All the while, if a usrloc record is looked-up and it is on in
cache, then SER would query MySQL for the correct ucontact record.
Thanks for the qustion --- I hadn't thought about that before.
Regards,
Paul
On 5/30/05, Karl H. Putz <kputz(a)columbus.rr.com> wrote:
replication?
-----Original Message-----On Behalf Of Jiri
Kuthan
Sent: Monday, May 30, 2005 5:36 AM
At 03:40 AM 5/30/2005, Java Rockx wrote:
>Currently, usrloc is replicated via t_replicate() using
db_mode=writeback.
However, our lazy-load patch would obsolete the need for
t_replicate() because we
have multiple MySQL servers that are
active-active so __all__ replication really occurs at the database
layer rather than the SIP layer.
So this is the point which I am still struggling with. I mean
generally there is a problem
of read-write intenstive UsrLoc operations. We can move it from
SIP to DB. However, whichever
layer we choose to solve the problem, it takes careful
dimensioning. Otherwise the
replication mechanism may cause peformance problems.
What Mysql setup are you exactly using? Cluster? Master/slave
Otherwise I think that the cache policy "load-on-demand" makes sense.
If pure DB replication is used, what would happen in the following
scenario:
A given user receives multiple calls such that more than 1 physical SER
server has userloc
cache populated.
The user then phsyically moves or changes return contact registration
information and re-registers.
It seems that the specific SER server that handled the registration would
update cache and the
backend DB would be updated. But any attempt to contact the user through a
SER server that has
not yet expired the old cache info would fail.
Karl
-jiri
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers