Hi Tom I'd be very interested to know if Shane's approach should work, or if you know of any good reason why that approach would cause issues.
Also, aren't there several very real business use cases here that users of Riak will inevitably encounter, and must be able to satisfy? Shane mentions two use cases below: creation of a test environment using a copy of data from a production cluster; and the migration of data within one cloud provider from one set of systems to a distinct, separate set of systems. To add to this, what about the case where a Riak customer needs to move from one cloud provider to another? How does this customer take his data with him? All of the above cases require that a separate cluster be spun up from the original cluster, with different names and IP addresses for the Riak nodes involved in the cluster. None of these use cases are satisfied by using the riak-admin cluster command. It seemed that this was the purpose of the reip command, but if Basho is poised to deprecate this command, and indeed no longer recommends its use, how are the previous cases supported? Surely these are important scenarios for users of Riak, and therefore Basho? At one level, it seems it should be entirely possible to simply copy the data directory from each Riak node and tell Riak that the node names and IP addresses have changed (reip!). So what's the problem with doing this? Regards, Martin. On 13 November 2012 17:16, Thomas Santero <tsant...@basho.com> wrote: > Hi Shane, > > I'm sorry for the delay on this. Over the weekend I was working to > replicate your setup so I can answer your question from experience. Alas, > time got the best of me and I have not yet finished. > > That said, I'm inclined to suggest upgrading riak on your current cluster > first and then using riak-admin replace to move off of the VM's and onto > metal. > > * In this scenario, do a rolling upgrade (including making backups) of the > current cluster. > * Install riak onto the new machines > * join the first machine to the cluster > * use riak-admin replace to replace one of the old nodes with the new node > * wait for ring-ready, then repeat for the other nodes. > > Tom > > > On Tue, Nov 13, 2012 at 11:59 AM, Shane McEwan <sh...@mcewan.id.au> wrote: > >> Anyone? Beuller? :-) >> >> Installing Riak 1.1.1 on the new nodes, copying the data directories from >> the old nodes, issuing a "reip" on all the new nodes, starting up, waiting >> for partition handoffs to complete, shutting down, upgrading to 1.2.1 and >> starting up again got us to where we want to be. But this is not very >> convenient. >> >> What do I do when I come to creating our test environment where I'll be >> wanting to copy production data onto the test nodes on a regular basis? At >> that point I won't have the "luxury" of downgrading to 1.1.1 to have a >> working "reip" command. >> >> Surely there's gotta be an easier way to spin up a new cluster with new >> names and IPs but with old data? >> >> Shane. >> >> >> On 08/11/12 21:10, Shane McEwan wrote: >> >>> G'day! >>> >>> Just to add to the list of people asking questions about migrating to >>> 1.2.1 . . . >>> >>> We're about to migrate our 4 node production Riak database from 1.1.1 to >>> 1.2.1. At the same time we're also migrating from virtual machines to >>> physical machines. These machines will have new names and IP addresses. >>> >>> The process of doing rolling upgrades is well documented but I'm unsure >>> of the correct procedure for moving to an entirely new cluster. >>> >>> We have the luxury of a maintenance window so we don't need to keep >>> everything running during the migration. Therefore the current plan is >>> to stop the current cluster, copy the Riak data directories to the new >>> machines and start up the new cluster. The hazy part of the process is >>> how we "reip" the database so it will work in the new cluster. >>> >>> We've tried using the "riak-admin reip" command but were left with one >>> of our nodes in "(legacy)" mode according to "riak-admin member-status". >>> From an earlier E-Mail thread[1] it seems like "reip" is deprecated and >>> we should be doing a "cluster force replace" instead. >>> >>> So, would the new procedure be the following? >>> >>> 1. Shutdown old cluster >>> 2. Copy data directory >>> 3. Start new cluster (QUESTION: The new nodes don't own any of the >>> partitions in the data directory. What does it do?) (QUESTION: The new >>> nodes won't be part of a cluster yet. Do I need to "join" them before I >>> can do any of the following commands? Or do I just put all the joins and >>> force-replace commands into the same plan and commit it all together?) >>> 3. Issue "riak-admin cluster force-replace old-node1 new-node1" >>> (QUESTION: Do I run this command just on "new-node1" or on all nodes?) >>> 4. Issue "force-replace" commands for the remaining three nodes. >>> 5. Issue a "cluster plan" and "cluster commit" to commit the changes. >>> 6. Cross fingers. >>> >>> In my mind the "replace" and/or "force-replace" commands are something >>> we would use it we had a failed node and needed to bring a spare online >>> to take over. It doesn't feel like something you would do if you don't >>> already have a cluster in place and are needing to "replace" ALL nodes. >>> >>> Of course, we want to test this procedure before doing it for real. What >>> are the risks of doing the above procedure while the old cluster is >>> still running? While the new nodes are on a segregated network and >>> shouldn't be able to contact the old nodes what would happen if we did >>> the above and found the network wasn't as segregated as we originally >>> thought? Would the new nodes start trying to communicate with the old >>> nodes before the "force-replace" can take effect? Or, because all the >>> cluster changes are atomic there won't be any risk of that? >>> >>> Sorry for all the questions. I'm just trying to get a clear procedure >>> for moving an entire cluster to new hardware and hopefully this thread >>> will help other people in the future. >>> >>> Thanks in advance! >>> >>> Shane. >>> >>> [1] >>> http://comments.gmane.org/**gmane.comp.db.riak.user/8418<http://comments.gmane.org/gmane.comp.db.riak.user/8418> >>> >>> >>> ______________________________**_________________ >>> riak-users mailing list >>> riak-users@lists.basho.com >>> http://lists.basho.com/**mailman/listinfo/riak-users_**lists.basho.com<http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com> >>> >> >> ______________________________**_________________ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/**mailman/listinfo/riak-users_**lists.basho.com<http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com> >> > > > > -- > @tsantero <https://twitter.com/#!/tsantero> > Technical Evangelist > Basho Technologies > 347-571-3995 > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
