Antw: Replication through BDB

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

>>> Rick van Rein <rick@openfortress.nl> schrieb am 08.12.2016 um 22:37 in
Nachricht <5849D28D.8050408@openfortress.nl>:
> Hello,
> 
> I've been thinking about replication schemes lately.  I very much like
> SyncRepl, especially that it can be used in master-master mode, but it
> also has a downside -- it returns before a majority of replicated
> servers have agreed on a change.  One might say that the change is
> committed before certainty has been established.

It seems you are mixing a quorum protocol with a synchronisation protocol: RAID1 with sequential (not parallel) writes has the same weaknesses, BTW.

if a change was committed to one server, the change is there; certainly. What is your "certainty"?

> 
> This is different with the replication scheme that is now built into
> BerkeleyDB, by Oracle; this has a scheme based on majority voting, and
> with automatic resumption after downtime based on this majority.  The
> BerkeleyDB will not return cheerfully from a commit until a majority has
> confirmed.

Generally the majority can be wrong: Assume you have a network-failure in a three-node MMR configuration: You update one node while the other two are unreachable. The communication resumes, do you expect the change on the none node to be reverted to majority, or should the majority be updated from the one node that has more recent data?

> 
> AFAIK the HDB backend that was once the default for OpenLDAP has been
> replaced with the plain vanilla BerkeleyDB... so it seems that the
> replication scheme of the latter can be used.  Is that right / does
> anyone see problems with that / ...?

Oracle licensing conditions may be a different thing.
Despite of all that LDAP replication is not done at the database level.

Was the intention of your message to say: "Oracle has the better databases"?

Regards,
Ulrich