Re: Correct way to load LDIF in mirrormode

[Pierangelo Masarati <masarati@aero.polimi.it>]

Peter Mogensen wrote:
> 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.

What happened is that slapadd simply converted the existing 2.3 CSNs to 
2.4 format while keeping their value.  The fact the first contextCSN 
(generated by slapadd) has SID 000 is expected, since the contextCSN is 
computed as the largest entryCSN (one for each SID that appears in the 
database's entryCSN).

At this point, you should:

- take the LDIF slapcat from server-1
- manually modify all SIDs to 001 (e.g. using sed or whatever)
- reload the LDIF into server-1

Now you have a properly initialized server-1.

p.