4

Is it trivial? I will be using Bitcask and file backups (of the files on each node).

Let's say my initial ring size is 256 with 16 nodes. Now if I am required to expand to a ring of 1024, can I setup 16 new instances configured with a ring-size of 1024, copy the backup files for the old cluster into these 16 new instances and start Riak up? Will Riak be able to pick up this old data?

I guess not, since the partition ids and their mapping to individual nodes may also change once the ring size is changed. But what other way is there? Will riak-backup work in this case (when the ring size changes)?


I just want to know that the choice I've made is future-proof enough. Obviously at some point when the requirements change drastically or the user base balloons, the entire architecture might need to be changed. But I do hope to be able to make these sort of changes (to the ring size) at some point - naturally with SOME effort involved, but - without it being impossible.

Dev Kanchen
  • 2,332
  • 3
  • 28
  • 40

2 Answers2

4

Migrating clusters to a different ring size is difficult to do with node-based file backups (meaning, if you just back up the /data directories on each node, like it's recommended in Backing Up Riak). Because as you've suspected, the backend data files depend on the mapping of nodes and partitions to a given ring size.

What should you do instead?

You have to use "logical" backups of the entire cluster, using one of these two tools:

  1. riak-admin backup and restore (which does in fact work with clusters of different ring sizes), or
  2. the Riak Data Migrator

Using either one basically dumps the contents of the entire cluster into one location (so be careful not to run out of disk space, obviously). Which you can then transfer, and restore to your new cluster with a different ring size.

Things to watch out for:

  • Only do backups of non-live clusters. Meaning, either take the cluster down, or at least make sure no new writes are happening to the old cluster while backup is taking place. Otherwise, if you start backup but new writes are still coming in, there is no guarantee that they'll make it into the backed up data set.

  • Be sure to transfer the app.config and custom bucket settings to the new cluster before doing backup/restore.

Hopefully this helps. So, it's not trivial (meaning, it'll take a while and will require a lot of disk space, but that's true whenever you're transferring large amounts of data), but it's not extremely complicated either.

Dmitri Zagidulin
  • 1,117
  • 9
  • 23
  • Right, so the answer seems to be setup a replica cluster and using that as both a hot-swap option and backing up not-too-frequently from it to file. Expensive (in terms of instances) but I do not see another logical option. Thanks for the detail too! – Dev Kanchen Feb 26 '13 at 18:46
  • 1
    How do you get the replica-cluster working? Is there a way other than the prohibitively expensive riak-enterprise replication? – John Eikenberry Apr 29 '13 at 00:06
2

I know this is an old question, but with Riak 2.x it is now possible to resize the ring dynamically without shutting down the cluster:

riak-admin cluster resize-ring <new_size>

riak-admin cluster plan

riak-admin cluster commit

Note: The size of a Riak ring should always be a 2n integer, e.g. 16, 32, 64, etc.

http://docs.basho.com/riak/latest/ops/advanced/ring-resizing/

Felix Scheffer
  • 346
  • 2
  • 5
  • 4