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 contextCSNAhh... 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 justslapadd 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-1I 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.