upgrade process?

John D. Rowell me at jdrowell.com
Tue Nov 23 23:28:11 EST 2010

2010/11/23 David Smith <dizzyd at basho.com>

> On Tue, Nov 23, 2010 at 8:58 AM, Colin Surprenant
> <colin.surprenant at gmail.com> wrote:
> >
> > Would upgrading (rolling or offline) sequentially from 0.10 to 0.11 to
> > 0.12 be "easier" to manage potential compatibility issues?
> As on of my colleagues (Grant) just pointed out to me, a rolling
> upgrade of 0.10 -> 0.13 won't work due to some internal messaging
> changes; you'll need to take the whole cluster down after all.
> However, I do not know of any major changes to the storage formats
> (particularly with innostore), so you should be able to just upgrade
> in place and bring the cluster back up.
> As I said before, though, testing it would be a wise idea. :) (Yes,
> there's a pattern here...:))
> > I'm using innostore, with a 3 nodes cluster holding ~250GB of data
> > each. Using the riak-admin backup/restore is just too slow to be
> > usable in my environment. Would innodump/innoload be any faster? Could
> > I consider setting up a new 0.13 ring, use innodump on my 0.10 nodes
> > and innoload on the 0.13??
> innodump is going to be much faster than riak-admin backup, I believe,
> since it's dumping data at a much lower-level.
> Yes, you could setup a whole new cluster...but that really shouldn't
> be necessary.  If I were backing up your cluster, here's what I would
> do (off the cuff):
> 1. Take down one node at a time and innodump the data so I have a
> known good backup

If you're taking each node down, why not simply backup the filesystem
instead of using innodump? Restoring the filesystem should work just as
well, right? That way you'd have a backend agnostic procedure that would
also be faster and you'd always backup the ring state (less steps).


> 2. For each node, backup the ring and any other config info
> 3. Take down cluster; upgrade in place (i.e. try to use the existing
> config, ring and data)
> 4. Bring cluster back up
> 4a. If there are problems when bringing cluster back up, revert to
> previous version/config. Data _should_ be ok, but if push comes to
> shove you'll have to reload via innoload.
> As noted before, test..test..test before doing this in a production
> environment. :)
> D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20101124/2b202ca8/attachment.html>

More information about the riak-users mailing list