[Serusers] Problem with MySQL Replication of 'subscriber' table

Iqbal iqbal at gigo.co.uk
Wed Sep 7 12:30:35 CEST 2005


but then how do you replicate the other tables

Iqbal

Klaus Darilion wrote:

> Another option: Do not replicate the mysql data bases.
>
> You have double replication. On SIP level and on mysql level. You are 
> asking for trouble. You should do the replication once!
>
> regards
> klaus
>
> Bogdan-Andrei Iancu wrote:
>
>> Hi Gerhard,
>>
>> there are two ways to solve it:
>>
>> 1) server which gets a replicated REGISTER updates only its cache and 
>> not also the DB (use save_mem()); doing so, the DB of the backup 
>> machine will be updated only via DB replication, so no overlapping.
>>
>> 2) configure mysql replication to ignore the error code for 
>> overlapping; See |"--slave-skip-errors" in|
>>     http://dev.mysql.com/doc/mysql/en/replication-options.html
>>
>> regards,
>> bogdan
>>
>>
>> Gerhard Zweimüller wrote:
>>
>>> Hi,
>>>
>>> let me briefly describe my problem:
>>>
>>> We run ser for quite a while already and are currently
>>> switching to a redundant system with 2 servers.
>>> Each of the servers runs Debian Sarge, an instance of
>>> MySQL 4.0.18 and ser_0.8.14.
>>>
>>> We implemented the replication of INVITE messages via
>>> SIP, so the other server always has all known SIP UAs
>>> in his RAM-cache. This works fine.
>>>
>>> Both SERs run in as follows:
>>> modparam("usrloc", "db_mode", 2)
>>> modparam("usrloc", "timer_interval", 20)
>>>
>>>
>>> The next task was to replicate the whole 'ser' db from
>>> MySQL-instance 1 as master to 2 as slave; and back
>>> again with 2 as master and 1 as slave.
>>>
>>> Now when the whole system is started up, we sometimes
>>> have problems and the replication stops:
>>> The reason is in the 'subscriber' table:
>>>
>>> 1. A new UA registers at the primary server 1. The
>>> data is stored in the local MySQL as well. Fine.
>>> 2. Then there is the SIP-Invite-Replicate to server 2,
>>> there again the data is stored in the local MySQL.
>>> Fine.
>>> 3. Now MySQL replication kicks in and tries to
>>> replicate the record from server 1 to 2. Unfortunately
>>> a record with same primary index exists already in
>>> server 2, but sometimes with a different timestamp.
>>> -> So replication fails and the "slave" process in
>>> server 2 stops.
>>>
>>> Do you know a way to overcome this?
>>>
>>> Can MySQL be configured to ignore errors (like this)
>>> in a replication?
>>>
>>> Thanks in advance!
>>> Gerhard
>>>
>>>
>>>
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam protection around 
>>> http://mail.yahoo.com
>>> _______________________________________________
>>> Serusers mailing list
>>> serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>  
>>>
>>
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
> .
>




More information about the sr-users mailing list