Currently, usrloc is replicated via t_replicate() using db_mode=writeback.<br>
<br>
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.<br>
<br>
So in this situation, when a REGISTER message hits any SIP router, SER
will do the usual stuff that it currently does (excluding t_replicate),
and when it persists the user contact to MySQL, the database will
replicate to the other DB servers.<br>
<br>
Then if a usrloc record is "looked-up" on any other SIP router and a
match is not found in cache, the usrloc code will query MySQL for the
record, which was replicated by MySQL.<br>
<br>
By doing this we will have a "zero-delay" SER start time, regardless of
the number of records in the subscriber table and we also eliminate the
possiblity of t_replicate() sending a usrloc record to peer SIP routers
which didn't process the request.<br>
<br>
Jiri, do you see any pitfalls with this school of thought.<br>
<br>
Regards,<br>
Paul<br><br><div><span class="gmail_quote">On 5/29/05, <b class="gmail_sendername">Jiri Kuthan</b> <<a href="mailto:jiri@iptel.org">jiri@iptel.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At 03:15 PM 5/29/2005, Java Rockx wrote:<br>>Actually,
a minute delay would be a bad thing because replicated usrloc records,
using t_replicate() would not make it in to peer SER server caches when
the server is starting up.<br>><br>>Given this fact, and given
the fact that most SER modules do not hash data upon server startup
[like group.so, etc, etc] we are starting to see little value in
caching usrloc. Our MySQL server is hit 12 times for an INVITE message
and so complete caching of usrloc is of minimal performace gain.<br><br>indeed.<br><br><br>>Anyhow, we're not in process of modifying SER so that:<br>><br>>* when ser starts up usrloc is "lazy-loaded"<br>
>*
if a usrloc record is looked up in cache and is __NOT__ found, then
MySQL will be queried. If found in MySQL then the usrloc record will be
put in to cache for future lookups<br>><br>>By doing these two things we should not have a problem we excessively large subscriber bases.<br><br>Appears reasonable to me.<br><br>Still -- with the way you are suggesting, CallID based load distribution, how
<br>do you replicate UsrLoc changes across all the servers?<br><br>-jiri<br><br></blockquote></div><br>