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.
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.
If this indeed is impossible I've have to continue our current scheme with SIP level replication.