Hey folks, 

I'll be doing an upgrade soon for my core hypervisors running qemu 2.0 built 
with Gluster 3.5.2 connecting to a replicated 3.5.2 volume. 
The upgrade path I'd like to do is: 
1. migrate all machines to node not being upgraded 
2. prevent client heals as documented over at 
http://www.gluster.org/community/documentation/index.php/Upgrade_to_3.6 
3. stop gluster server and gluster processes on node being upgraded 
4. upgrade kvm, gluster, and supporting packages to required to 3.6.3 
5. restart node being upgraded 
6. Node joins pool again except one node will be running 3.6.3 and the other 
3.5.2 
7. perform heal to ensure data correct 
8. migrate all machines over to newly upgraded node 
9. repeat steps 3-5 for other node 
10. perform heal to ensure data correct 
11. rebalance machines as necessary 
12. upgrade complete 

This method has the obvious issue of will the two nodes behave as expected when 
on different major versions with the gain of no downtime for vm's. Is this 
method too risky? Has anyone tried it? Would appreciate any input. 

Thanks, 
Josh 
_______________________________________________
Gluster-users mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-users

Reply via email to