[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: syncrepl simplification
--On Tuesday, January 11, 2005 8:22 PM -0800 Howard Chu <hyc@symas.com>
wrote:
If we restrict the implementation to using only one consumer per context,
then we can collapse the consumer contextCSN into the suffix entry, the
same as was done with the provider context. Then we don't need to mess
around with the slapadd options for promotion/demotion of
provider/consumer since the same contextCSN info is used in all cases.
This would allow us to remove the -p, -r, -w, and -i options from
slapadd, and save a lot of administrative overhead re:
promotion/demotion. (Actually I would keep the "-w" option to write the
contextCSN. Saves time for the provider, and allows the resulting
database to be slapcat'd and immediately slapadd'd into any consumers
without any more fuss.)
I'm not sure what should be done in the case where people slapadd multiple
files. This looks like you are assuming they will dump the master or a
replica, and then use that file to do a full load of another replica. I
think that is the only thing that makes a lot of sense with syncrepl, but
there are people who seem to be in the habit of batching slapadd's. In
that case, I'd think that slapadd would need to load whatever the existing
contextCSN in the DB is, and then compare that with the incoming entries to
make sure it has the correct contextCSN in the end.
Other than that, I'm all for the absolute simplification of syncRepl. ;)
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin