Re: upgrade 2.2.x -> 2.3.x, sync repl replica compatibility?

[Jed Donnelley <jed@nersc.gov>]

At 02:21 PM 3/28/2006, Howard Chu wrote:

Thanks for taking time to respond Howard.

> ...If you're running recent enough 2.2 code, any order should be 
> fine. Logically speaking, since you probably have many consumers and 
> only a few providers, the path of minimal impact is to change 
> consumers one at a time and change the provider last. Of course, it 
> may make sense to upgrade the least stable systems first, regardless 
> of consumer or provider role.

All our instances are 2.2.29 (or at least 2.2.28).  Is that recent 
enough?  All our replicas are running the Sync replication protocol 
in refresh only mode.

We have one relevant production master and many (~6) slaves.  Some of 
the slaves are under other administrative control.  For we who run 
the master and some of the slaves it's probably best to upgrade the 
master first after testing to insure that an upgraded master seems to 
function with all the slave types we know are out there (different 
OSs and hardware).  At least if we upgrade the master first we have a 
fairly simple backoff strategy.  Announce, upgrade, and wait to see 
if there's any fallout.  If there are problems then backup to our old 
2.2.29 master and regroup.  If there are no problems (watchdog timer 
resync, etc.) then we can upgrade the slaves one at a time.  It's the 
slaves that carry our production read load, so we can function with 
the master down for some time.

We expect to dump and restore the master database to and from LDIF 
format across the master upgrade.  All our slaves will have their 
watchdog timers go off, but that will be expected from the 
announcement.  I will be delighted if we get to the upgraded master 
as we've had continuing problems (perhaps once a month) with the 
master seemingly getting into some sort of CPU bound deadlock where 
we have to kill it hard and end up having to restart all the replicas 
- very embarrassing.  We're hoping that the upgrade to 2.3.20 will 
correct that problem.

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