Fedora Account System
Red Hat Associate
Red Hat Customer
Document URL: A new command for resetting an existing brick in the volume is provided. Usage: gluster v reset-brick <volname> <hostname:brick-path> start This command kills the brick to be reset. Once this command is run, admin can do other manual operations that they need to do, like configuring some options for the brick. Once this is done, resetting the brick can be continued with the following options. gluster v reset-brick <volname> <hostname:brick-path> <hostname:brick-path> commit {force} Does the job of resetting the brick. 'force' option should be used when the brick already contains volinfo id. Section Number and Name: Describe the issue: Suggestions for improvement: Additional information:
Hi Laura, I am providing information about reset-brick command. Please let me know if it clear and sufficient. reset-brick command is used for following cases - 1 - To replace a brick when source and destination "path" of the bricks are same. As of now replace-brick for the same "brick-path" is not allowed. reset-brick will provides the functionality to replace a brick even when source and destination <hostname:brickpath> are identical as long as - - Source brick is not alive. - Source and destination brick have the same brick uuid and path. 2 - Administrator can do other manual operations, like configuring some options for the brick. Usage : This command works in two steps. Step 1. Kill a brick you want to replace or configure. This cam be done using following command - gluster v reset-brick <volname> <hostname:brick-path> start. This command kills the brick to be reset. Step 2. Resetting the brick can be continued with the following options- gluster v reset-brick <volname> <hostname:brick> <hostname:brick> commit {force}
Hi Laura, I have reviewed the document and provided my comments. Ashish
*** Bug 1365842 has been marked as a duplicate of this bug. ***
Hi Laura, I have reviewed the steps you asked for and it looks fine. I have provided my comment also. Ashish
Can you just flip these two sentences? The reset-brick subcommand lets you replace a brick with another brick of the same location and UUID. This is useful when you want to reconfigure a brick, rather than when you want to replace it with a new one. >>> This command is useful when you want to reconfigure a brick, rather than when you want to replace it with a new one. The reset-brick subcommand lets you replace a brick with another brick of the same location and UUID. In step-3, while checking the volume id, to get volume id of brick we have to do following - cat /var/lib/glusterd/vols/<volume name>/<volume name>.<hostname>.<brick path>.vol | grep volume-id Example : cat /var/lib/glusterd/vols/vol/vol.apandey.brick-gluster-vol-1.vol | grep volume-id if the vol info is - Volume Name: vol Type: Disperse Volume ID: ab8a981a-a6d9-42f2-b8a5-0b28fe2c4548 Status: Started Snapshot Count: 0 Number of Bricks: 1 x (4 + 2) = 6 Transport-type: tcp Bricks: Brick1: apandey:/brick/gluster/vol-1
I have reviewed the content and I have found it correct.
I am seeing below issues: 1) we need to talk about reset brick works for both replicate and disperse volume 2)--force is invalid, instead use just force 3) when to use force and when not to use force 4) make the example, if possible more generic, else admin can think it is only for disperse volume
Also document some warnings or recommendations as below: 1) make sure no heals are pending 2) IOs to be stopped if possible 3) minimum quorum is met, for example in a ec volume of 4+2 , make sure that the brick being reset is done when there are atleast another 4 bricks online and in a 1x2 volume when there is another healthy brick online. the above must be recommendations rather than force
Ashish, Nag, I have a few questions with regard to Nag's comments: @ Ashish: > 1) we need to talk about reset brick works for both replicate and disperse volume Does reset-brick only work with specific volume types? If so we need to specify. reset-brick works for all the volumes types. @Nag @Ashish: > Also document some warnings or recommendations as below: > 1) make sure no heals are pending > 2) IOs to be stopped if possible > 3) minimum quorum is met, for example in a ec volume of 4+2 , make sure that > the brick being reset is done when there are atleast another 4 bricks online > and in a 1x2 volume when there is another healthy brick online. > > the above must be recommendations rather than force @Nag: Do you mean that we should make these recommendations instead of telling people to use the force keyword in their command? Or do you mean that this is recommended not required? I assumed the latter for this text. @Ashish, is this an appropriate first/prerequisite step? "If possible, ensure that I/O has stopped, no heal operations are pending on the volume and the quorum minimum will still be met when the brick that you want to reset is taken offline." This is a mix of suggestions and prerequisite. Minimum quorum should match but stopping IO is a suggestion. Considering Heal operation depends on the file and bricks which need to be healed. Final text should be reviewed again. Re. the rest of Nag's comments: > 2)--force is invalid, instead use just force Done, thanks for the catch. > 3) when to use force and when not to use force We discuss this under "Bring the reconfigured brick back online." > 4) make the example, if possible more generic, else admin can think it is > only for disperse volume That is possible but unlikely as we do not specify that this can only work for a particular volume type and it is a brick command rather than a volume command. I think this should be fine, assuming that it works for all volume types - checking with Ashish above. reset-brick command works for all the volume type. However, the suggestions or necessary steps might differ for different volumes.
1 - This line is correct but does not give complete picture. "The reset-brick sub command is useful when you want to reconfigure a brick rather than replace it." Actually, reset-brick was introduce to modify a brick on a <brickpath> _without_ modifying its path on a node/server. You can reconfigure that brick. You can change the hostname to ip and vice versa. That gives one more use case of this command. Which, if we explain, could be a physical "replace brick". Suppose we want to physically replace a brick from a path /home/brick/brick-1 but want to keep the same path and hostname and everything. May be hard drive has been damaged. In this case we have to follow the same steps. - gluster volume reset-brick VOLNAME HOSTNAME:BRICKPATH start - remove brick physically from the same path. - attach and mount a brick on the same path. - gluster volume reset-brick VOLNAME HOSTNAME:BRICKPATH HOSTNAME:BRICKPATH commit This is one example or use case. I don't know where and how to give this information.
looks good to me
Moving to CLOSED CURRENTRELEASE since RHGS 3.2 GA was yesterday. All documentation is available from https://access.redhat.com/documentation/en/red-hat-gluster-storage/.