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 <[email protected]> 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. > >
