I too would like to know about this. I also tried this process on my 3.2.7 cluster and reported my findings here: http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3/
No reply as of yet... Not wanting to sound negative, but I do find there's little support from the Gluster sites/community on issues such as this. Especially compared to other projects I've seen. It's not very reassuring for a film-system in which we're supposed to trust with our precious data. For this reason - we are looking to migrate away from Gluster after using it for 3+ years. It's a shame - and I was a believer (still think it's a great idea) - but we can't afford to carry on groping around in the dark (with sparse documentation, obscure error messages & a low-bandwidth community) any more. :/ Still interested to hear if / how we can upgrade by hand (if need be). Would certainly help me in the interim - might even change my mind (not having seen 3.4 in action).. :) On 21 February 2014 13:22, Dmitry Kopelevich <dkopelev...@che.ufl.edu>wrote: > I would like to follow up on my question regarding an upgrade from 3.2.6 > to 3.4.2. > Can anybody tell me whether I'm doing something completely wrong? Am I > trying to skip too many versions of gluster in my upgrade? Is CentOS 5 too > old for this? > > Thanks, > > Dmitry > > On 2/18/2014 2:51 PM, Dmitry Kopelevich wrote: > > I am attempting to upgrade my GlusterFS from 3.2.6 to 3.4.2 using the > instructions posted at > http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3. These > guidelines are for an upgrade to 3.3 but it is stated at > http://vbellur.wordpress.com/2013/07/15/upgrading-to-glusterfs-3-4 that > they can also be used to upgrade to 3.4.0. So I was hoping that they would > also work with an upgrade to 3.4.2. > > I'm running CentOS 5 and installed the following rpms on the gluster > servers: > > glusterfs-libs-3.4.2-1.el5.x86_64.rpm > glusterfs-3.4.2-1.el5.x86_64.rpm > glusterfs-fuse-3.4.2-1.el5.x86_64.rpm > glusterfs-cli-3.4.2-1.el5.x86_64.rpm > glusterfs-server-3.4.2-1.el5.x86_64.rpm > glusterfs-rdma-3.4.2-1.el5.x86_64.rpm > glusterfs-geo-replication-3.4.2-1.el5.x86_64.rpm > > According to the installation guidelines, installation from rpms should > automatically copy the files from /etc/glusterd to /var/lib/glusterd. This > didn't happen for me -- the directory /var/lib/glusterd contained only > empty subdirectories. But the content of /etc/glusterd directory has moved > to /etc/glusterd/glusterd. > > So, I decided to manually copy files from /etc/glusterd/glusterd to > /var/lib/glusterd and follow step 5 of the installation guidelines (which > was supposed to be skipped when installing from rpms): > > glusterd --xlator-option *.upgrade=on -N > > This didn't work (error message: glusterd: No match) > > Then I tried specifying explicitly the name of my volume: > > glusterd --xlator-option <volume>.upgrade=on -N > > This lead to the following messages in file etc-glusterfs-glusterd.vol.log: > > [2014-02-18 17:22:27.146449] I [glusterd.c:961:init] 0-management: Using > /var/lib/glusterd as working directory > [2014-02-18 17:22:27.149097] I [socket.c:3480:socket_init] > 0-socket.management: SSL support is NOT enabled > [2014-02-18 17:22:27.149126] I [socket.c:3495:socket_init] > 0-socket.management: using system polling thread > [2014-02-18 17:22:29.282665] I > [glusterd-store.c:1339:glusterd_restore_op_version] 0-glusterd: retrieved > op-version: 1 > [2014-02-18 17:22:29.283478] E > [glusterd-store.c:1858:glusterd_store_retrieve_volume] 0-: Unknown key: > brick-0 > [2014-02-18 17:22:29.283513] E > [glusterd-store.c:1858:glusterd_store_retrieve_volume] 0-: Unknown key: > brick-1 > [2014-02-18 17:22:29.283534] E > [glusterd-store.c:1858:glusterd_store_retrieve_volume] 0-: Unknown key: > brick-2 > ... > and so on for all other bricks. > > After that, files nfs.log, glustershd.log, and > etc-glusterfs-glusterd.vol.log get filled with a large number of warning > messages and nothing else seems to happen. The following messages appear to > be relevant: > > - Files nfs.log, glustershd.log: > > 2014-02-18 15:58:01.889847] W [rdma.c:1079:gf_rdma_cm_event_handler] > 0-data-volume-client-2: cma event RDMA_CM_EVENT_ADDR_ERROR, error -2 (me: > peer:) > > (the name of my volume is data-volume and its transport type is RDMA) > > - File etc-glusterfs-glusterd.vol.log > > [2014-02-18 17:22:33.322565] W [socket.c:514:__socket_rwv] 0-management: > readv failed (No data available) > > Also, for some reason the time stamps in the log files are incorrect. > > Any suggestions for fixing this would be greatly appreciated. > > Thanks, > > Dmitry > > -- > Dmitry Kopelevich > Associate Professor > Chemical Engineering Department > University of Florida > Gainesville, FL 32611 > > Phone: (352)-392-4422 > Fax: (352)-392-9513 > E-mail: dkopelev...@che.ufl.edu > > > > _______________________________________________ > Gluster-users mailing list > Gluster-users@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users >
_______________________________________________ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users