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).

-jd




> 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