Thanks a lot. That will help me sleep easier :) I'll check indices, schemachecking & the schema elements for may/must.

Thanks,
Amol Kulkarni.

On Fri, Nov 28, 2014 at 12:49 AM, Michael Ströder <michael@stroeder.com> wrote:
Howard Chu wrote:
> Amol Kulkarni wrote:
>> I've a openldap 2.4.30 syncrepl setup which is used by our applications.
>> There are over 50 servers in the setup.
>> I want to upgrade our application to the next version. In a single
>> downtime, all servers cannot be upgraded. So the application will be
>> upgraded in phase wise manner. Application upgrade requires some changes
>> in ldap schemas. I want to update the schemas in same phases as the
>> application so as to avoid separate downtime for schema update. I'm
>> planning to update schema on the consumers first and provider last so
>> that during the phases, some servers with old schemas and others with
>> new schemas both replicate properly.
>
> That's fine.

I'd also start with the consumers.

>> schemachecking is set to off on all servers.
>
> That's dangerous. You have no idea how long garbage data will persist in the
> system.

I'd also rather try not to disable schema checking.

Note that with some older versions (IIRC 2.4.31) in my setup slapd providers
crashed when slapd consumers noticed a schema problem and took down connection
immediately. Yes, the provider.

>> I'm not using cn=config - if that is a consideration.
>
> Makes no difference.

Hmm, with static configuration schema elements can be easily *removed*. Which
is the trickier thing to deal with. In general I recommend not to remove
schema elements but rather use OBSOLETE in the schema description (see RFC
4512). Even using OBSOLETE there are some corner cases though.

So first check whether the application changes removes schema elements or even
alter from MAY to MUST or similar.

Ciao, Michael.