<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2627" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>Yes, good point, but I don't like the solution. Both doing t_replicate AND
DB replication is replication at both layers... I think we here have another
argument for replication at the application layer. I'm starting to get blurred
vision here: What was the reason for doing DB-level replication in the first
place? (And BTW, what do you gain?)</DIV>
<DIV>g-)</DIV>
<DIV> </DIV>
<DIV>---- Original Message ----<BR>From: Java Rockx<BR>To: Karl H. Putz<BR>Cc:
serusers<BR>Sent: Monday, May 30, 2005 05:07 PM<BR>Subject: Re: [Serusers] SER
Reports "out of memory"<BR><BR>> Good point. So then perhaps t_replicate()
[AND] save_memory() should<BR>> be used as normal. And SER should then just
start up using a<BR>> lazy-loading mechanism. Eventually all SER routers in
the farm would<BR>> then have a fully populated cache and the problem would
be solved. <BR>> <BR>> In other words the SER server that
physically recieves the original<BR>> REGISTER message would save() and
t_replicate(). <BR>> <BR>> All the peers in the farm that receive a
REGISTER via the<BR>> t_replicate() function would only use save_memory().
<BR>> <BR>> MySQL replication still occurs and if a SER server is
restarted it<BR>> doesn't attempt to load usrloc info upon startup, but
rather loads it<BR>> over a period of time. All the while, if a usrloc record
is looked-up<BR>> and it is on in cache, then SER would query MySQL for the
correct<BR>> ucontact record. <BR>> <BR>> Thanks for
the qustion --- I hadn't thought about that before.<BR>> <BR>>
Regards,<BR>> Paul<BR>> <BR>> <BR>> On 5/30/05, Karl H. Putz
<kputz@columbus.rr.com> wrote:<BR>>> -----Original Message-----On
Behalf Of Jiri Kuthan<BR>>> Sent: Monday, May 30, 2005 5:36 AM<BR>>>
At 03:40 AM 5/30/2005, Java Rockx wrote:<BR>>>> Currently, usrloc is
replicated via t_replicate() using<BR>>>> db_mode=writeback.
<BR>>>> <BR>>>> However, our lazy-load patch would obsolete
the need for<BR>>> t_replicate() because we have multiple MySQL servers
that are<BR>>> active-active so __all__ replication really occurs at the
database<BR>>> layer rather than the SIP layer.<BR>>> <BR>>>
So this is the point which I am still struggling with. I mean<BR>>>
generally there is a problem<BR>>> of read-write intenstive UsrLoc
operations. We can move it from<BR>>> SIP to DB. However,
whichever<BR>>> layer we choose to solve the problem, it takes
careful<BR>>> dimensioning. Otherwise the<BR>>> replication
mechanism may cause peformance problems.<BR>>> <BR>>> What Mysql
setup are you exactly using? Cluster? Master/slave<BR>>> replication?
<BR>>> <BR>>> Otherwise I think that the cache policy
"load-on-demand" makes sense.<BR>> <BR>> If pure DB replication is used,
what would happen in the following<BR>> scenario: <BR>> <BR>> A given
user receives multiple calls such that more than 1 physical<BR>> SER <BR>>
server has userloc<BR>> cache populated.<BR>> <BR>> The user then
phsyically moves or changes return contact registration<BR>> information and
re-registers.<BR>> <BR>> It seems that the specific SER server that
handled the registration<BR>> would <BR>> update cache and the<BR>>
backend DB would be updated. But any attempt to contact the user<BR>>
through a <BR>> SER server that has<BR>> not yet expired the old cache
info would fail.<BR>> <BR>> <BR>> Karl<BR>> <BR>>>
<BR>>> -jiri<BR>>> <BR>>>
_______________________________________________<BR>>> Serusers mailing
list<BR>>> serusers@lists.iptel.org<BR>>>
http://lists.iptel.org/mailman/listinfo/serusers<BR>>> <BR>> <BR>>
<BR>> _______________________________________________<BR>> Serusers
mailing list<BR>> serusers@lists.iptel.org<BR>>
http://lists.iptel.org/mailman/listinfo/serusers<BR>> <BR>> <BR>>
<BR>> <BR>> <BR>> <BR>>
_______________________________________________<BR>> Serusers mailing
list<BR>> serusers@lists.iptel.org<BR>>
http://lists.iptel.org/mailman/listinfo/serusers</DIV></BODY></HTML>