Glusterfs cluster distributed file system off the brick processing

We recently found a Brick dropped in a gluster distributed file system cluster that has been running for about half a year. Volume Name: web-volumeType: ReplicateVolume ID: cd9bf5ad-1b5f-404b-8279-6de12b8838ecStatus: StartedNumber of Bricks: 1 x 3 = 3Transport-type: tcpBricks:Brick1: 10.48.83.204:/data/gfsBrick2: 10.48.83.200:/Data/gfsBrick3: 10.48.83.196:/data/gfsStatus of volume: web-volumeGluster process Port Online Pid——————————————&mdash ;———————————Brick 10.48.83.204:/data/gfs 49152 Y 1791Brick 10.48.83.200:/data/gfs 49152 Y 17406Brick 10.48.83.196: /data/gfs N/ANN/A

This node is an SSD disk, which is caused by IO failures due to SSDs. We decided to take the node offline and replace it with a new SSD. Our GFS file system content data did not affect the replacement process. This is due to GlusterFS, which is not what we want to express today. Today we mainly talk about how to rejoin the new SSD node brick into the cluster. 1. Mount /data/of node 196. 2. We need to first get the file extension attribute of GFS (on the normal node), as follows: [[email protected] ~]# getfattr -d -m ‘. *’ /data/gfsgetfattr: Removing leading ‘/’ from absolute path names# file: data/gfstrusted.afr.web-volume-client-0=0sAAAAAAAAAAAAAAAAtrusted.afr.web-volume-client-1=0sAAAAAAAAAAAAAAAAtrusted. Afr.web-volume-client-2=0sAAAAAAAAAAAAAAAAtrusted.gfid=0sAAAAAAAAAAAAAAAAAAAAAQ== ; get the value of trusted.gfidtrusted.glusterfs.dht=0sAAAAAQAAAAAAAAAA/////w==trusted.glusterfs.volume-id=0szZv1rRtfQEuCeW3hK4g47A== Get the value of trusted.glusterfs.volume-id 3. Set the gfs folder extension property of 196 as follows: setfattr -n trusted.glusterfs.volume-id -v 0szZv1rRtfQEuCeW3hK4g47A== /data/gfssetfattr -n trusted.gfid -v 0sAAAAAAAAAAAAAAAAAAAAAQ== /data/gfs4. Restart the GFS service {/etc/init.d/glusterd restart}5.@196 Execute getfattr -d -m ‘.*’ /data/gfs; Join! The data will be synchronized like Raid1, and if your cluster is striped, it will be the same.