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

Re: 2.0.27 replicating to 2.2.15

Pierangelo Masarati wrote:

Curt Blank wrote:

This was only temporary. In order to convert the backend to Berkley I did a slapcat/slapadd and was using replication across the versions to keep the 2.2 server up to date until it could be placed in service as the master. However I see now that did not work. Problem is, I cannot afford the downtime to slapadd the new 2.2 master.

In principle (although possibly going off-topic), I don't see a big problem in temporarily shutting down the master, because the read service is guaranteed by the slaves. Only writes are temporarily disabled, but I'd consider it a minor limitation, given the extent of the changes you're working at. But I understant that's not my business.

No, no problem, I don't either, if it worked this way, unfortunately in our environment it doesn't. Some applications, because they don't know how to handle a referral if they got one attempting to update a slave are hardcoded to go to the Master because they need to do updates, so those applications would be offline. (They won't accept a secondary server in the config either.) But, you got me thinking that I could temporarily point them at the Slave and still keep the applications running for the most part. Going off topic can be good, I never do mind when it happens.

The other way round, i.e. a 2.2 master replicating to 2.0 slaves should be easier because in 2.2 you can filter out the operational attributes that the 2.2 master routinely generates but earlier slaves wouldn't accept. The topic has already been iscussed, you may find something by browsing the mail archives. In any case, you need to look at the "attr" parameter of the "replica" statement in 2.2's slapd.conf(5) man page.

This is the intent for only as long as it takes to rotate in slaves upgraded to 2.2 once the Master was at 2.2. So, will attr!=structuralObjectClass work when replicating from a 2.2 Mater to a 2.0 Salve?

It should. I vaguely remember trying (just for fun) but it worked. Note that 2.2 is also replicating entryUUID and entryCSN, which 2.0 is not aware of.

Thank you, that was the kind of information I was hoping for.

(Short term.) Should there be a structuralObjectClass: account associated with every dn in the database or is that just used for replication protocol?

The structuralObjectClass attribute is operational; it's computed by selecting the structural objectClass in the objectClass chain of the entry.

To be able to get the 2.2 server running temporarily as a slave so I can slapadd it and then get replication from the 2.0 server, how hard/risky would it be for me to modify the code so that the 2.2 server bypasses this requirement? (Temporarily, until it is installed as the Master.) Or would this not be recommended at all?

In principle, you could have the structuralObjectClass computed as it is for regular adds. I wouldn't see this as a critical issue, and this should be an easy hack. Just look at where it's computed for regular adds (I think it's computed by mods_structural_class() in slap_mods_opattrs()).

Thank you for this suggestion, I will look into that.

My main concern is that 2.0 was quite loose in schema compliance checks if compared to 2.2; so writes coming from the 2.0 master might fail some check (e.g. if more than one structuralObjectClass is defined, which was tolerated in 2.0, mods_structural_class() in 2.2 will barf).

Tell me about it! Getting slapadd to work in the first place 2.0->2.2 was no cake walk. Many schema changes both to home grown schema and vendor supplied, obviously this came as a surprise to many.

But I found this (let the screaming begin):

int       global_schemacheck = 1; /* schemacheck ON is default */

If I were to temporarily:

int       global_schemacheck = 0;

Then turn it back on once all servers were at 2.2, how hosed would I be? With it off would
structuralObjectClass still be computed and set for new entries? Or any entries for that matter?

Thanks again for the reply.

Just as a sidebar, I was wondering if you would explain why this structuralObjectClass: account for replication was added? Is it something I really need?

Slapd needs it, but you shouldn't bother with it, except when you design your entry and decide what objectClasses it will be based upon. Hope I clarified a bit the issue.


SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497