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

Re: 2.0.27 replicating to 2.2.15



Kurt D. Zeilenga wrote:

At 02:06 PM 3/23/2005, Curt Blank wrote:


Thank you for your reply.

Yeah I was leaning towards one of your three solutions as a temporary fix so I could do the upgrade. Before I attempt it though (already been looking at the code) and target the structuralObjectClass issue and optimistically say successfully address it, anything else then going to bite me in the butt?



The problem with your upgrade approach, as I see it, is that the
2.0 server may not only have bad data in it, clients may
continually be adding bad data to it.  So, even if you were to
modify slurpd(8) (I don't recommend solutions (1) or (3)) to
generate structualObjectClass values, you have to deal data for
which slurpd(8) can deal with programmatically.

I recommend (2) over (1) and (3) because it keeps the (temporary)
hacks out of the servers. I recommend against (3) as that would
lead to the hacks becoming permanent, it would (in effect) back
out many of the data consistency bug fixes that 2.2 was intended
to address.


Thanks. I don't want to leave any hacks in so #2 does sound the best.

Personally, I prefer to either replacing everything at once
(which can be done quite quickly if necessary... and, if done
right, allows for switching back if something were to go wrong)
or to replace master first.


My only problem here is time, even if I built a 2.2 Master and a Slave ahead of time I would still have to do the data conversion via slapcat/slapadd from the 2.0 to the 2.2 Berkley. And on top of that I have to edit the output from slapcat, and you guessed it, correct and/or remove a lot of bad or no longer needed data. That would cause a large outage for applications that do updating. Not the end of the world but an inconvenience and I may have to bite the bullet and go that route.

I've been digging through a lot of this stuff to gain an understanding and like Pierangelo said I see that I would have to deal with structuralObjectClass, entryUUID, and entryCSN. Is there any explanation whitepaper, RFC, etc. that I could read up on these attributes? I'd really like to read up on how these deal with data integrity (I assume that is their purpose). It appears entryUUID and entryCSN are generated values, I suppose I could cut and paste the code, but I'm leaning more and more towards taking the down time.

I really thought I could do this replication trick to the 2.2 server keeping it current until we were ready to pop it in as the Master but these three attributes and their underlying purpose definitely throw a monkey wrench in that idea.

I take it the Master generates the values for these three attributes and saves them and then places them in the Transactions.log to be replicated so that the Master and all the slaves match. If so I would have to grab that code from 2.2 slapd and put it into my 2.0 slurpd so I could do the 2.0->2.2 replication and make slurpd smart enough to only add it when replicating to 2.2 servers and not 2.0 servers. Not sure I want to attempt that yet.

Kurt



Kurt D. Zeilenga wrote:



At 12:44 PM 3/23/2005, Curt Blank wrote:




I've got a 2.0.27 server set up as Master replicating via slurp to a 2.2.15 slave server. Modifications are being replicated properly but adds are not, the new dn is not added, I see this error message:

bdb_add: entry failed schema check: no structuralObjectClass operational attribute (80)

Unfortunately I do have updatedn and rootdn set the same. I see in the 2.2 documentation that shouldn't be done but the existing environment is 2.0 and it was not a constraint there, at least according to the the 2.0 Admin Manual.

So, anyone know if making the updatedn and rootdn different will solve this problem?


The problem has nothing to do with the updatedn and the rootdn.

2.0 simply does not produce everything that 2.2 expects to be
present in the replication stream.  There are three obvious
solutions to this problem.
     1) modify the 2.0 slapd(8) to provide what 2.2 slapd(8) expects.
     2) modify the 2.0 or 2.2 slurpd to provide what 2.2 slapd(8) expects.
     3) modify the 2.2 slapd(8) not to require information not provided
     by the 2.0 slapd(8).

The devil is in the details, of course.

Kurt