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

Re: Correct way to load LDIF in mirrormode

Peter Mogensen wrote:

Pierangelo Masarati wrote:

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.

Ahh... -S is only for generated CSN's.

Correct.  The idea is that if an entry already has a CSN, you'd like to 
preserve it, at least in the portion that indicates when it was last 
changed.  Having entries whose CSN has a SID of 0 in your setup should 
not be an issue by itself; my fear is that it may result in some "not 
mine" issues, that's why I'd suggest to turn single-master entryCSN into 
MM entryCSN by forcing their SID to that of the first server.

But if I'm loading the same data into both servers in a mirromode setup, 
then I shouldn't really have any use for the old CSN values, should I?
So instead of sed/perl chaing the CSN's I could just remove them from 
the LDIF and let sladadd generate new ones?

That's another option; you'd lose the real modification date, but this 
might be a minor issue as soon as you intend to start with a fresh system.

It strikes my that there should be an FAQ about this (loading a backup 
from one server setup into another with different SID/RIDs).

There should be some discussion in the mailing lists (option -S was 
added based on something related to this, namely the need to use a 
specific SID to initialize entryCSN during LDIF import).  I'm not aware 
of specific FAQs on this exact topic.

p.