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