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

Re: Two contextCSNs

Howard Chu wrote:
Peter Mogensen wrote:
I'm trying to understand why changes made to SID 1 in my mirror set
while SID 2 is down does not get propagated to SID 2 when it comes up.

You've posted quite a lot of stuff on that topic already, but nothing useful that could help anyone else to see what you're actually doing. (E.g., such essentials as your software version, config files, and the actual commands/operations you perform in the precise sequence you execute them.)

Before I posted config, I had hoped to get the precise sequence of steps (including commands) I posted which I used to load the data verified as the correct procedure. I have posted versions and command sequences. (version is currently 2.4.20 + patch for ITS#6408 and DB4.8)
The config is the same as in ITS #6365

If the last operation that occurred on that server was a Delete, then
the contextCSN will be the CSN of that Delete operation, but obviously there will not be any entry in the server with that CSN.

Hmm.. I did no delete, but maybe syncrepl did. Why I can't figure out given the procedure I used:

1) Took an slapcat generated LDIF from a 2.3.x setup
2) Removed all entryCSN and contextCSN lines.
3) Ran "slapadd -S 1 -q -w -l ~/load_noCSN.ldif" on server-1
4) Did a "slapcat > toserver2.ldif" on server-1
5) Started server-1 and let applications create and modify objects.
6) Moved toserver2.ldif to server-2.
7) Ran slapadd -q -l toserver2.ldif on server-2
8) Started server-2