Bagian sebelumnya - Langkah-langkah pembuatan GlusterFS
Artikel ini menjelaskan dua masalah GlusterFS yang mungkin Anda alami dan memberikan langkah-langkah untuk menyelesaikannya:
- Menyembuhkan volume yang direplikasi
- Memperbaiki masalah otak terbelah
Sembuhkan volume yang direplikasi
Saat bata apa pun dalam volume yang direplikasi menjadi offline, glusterd daemon pada node yang tersisa melacak semua file yang tidak direplikasi ke bata offline. Saat bata offline tersedia lagi, cluster memulai proses penyembuhan, mereplikasi file yang diperbarui ke bata itu. Awal proses ini dapat memakan waktu hingga 10 menit, berdasarkan pengamatan.
Anda dapat melihat informasi tentang file mana yang akan direplikasi dengan menjalankan perintah berikut:
gluster volume heal volumeName info
Anda dapat melihat informasi tentang file yang direplikasi selama proses pemulihan. Anda juga dapat melihat informasi tentang file yang diubah secara independen di node offline (otak terpisah), atau file yang gagal direplikasi karena alasan apa pun. Tambahkan opsi berikut ke perintah sebelumnya:
gluster volume heal volumeName info healed
gluster volume heal volumeName info heal-failed
gluster volume heal volumeName info split-brain
Anda juga dapat memaksa penyembuhan secara manual dengan menjalankan perintah berikut. Jika Anda menggunakan argumen opsional full , semua file yang tidak ditandai sebagai perlu dipulihkan juga disinkronkan.
gluster volume heal volumeName
Opsional:
gluster volume heal volumeName full
Memperbaiki masalah otak terbelah
otak terbelah masalah terjadi ketika salah satu node yang direplikasi menjadi offline (atau terputus dari cluster), dan file di salah satu batanya diperbarui. Setelah node bergabung kembali dengan cluster GlusterFS, proses penyembuhan gagal karena konflik yang disebabkan oleh dua versi file yang berbeda.
Dalam contoh berikut, masalah ini dipicu secara manual dan kemudian diperbaiki. Node yang disebut gluster4 terputus, dan salah satu file yang disimpan di batanya diubah:
[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)
Sekarang proses penyembuhan dipicu:
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
Perhatikan bahwa testfile.txt file terdaftar, yang berarti bahwa GlusterFS tidak tahu versi file mana yang benar. Penting untuk memperbaiki masalah ini karena dapat membingungkan klien dan menyebabkan mereka mogok.
Setiap bata GlusterFS memiliki folder tersembunyi, glusterfs , yang berisi ID GlusterFS heksadesimal (GFID) dari setiap file sebagai tautan hard-code. Dalam contoh kita, gluster4 adalah replika dari node gluster1. Contoh berikut menunjukkan GFID dari testfile.txt pada gluster1 dan 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
Di salah satu node, file itu sendiri, serta file GFID terkait (dalam hal ini, a702251d-e4c5-47e2-ba2f-96b896a43718), harus dihapus dari mount yang mendasarinya. Hanya dengan begitu proses penyembuhan dapat dipicu lagi. Sangat penting untuk memahami salinan file mana yang ingin Anda simpan. Jika memungkinkan, simpan salinan lengkap file ke lokasi di luar GlusterFS, hapus file dari semua node, picu proses pemulihan, dan salin file kembali ke titik pemasangan. Metode ini lebih kasar, tetapi berfungsi jika proses penyembuhan masih tidak dapat memperbaiki file dengan benar melalui replikasi.
[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
Bagian berikutnya - GlusterFS HA dan penyeimbangan beban