[Date Prev][Date Next]
Re: syncrepl questions
--On Wednesday, September 24, 2003 10:59 PM -0700 "Kurt D. Zeilenga"
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.
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html