[Date Prev][Date Next] [Chronological] [Thread] [Top]

direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)

[moved to -devel]

On Mon, 2005-11-21 at 13:05 -0500, John Madden wrote:
> > Maybe we could use something like this:
> > - the chain overlay attaches a control to the chained write that
> > contains the entryUUID and the entryCSN
> > - the producer processes the write; upon success, if the entryUUID and
> > the entryCSN were the same, it returns a control response value that
> > indicates the consumer can directly apply the write.
> I wonder if Berkeley has any of this solved for us.  If perhaps a separate lock
> manager process can attach to the DB environment and lock records, a process
> outside of slapd could deal with locking on the request of the node of the
> "cluster" wishing to write to an object.

I wouldn't go that way, because we'd depend too much on something that
is BDB specific; we'd open the door to deadlock issues; 

> Or could there be delegation of authority of objects?  In other words, upon
> entrance into the cluster, the existing nodes negiotiate which pieces of the
> directory are to be delegated to which nodes, who are then responsible for
> maintaining their piece.  Every node has a complete replica of the directory, but
> only serve authoritatively the piece that has been delegated to them and become
> clients, connecting to the other nodes for the other pieces, regardless of write
> or read (a sort of internal referral, one the client never sees).  If a client is
> suddenly unreachable, negotiation is forced again among the remaining nodes.  I
> don't know what the contents of the entryUUID are, but perhaps this could be used
> to determing which entries are controlled by which nodes.  All changes are either
> slurp'd or syncrepl'd to each node as normal.

Something like this has been discussed recently; the idea was to have
something like moving the granularity of master to the entries; each
entry would have a mastership token and the server willing to modify an
entry would request that token to the server it owns.  I think Kurt
loosely committed to digging up some old docs about this.

I think the point is that we don't necessarily need something like
commit after all shadows confirm they successfully received the change:
this would not be a viable solution: too much overhead for the advantage
it brings on regular operations.  The single master replication model,
and the syncrepl protocol, ensure convergence to data consistency; that
is, data is consistent, but there might be delays in propagation.  One
of the performance penalties of the referral mechanism is that it
requires one extra write with respect to so-called multimaster.  The
solution outlined above would eliminate this extra write, but only in
those cases this can be safely done, i.e. after the master confirms that
the change can be applied, and it supplies the bits of info that only
the master can generate, i.e. the entryUUID and the createTimestamp for
adds, the modifyTimestamp for updates, and the entryCSN for all.

Note that this approach wouldn't solve the problem of load balancing,
because a write would be available after successful return only on the
producer and on the consumer that processed the request; the other
consumers would be updated according to replication schedule, so if the
read successive to a write is delegated to another shadow by the load
balancer, the write would not be in place yet.


Ing. Pierangelo Masarati
Responsabile Open Solution

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it