Re: Correct way to load LDIF in mirrormode

[Peter Mogensen <apm@mutex.dk>]

Pierangelo Masarati wrote:
> Howard Chu wrote:
> > Peter Mogensen wrote:
> > > masarati@aero.polimi.it wrote:
> > > > - load server 1 using slapadd with option -S (the SID of server 1) 
> > > > and -w
> > > >
> > > > - slapcat server 1
> > > >
> > > > - slapadd server 2 using the slapcat from server 1
> > > >
> > > > this ensures you have consistent entryCSN and contextCSN
> > >
> > > Ahh...
> > > That's of course right.
> > > But that will also more than double the time needed to load a backup 
> > > on a mirrormode setup.
> >
> > This procedure should only be needed if the LDIF doesn't already contain
> > correct CSNs. If you're loading a backup from a 2.4 slapcat you can just
> > slapadd it on all servers at once.
>
> My understanding is that he was loading LDIF from 2.3, which has a 
> different format for CSN.  So the first run with -S and -w was intended 
> to initialize CSN info in 2.4 format with the SID of the first master. 
> This would probably require to remove entryCSN values from the original 
> LDIF.

I've done as above.
"slapadd -S 1 -q -w" on server-1 (Server-ID 1)

Then slapcat on server-1

I would have expected the entryCSN values in the output to now be with 
SID 1, but they look like this:
entryCSN: 20071214130312.000000Z#000000#000#000000

Then contextCSN is also with SID 0:
contextCSN: 20090929120520.000000Z#000000#000#000000

Though that surpised me I impirted the LDIF to server-2 (SID 2) and
replication seems to work.
However, after the first change from server-1 has been replicated to 
server-2, there are now 2 contextCSN's on server-2:
entryCSN: 20071214130312.000000Z#000000#000#000000
contextCSN: 20090929120520.000000Z#000000#000#000000
contextCSN: 20091112161735.074445Z#000000#001#000000

... the last one with SID 1.

This is not the behaviour I would have expected.

/Peter