Peter Mogensen wrote:
Pierangelo Masarati wrote:
Peter Mogensen wrote:
Pierangelo Masarati wrote:
Howard Chu wrote:
Peter Mogensen wrote:
[email protected] 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.
