-----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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers