30 Aug
2012
30 Aug
'12
10:29 a.m.
On 2012-08-30 at 10:09, Daniel-Constantin Mierla wrote:
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.
--
Øyvind Kolbu
On 8/29/12 9:15 PM, Øyvind Kolbu wrote:
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.
On 2012-08-29 at 20:16, Daniel-Constantin Mierla
wrote:
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. is usrloc module configured in db only mode?
Yes, db_mode is 3. 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.