【場景1】某個GlusterFS節點的操作系統Down，需要重裝系統和GlusterFS的場景。
解決辦法如下：
（1）先別啓動GlusterFS服務
重新安裝GlusterFS後，設置好對應的Brick目錄和掛載完對應的存儲，暫時別啓動GlusterFS服務。
（2）獲取該節點UUID信息
通過觀察集羣的其他節點保存的節點UUID信息，得到損壞節點的UUID信息。
ls命令查看一個完好節點的“/var/lib/glusterd/peers”目錄，可以看到該集羣其他節點所有的UUID，如圖1所示。
圖1
逐個觀察各完好節點的本身UUID信息（cat /var/lib/glusterd/peers glusterd.info），如圖2所示。
圖2
結合圖1進行排除，就可以損壞節點的原UUID信息。
（3）在損壞節點配置原UUID信息
在/var/lib/glusterd/peers目錄下，新建glusterd.info，按圖2的格式，將原UUID和operating-version信息寫入該文件。
（4）重啓GlusterFS服務
（5）在該節點執行“gluster peer probe gf6”命令探測完好節點。
（6）在該節點執行“gluster peer status”命令觀察存儲池的狀態，如圖3所示。
圖3
在第（5）步命令中那個完好的節點（gf6），也執行“gluster peer status”命令觀察存儲池的狀態，如圖4所示。
圖4
可以看到損壞的節點（gf2）在存儲池節點的狀態爲“Peer Rejected (Connected)”。
（7）重啓損壞節點（gf2）的GlusterFS服務
在兩個節點分別觀察存儲池節點的狀態，應該可以發現損壞的節點，已經正常連接到存儲池中。
（8）觸發該節點進行數據同步
在客戶端的掛載點使用ls命令遍歷集羣目錄，該節點就啓動文件自愈功能，從老的備份節點將數據同步過來。
注意：當數據較大時，整個同步過程較爲耗時。
（9）測試損壞節點是否可寫文件
在客戶端的掛載目錄，新建多個文件，觀察新建的文件能否寫在該節點上。
測試如下：通過touch命令，新建數個文件。
圖5
在原來損壞的節點的brcik目錄下觀察能否寫入文件
圖6
【場景2】日誌轉儲
GlusterFS 3.6版本默認配置了日誌轉儲功能，日誌轉儲的配置保存在/etc/logrotate.d/下。如不存在按以下步驟新建相應的配置文件。
注意：CentOS6.3 Minimal版本因官方遺漏cron，會導致日誌轉儲功能失效，解決辦法是手動安裝cronie的包。
在/etc/logrotate.conf文件，可以配置日誌轉儲的週期、日誌保持的時間、是否壓縮日誌
在/etc/logrotate.d/目錄，可以查看哪些服務配置了日誌轉儲的。GlusterFS配置的文件如下圖所示，對glusterd、glusterfsd、glusterfs-fuse和glusterfs-georep進行轉儲。
初始的glusterd配置爲：
通過logrotate –d –f /etc/logrotate.d/glusterd調試觀察配置是否生效。
【場景3】替換損壞的Brick
在備份集羣中，假設gf4節點出現故障，無法啓動GlusterFS服務，而gf5是個備用的節點，準備好gf5的存儲和brcik相應的目錄，使用replace-brick命令替換損壞節點的brcik
命令如下：glustervolume replace-brick testvol gf4:/srv/sdb1/brick gf5:/srv/sdb1/brick commitforce
testvoI是卷名，gf4:/srv/sdb1/brick是已損壞的brcik，gf5:/srv/sdb1/brick是新的brcik
命令執行後，等待數據的同步，可以觀察gf5的/srv/sdb1/brick目錄查看同步好的數據。數據較大的情況下，同步過程也較久，請耐心待replace-brick命令的執行。
