John Morrissey wrote:
On Tue, Nov 11, 2008 at 02:18:10PM -0800, Quanah Gibson-Mount wrote:
--On Tuesday, November 11, 2008 4:35 PM -0500 John Morrissey jwm@horde.net wrote:
Instead of slapcat(8)/slapadd(8)ding the old databases, we're removing the existing databases and allowing slapd(8) to delta-syncrepl a copy from scratch. Ironing out this use case is especially important for us since we expect to be adding a number of consumers in the coming months and would obviously prefer to bring them online without having to shut down any other slapd instances for slapcat(8)ting.
Why would you have to shut down a server to slapcat it? Hot slapcatting has been supported for a long time.
Right, slapcat's man page indicates it's always safe to run against the bdb backend, but I suspect that's referring more to read concurrency and not necessarily the generation of a consistent, point-in-time snapshot of the database.
Empirically, slapcat output does not have a consistent view of the database while dumping it. Specifically, when slapcat is running and one changes an entry that hasn't been dumped yet, that change will appear in slapcat's output. Using slapadd's -w option would definitely be unsafe in this situation.
The -w option is only meant to be used when your LDIF does not already contain contextCSN values. There's no need to use it otherwise, and as you note, it would be detrimental in this case.
Without the -w option seems safe at first glance since the suffix entry's contextCSN will be older than any CSN in the generated LDIF. It seems that any syncrepl updates that have already been "applied" by virtue of the aforementioned slapcat behavior will simply be skipped since there will be no changes to the entry? Still, I couldn't find anything in the Administrator's Guide about this, and it feels like there's some concurrency case I'm not considering here, so I'd definitely appreciate hearing any thoughts you have on this.
slapcat/slapadd (no -w), let syncrepl figure out the rest.
We haven't upgraded our provider to 2.4 yet, since we wanted to get some consumers upgraded first. Would running a 2.4 provider with 2.3 consumers be OK? The contextCSN format changed to add fractional seconds; will that have any adverse impact on existing 2.3 consumers that try to continue syncrepling?
A recent enough 2.3 will accept 2.4-format CSNs.