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