On 8/30/12 10:29 AM, Øyvind Kolbu wrote:
On 2012-08-30 at 10:09, Daniel-Constantin Mierla
wrote:
On 8/29/12 9:15 PM, Øyvind Kolbu wrote:
On 2012-08-29 at 20:16, Daniel-Constantin Mierla
wrote:
is usrloc module configured in db only mode?
Yes, db_mode is 3.
this might not be very suitable for db_cluster usage if
one db server is
done, because right now the reading is done to the first available server.
I
choose 3 because of the usrloc documentation: «The mode is useful if you
configure more servers sharing the same DB without any replication at SIP
level.» As I want multiple servers to write to the same database it seemed
as the best option.
Yes, it is what it says, but you have two database servers. Your two
kamailios don't connect to a single instance of DB server.
No, you have to do some C coding. The target was
to offer high
availability to access a database server, when one is down, try next.
OK, will see
if I get the time to do that.
Perhaps you can add some cross replication at
database server layer.
Yes, I've asked our DBAs for that, but they are not
ready yet.
Hm,
perhaps I was a bit confused on how the affected rows works. Anyhow
if a row is missing on a secondary server the UPDATE will fail and it
will never be fixed with an INSERT.
IIRC, if the operation was successful,
affected rows checks the last
used connection. In a cluster, the operation is considered to be
successful when int succeeded on a db server node.
I think you are looking more for replication, rather that high
availability of the db layer. This is not done by db_cluster, if the
nodes are up, then all should be fine, but if one goes down and then
back up, its content is not synchronized, should be done by the db
server itself.
Yes, I actually want both, HA + replication, by using db_cluster as
the
replicator. And as I've demonstrated the location-table on non-primary
servers will lack entries after downtime, which is bad.
Replication is done with
parallel writing as long as all nodes are
available, but, better said, you look for re-synchronization after
downtime, which is another story, not easy to code, because it is db
specific.
If this indeed is impossible I've have to continue our current scheme with
SIP level replication.
If you use db mode 3, then you can do database level
replication, is the
same.
Daniel
--
Daniel-Constantin Mierla -
http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -
http://asipto.com/u/kat