Reputation: 2352
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.
Upvotes: 4
Views: 1716
Reputation: 384
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/
Upvotes: 2
Reputation: 1115
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:
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.
Upvotes: 4