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

Re: syncrepl questions

--On Wednesday, September 24, 2003 10:59 PM -0700 "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote:

I've changed back to persist mode, which is where I started at.  If
syncrepl is not suited to large scale deployments/deployments with
frequent updates, does this mean the various ITS's against slurpd will
be dropped back into the queue to be fixed, instead of suspended?

First, I note, there is no "queue to be fixed". I did move a number of ITS from Historic to Incoming, but left them Suspended. I might later move some of them to Software Bugs. Of course, whether or not the reports are eventually addressed has little to do with the categorization or status of the ITS. Developers contribute per their own desires.

Second, we just started this Syncrepl experiment.  I suspect
Syncrepl will prove to be better than the slurpd approach
in almost all deployments.  I also suspect that some deployments
will need a far more sophisticated replication engine than either
syncrepl and slurpd provide.

I just want to be clear that I'm not criticizing the idea of syncrepl. I like it, and I would prefer to use it over slurpd. I'm just thinking of things that I think should be made clear when the 2.2 release is official.

syncrepl in persistent mode is working successfully for me now on our development systems, although I am not currently able to test it under the conditions we have in production. I agree about a more sophisticated engine to be in place eventually. Observationally, Netscape kept a store of changes from the time the server was loaded with the DB until it next got reloaded (which would, for us, be when it next corrupted itself). I think that strategy is a bit overkill. Our general strategy has been nightly stop/starts of the master. This allows us to export the DB, and clear up the resources that slapd & slurpd slowly eat over the course of a day. In the bit that Jong was talking about a log store, I was wondering if it'd be useful to have the store record changes between restarts of the server. There is of course some issues with that as well.


-- Quanah Gibson-Mount Principal Software Developer ITSS/TSS/Computing Systems Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html