7 Sep
2005
7 Sep
'05
4:43 a.m.
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
7 Sep
7 Sep
5:24 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
5:46 a.m.
Hi Bogdan,
your option 2, ignoring the error in MySQL works fine.
Thanks a lot.
However I cannot find the mentioned save_mem()
function.
I tried to google it with:
"save_mem site:iptel.org"
But without success. In which versions of ser should
save_mem be present?
Regards,
Gerhard
--- Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>
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:
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6 a.m.
Hi Gerhard,
actually the correct name is save_memory() (in registrar module). I
guess the latest stable has it.
regards,
bogdan
Gerhard Zweimüller wrote:
Hi Bogdan,
your option 2, ignoring the error in MySQL works fine.
Thanks a lot.
However I cannot find the mentioned save_mem()
function.
I tried to google it with:
"save_mem site:iptel.org"
But without success. In which versions of ser should
save_mem be present?
Regards,
Gerhard
--- Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>
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:
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6:16 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6:30 a.m.
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:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7:24 a.m.
Just replicate the tables you need to be replicated. Do not replicate
the whole database.
klaus
Iqbal wrote:
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:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7:44 a.m.
Iqbal wrote:
but then how do you replicate the other tables
Klaus Darilion wrote:
> Another option: Do not replicate the mysql data bases.
You can replicate the other tables in one direction, just leave out the
usrloc tables like location and aliases and replicate them on SIP level.
Right before startup of one SER perform a mysqldump of the usrloc tables
from the running peer and you should be fine (well, in fact you'd loose
the registrations coming in at the peer between the start of the dump
and the end of preloading the tables in usrloc module).
Andy
7:59 a.m.
Hi there,
double replication (SIP and DB) is good if you avoid DB double insertion
(via save_memory). The idea is to keep having replication even if the
backup proxy is down (to maintain for example) when SIP replication
doesn't work anymore. In such a case, the DB replication will keep
updating the location table and when the backup machine will be
restarted, it will be perfect sincronized from the beginning.
regards,
bogdan
Andreas Granig wrote:
Iqbal wrote:
but then how do you replicate the other tables
Klaus Darilion wrote:
You can replicate the other tables in one direction, just leave out
the usrloc tables like location and aliases and replicate them on SIP
level.
Right before startup of one SER perform a mysqldump of the usrloc
tables from the running peer and you should be fine (well, in fact
you'd loose the registrations coming in at the peer between the start
of the dump and the end of preloading the tables in usrloc module).
Andy
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Another option: Do not replicate the mysql data
bases.
7023
days inactive
7023
days old
8 comments
5 participants
participants (5)
-
Andreas Granig -
Bogdan-Andrei Iancu -
Gerhard Zweim�ller -
Iqbal -
Klaus Darilion