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?)

g-)

 

---- Original Message ----
From: Java Rockx
To: Karl H. Putz
Cc: serusers
Sent: Monday, May 30, 2005 05:07 PM
Subject: Re: [Serusers] SER Reports "out of memory"

> 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@columbus.rr.com> wrote:
>> -----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
>> replication?
>>
>> 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@lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>
>
> _______________________________________________
> Serusers mailing list
> serusers@lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
>
>
>
> _______________________________________________
> Serusers mailing list
> serusers@lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers