GlusterFSのトラブルシューティング

スプリットブレイン 問題は、レプリケートされたノードの1つがオフラインになる（またはクラスターから切断される）ときに発生し、そのブリックの1つにあるファイルが更新されます。ノードがGlusterFSクラスターに再参加した後、ファイルの2つの異なるバージョンが原因で競合が発生したため、修復プロセスが失敗します。

次の例では、この問題は手動でトリガーされてから修正されています。 gluster4というノード が切断され、ブリックに保存されているファイルの1つが変更されます：

[root@gluster1 ~]# cat /mnt/gluster/gvol0/testfile.txt
This is version 1 of the file

[root@gluster4 ~]# ifdown eth2

##Wait just a little bit for the other nodes to see it disconnected

[root@gluster1 ~]# gluster peer status | grep -A2 glus4
Hostname: glus4
Uuid: 734aea4c-fc4f-4971-ba3d-37bd5d9c35b8
State: Peer in Cluster (Disconnected)

[root@gluster4 ~]# echo "This is new content" >> /var/lib/gvol0/brick4/testfile.txt

[root@gluster4 ~]# cat /var/lib/gvol0/brick4/testfile.txt
This is version 1 of the file
This is new content

[root@gluster1 ~]# cat /mnt/gluster/gvol0/testfile.txt
This is version 1 of the file

[root@gluster4 ~]# ifup eth2

##Wait just a little bit for the other nodes to see it reconnected

[root@gluster1 ~]# gluster peer status | grep -A2 glus4
Hostname: glus4
Uuid: 734aea4c-fc4f-4971-ba3d-37bd5d9c35b8
State: Peer in Cluster (Connected)

これで、修復プロセスがトリガーされます：

gluster volume heal gvol0 full

gluster volume heal gvol0 info split-brain
Gathering list of split brain entries on volume gvol0 has been successful

Brick glus1:/var/lib/gvol0/brick1
Number of entries: 1
at                    path on brick
-----------------------------------
2014-05-16 19:55:19 /testfile.txt

Brick glus2:/var/lib/gvol0/brick2
Number of entries: 0

Brick glus3:/var/lib/gvol0/brick3
Number of entries: 0

Brick glus4:/var/lib/gvol0/brick4
Number of entries: 0

[root@gluster1 ~]# cat /mnt/gluster/gvol0/testfile.txt
cat: /mnt/gluster/gvol0/testfile.txt: Input/output error

[root@gluster4 ~]# cat /mnt/gluster/gvol0/testfile.txt
cat: /mnt/gluster/gvol0/testfile.txt: Input/output error

testfile.txtに注意してください ファイルが一覧表示されます。これは、GlusterFSがファイルのどのバージョンが正しいかを認識していないことを意味します。クライアントを混乱させ、クラッシュさせる可能性があるため、この問題を修正することが重要です。

各GlusterFSブリックには、隠しフォルダー glusterfsがあります。 、ハードコードされたリンクとして各ファイルの16進数のGlusterFS ID（GFID）が含まれています。この例では、gluster4はgluster1ノードのレプリカです。次の例は、 testfile.txtのGFIDを示しています。 gluster1とgluster4について：

[root@gluster1 ~]# getfattr -m . -d -e hex /var/lib/gvol0/brick1/testfile.txt
# file: var/lib/gvol0/brick1/testfile.txt
trusted.afr.gvol0-client-0=0x000000000000000000000000
trusted.afr.gvol0-client-1=0x000000000000000000000000
trusted.afr.gvol0-client-2=0x000000000000000000000000
trusted.afr.gvol0-client-3=0x000000000000000000000000
trusted.gfid=0xa702251de4c547e2ba2f96b896a43718

[root@gluster4 ~]# getfattr -m . -d -e hex /var/lib/gvol0/brick4/testfile.txt
# file: var/lib/gvol0/brick4/testfile.txt
trusted.afr.gvol0-client-0=0x000000000000000000000000
trusted.afr.gvol0-client-1=0x000000000000000000000000
trusted.afr.gvol0-client-2=0x000000000000000000000000
trusted.afr.gvol0-client-3=0x000000000000000000000000
trusted.gfid=0xa702251de4c547e2ba2f96b896a43718

ノードの1つで、ファイル自体と関連するGFIDファイル（この場合はa702251d-e4c5-47e2-ba2f-96b896a43718）を基になるマウントから削除する必要があります。そうして初めて、癒しのプロセスを再びトリガーすることができます。保存するファイルのコピーを理解することが重要です。可能であれば、ファイルの完全なコピーをGlusterFSの外部の場所に保存し、すべてのノードからファイルを削除し、修復プロセスをトリガーして、ファイルをマウントポイントにコピーして戻します。この方法はより野蛮な力ですが、修復プロセスがレプリケーションによってファイルを適切に修正できない場合に機能します。

[root@gluster4 ~]# rm -vf /var/lib/gvol0/brick1/.glusterfs/a7/02/a702251d-e4c5-47e2-ba2f-96b896a43718
[root@gluster4 ~]# rm -vf /var/lib/gvol0/brick1/testfile.txt
[root@gluster4 ~]# gluster volume heal gvol0 full

[root@gluster1 ~]# cat /var/lib/gvol0/brick1/testfile.txt
This is version 1 of the file

[root@gluster4 ~]# cat /var/lib/gvol0/brick4/testfile.txt
This is version 1 of the file

次のセクション -GlusterFSHAと負荷分散