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