[SR-Users] db_cluster together with the registrar module = signal 11

[Øyvind Kolbu]

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.

-- 
Øyvind Kolbu