[Date Prev][Date Next]
Re: 2.0.27 replicating to 2.2.15
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.
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.
(Short term.) Should there be a structuralObjectClass: account
associated with every dn in the database or is that just used for
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
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).
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