[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.)
Well...
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
http://www.openldap.org/its/index.cgi/Incoming?id=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
/Peter