[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-technical
Subject:    Re: syncrepl and change in ordering
From:       Amol Kulkarni <amolk112k () gmail ! com>
Date:       2014-11-28 6:25:18
Message-ID: CABhJRgMvJzGNZVT8FzQ8wv9t5wp9+97r06ApKJ5BhMuTgqK5ww () mail ! gmail ! com
[Download RAW message or body]

["attachment.htm" (text/html)]

<div dir="ltr"><div>Thanks a lot. That will help me sleep easier :) I&#39;ll check \
indices, schemachecking &amp; the schema elements for \
may/must.<br><br></div>Thanks,<br>Amol Kulkarni.<br></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 28, 2014 at 12:49 AM, \
Michael Ströder <span dir="ltr">&lt;<a href="mailto:michael@stroeder.com" \
target="_blank">michael@stroeder.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Howard Chu wrote:<br> <span class="">&gt; Amol Kulkarni \
wrote:<br> &gt;&gt; I&#39;ve a openldap 2.4.30 syncrepl setup which is used by our \
applications.<br> &gt;&gt; There are over 50 servers in the setup.<br>
&gt;&gt; I want to upgrade our application to the next version. In a single<br>
&gt;&gt; downtime, all servers cannot be upgraded. So the application will be<br>
&gt;&gt; upgraded in phase wise manner. Application upgrade requires some changes<br>
&gt;&gt; in ldap schemas. I want to update the schemas in same phases as the<br>
&gt;&gt; application so as to avoid separate downtime for schema update. I&#39;m<br>
&gt;&gt; planning to update schema on the consumers first and provider last so<br>
&gt;&gt; that during the phases, some servers with old schemas and others with<br>
&gt;&gt; new schemas both replicate properly.<br>
&gt;<br>
&gt; That&#39;s fine.<br>
<br>
</span>I&#39;d also start with the consumers.<br>
<span class=""><br>
&gt;&gt; schemachecking is set to off on all servers.<br>
&gt;<br>
&gt; That&#39;s dangerous. You have no idea how long garbage data will persist in \
the<br> &gt; system.<br>
<br>
</span>I&#39;d also rather try not to disable schema checking.<br>
<br>
Note that with some older versions (IIRC 2.4.31) in my setup slapd providers<br>
crashed when slapd consumers noticed a schema problem and took down connection<br>
immediately. Yes, the provider.<br>
<span class=""><br>
&gt;&gt; I&#39;m not using cn=config - if that is a consideration.<br>
&gt;<br>
&gt; Makes no difference.<br>
<br>
</span>Hmm, with static configuration schema elements can be easily *removed*. \
Which<br> is the trickier thing to deal with. In general I recommend not to \
remove<br> schema elements but rather use OBSOLETE in the schema description (see \
RFC<br> 4512). Even using OBSOLETE there are some corner cases though.<br>
<br>
So first check whether the application changes removes schema elements or even<br>
alter from MAY to MUST or similar.<br>
<br>
Ciao, Michael.<br>
<br>
</blockquote></div><br></div>



[prev in list] [next in list] [prev in thread] [next in thread]