Re: Replication between 2.2.x and 2.3.x

[Jed Donnelley <jed@nersc.gov>]

At 07:16 AM 5/31/2006, matthew sporleder wrote:
> On 5/31/06, FRLinux <frlinux@gmail.com> wrote:
> > Hello,
> >
> > We've been toying around quite a bit with 2.3 and we are very close to
> > move our master to the latest 2.3.x. Now the issue is that we have
> > slaves still using 2.2.x and as far as we can tell, it looks like it
> > is unhappy about trying to replicate from 2.3.x to 2.2.x.

What makes you think so?  What testing have you done to suggest that
your 2.3 master won't replicate to your 2.2 slaves?  Slurpd?  Syncrepl?
If Syncrepl, refresh-only?   See our configuration below.

> > Is there a way around this ?
>
> Try upgrading your replicas first.

Hmmm.   Depending on the software versions and replication methods
used we currently believe it's possible to upgrade the master first, though
our testing isn't yet complete.

We face this same situation.  For institutional reasons (many of our
replicas are run by other organizations) it's difficult for us to upgrade
our replicas first.

We are successfully running the following servers to test our
master first migration path:

   Production systems                               Test systems
2.2.29 Master production ldap   ---->   2.3.23 Slave | 
Master   ----->  2.2.30  Slave
  |           \                                                             /
Existing replicated production slaves (2.2.23, 2.2.24, 2.2.28, and 2.2.29)

All with syncrepl refresh only.  We've begun testing some of those other
2.2.x slave instances (test versions) with that 2.3.23 Slave | master.  So far
we haven't run into any problems.  Our slaves are all running openldap, but
on a variety of platforms.  If anybody knows of problems that we will be likely
to run into with this scenario I'd very much like to hear about them 
so we can focus
our testing efforts where such problems will be most likely to show up.

That system: 2.3.23 Slave | Master shown above is syncrepl replicating
from our 2.2.29 production master and is being used as a master to test
our existing slave versions.  Because it has all our production LDAP
data in it (including our watchdog timer updates) we can fairly easily see
if data gets out of sync in our test slaves.

When (if) we are satisfied with our testing our plan is to switch a new
2.3.x (likely 2.2.23 unless something comes up) master ldap server
into place by just taking over the IP address from the old server.  In our
situation we'll be able to stop updates to our LDAP database for
a short time (1-2 hours?) while we test this switch.  If problems come up
we can switch back and lick our wounds.

We are being driven to a switch to 2.3.x because our master occasionally
(perhaps once every two weeks on average) hangs up, requiring a consistency
run on the BerkeleyDB and then restarting of all our slaves.  This is a painful
operation (partly because of the slaves run by other organizations) that we
hope to get away from with the newer master.

I'd be happy to share experience with anybody trying to do a similar upgrade,
perhaps even to the extent of doing some testing on our testbed for problems
that others have run into if that would also help us to move forward - or not.
Naturally we don't want to spend time testing 2.2.x versions that are 
older than
what we're working with (see above diagram).

--Jed http://www.nersc.gov/~jed/