State Snapshot Transfer (SST) adalah salah satu dari dua cara yang digunakan oleh Galera untuk melakukan sinkronisasi awal ketika sebuah node bergabung dengan sebuah cluster, hingga node tersebut dinyatakan tersinkronisasi dan menjadi bagian dari "komponen utama". Bergantung pada ukuran set data dan beban kerja, SST bisa secepat kilat, atau operasi mahal yang akan membuat layanan database Anda lesu.
SST dapat dilakukan menggunakan 3 metode berbeda:
- mysqldump
- rsync (atau rsync_wan)
- xtrabackup (atau xtrabackup-v2, mariabackup)
Sebagian besar waktu, xtrabackup-v2 dan mariabackup adalah opsi yang lebih disukai. Kami jarang melihat orang yang menjalankan rsync atau mysqldump di cluster produksi.
Masalahnya
Ketika SST dimulai, ada beberapa proses yang dipicu pada node joiner, yang dijalankan oleh pengguna "mysql":
$ ps -fu mysql
UID PID PPID C STIME TTY TIME CMD
mysql 117814 129515 0 13:06 ? 00:00:00 /bin/bash -ue /usr//bin/wsrep_sst_xtrabackup-v2 --role donor --address 192.168.55.173:4444/xtrabackup_sst//1 --socket /var/lib/mysql/mysql.sock --datadir
mysql 120036 117814 15 13:06 ? 00:00:06 innobackupex --no-version-check --tmpdir=/tmp/tmp.pMmzIlZJwa --user=backupuser --password=x xxxxxxxxxxxxxx --socket=/var/lib/mysql/mysql.sock --galera-inf
mysql 120037 117814 19 13:06 ? 00:00:07 socat -u stdio TCP:192.168.55.173:4444
mysql 129515 1 1 Oct27 ? 01:11:46 /usr/sbin/mysqld --wsrep_start_position=7ce0e31f-aa46-11e7-abda-56d6a5318485:4949331Saat berada di node donor:
mysql 43733 1 14 Oct16 ? 03:28:47 /usr/sbin/mysqld --wsrep-new-cluster --wsrep_start_position=7ce0e31f-aa46-11e7-abda-56d6a5318485:272891
mysql 87092 43733 0 14:53 ? 00:00:00 /bin/bash -ue /usr//bin/wsrep_sst_xtrabackup-v2 --role donor --address 192.168.55.172:4444/xtrabackup_sst//1 --socket /var/lib/mysql/mysql.sock --datadir /var/lib/mysql/ --gtid 7ce0e31f-aa46-11e7-abda-56d6a5318485:2883115 --gtid-domain-id 0
mysql 88826 87092 30 14:53 ? 00:00:05 innobackupex --no-version-check --tmpdir=/tmp/tmp.LDdWzbHkkW --user=backupuser --password=x xxxxxxxxxxxxxx --socket=/var/lib/mysql/mysql.sock --galera-info --stream=xbstream /tmp/tmp.oXDumYf392
mysql 88827 87092 30 14:53 ? 00:00:05 socat -u stdio TCP:192.168.55.172:4444SST terhadap kumpulan data besar (ratusan GByte) tidak menyenangkan. Bergantung pada perangkat keras, jaringan, dan beban kerja, mungkin perlu waktu berjam-jam untuk menyelesaikannya. Sumber daya server mungkin jenuh selama operasi. Meskipun pelambatan didukung di SST (hanya untuk xtrabackup dan mariabackup) menggunakan opsi --rlimit dan --use-memory, kami masih dihadapkan pada cluster yang terdegradasi saat Anda kehabisan mayoritas node aktif. Misalnya, jika Anda kurang beruntung karena hanya satu dari tiga node yang berjalan. Oleh karena itu, Anda disarankan untuk melakukan SST pada jam-jam tenang. Namun, Anda dapat menghindari SST dengan mengambil beberapa langkah manual, seperti yang dijelaskan dalam entri blog ini.
Menghentikan SST
Menghentikan SST perlu dilakukan pada node donor dan joiner. Penggabung memicu SST setelah menentukan seberapa besar kesenjangan ketika membandingkan seqno Galera lokal dengan seqno cluster. Itu mengeksekusi wsrep_sst_{wsrep_sst_method} memerintah. Ini akan dipilih oleh donor terpilih, yang akan mulai mengalirkan data ke joiner. Node donor tidak memiliki kemampuan untuk menolak melayani transfer snapshot, setelah dipilih oleh komunikasi grup Galera, atau oleh nilai yang ditentukan dalam wsrep_sst_donor variabel. Setelah sinkronisasi dimulai dan Anda ingin mengembalikan keputusan, tidak ada perintah tunggal untuk menghentikan operasi.
Prinsip dasar saat menghentikan SST adalah:
- Membuat joiner terlihat mati dari sudut pandang komunikasi grup Galera (shutdown, fence, blok, reset, cabut kabel, daftar hitam, dll)
- Bunuh proses SST pada donor
Orang akan berpikir bahwa mematikan proses innobackupex (kill -9 {innobackupex PID}) pada donor sudah cukup, tetapi bukan itu masalahnya. Jika Anda mematikan proses SST pada donor (atau joiner) tanpa membatasi joiner, Galera masih dapat melihat joiner sebagai aktif dan akan menandai proses SST sebagai tidak lengkap, sehingga memunculkan kembali serangkaian proses baru untuk melanjutkan atau memulai lagi. Anda akan kembali ke titik awal. Ini adalah perilaku yang diharapkan dari skrip /usr/bin/wsrep_sst_{method} untuk melindungi operasi SST yang rentan terhadap waktu habis (misalnya, jika berjalan lama dan intensif sumber daya).
Mari kita lihat sebuah contoh. Kami memiliki node joiner yang rusak yang ingin kami gabungkan kembali dengan cluster. Kita akan mulai dengan menjalankan perintah berikut pada joiner:
$ systemctl start mysql # or service mysql startSemenit kemudian, kami menemukan bahwa operasinya terlalu berat pada saat itu, dan memutuskan untuk menundanya nanti selama jam lalu lintas rendah. Cara paling mudah untuk menghentikan metode SST berbasis xtrabackup adalah dengan mematikan node joiner, dan mematikan proses terkait SST pada node donor. Atau, Anda juga dapat memblokir port masuk pada joiner dengan menjalankan perintah iptables berikut pada joiner:
$ iptables -A INPUT -p tcp --dport 4444 -j DROP
$ iptables -A INPUT -p tcp --dport 4567:4568 -j DROPKemudian pada donor, ambil PID dari proses SST (daftar proses yang dimiliki oleh pengguna "mysql"):
$ ps -u mysql
PID TTY TIME CMD
117814 ? 00:00:00 wsrep_sst_xtrab
120036 ? 00:00:06 innobackupex
120037 ? 00:00:07 socat
129515 ? 01:11:47 mysqldTerakhir, matikan semuanya kecuali proses mysqld (Anda harus sangat berhati-hati untuk TIDAK mematikan proses mysqld pada donor!):
$ kill -9 117814 120036 120037Kemudian, pada log kesalahan MySQL donor, Anda akan melihat baris berikut muncul setelah ~100 detik:
2017-10-30 13:24:08 139722424837888 [Warning] WSREP: Could not find peer: 42b85e82-bd32-11e7-87ae-eff2b8dd2ea0
2017-10-30 13:24:08 139722424837888 [Warning] WSREP: 1.0 (192.168.55.172): State transfer to -1.-1 (left the group) failed: -32 (Broken pipe)Pada titik ini, donor harus kembali ke status "disinkronkan" seperti yang dilaporkan oleh wsrep_local_state_comment dan proses SST benar-benar dihentikan. Donor kembali ke kondisi operasionalnya dan mampu melayani klien dalam kapasitas penuh.
Untuk proses pembersihan pada joiner, Anda cukup menyiram rantai iptables:
$ iptables -FAtau cukup hapus aturan dengan flag -D:
$ iptables -D INPUT -p tcp --dport 4444 -j DROP
$ iptables -D INPUT -p tcp --dport 4567:4568 -j DROPPendekatan serupa dapat digunakan dengan metode SST lain seperti rsync, mariabackup, dan mysqldump.
Membatasi SST (hanya metode xtrabackup)
Bergantung pada seberapa sibuk donor, ini adalah pendekatan yang baik untuk membatasi proses SST sehingga tidak akan berdampak signifikan pada donor. Kami telah melihat sejumlah kasus di mana, selama kegagalan bencana, pengguna putus asa untuk mengembalikan cluster yang gagal sebagai node bootstrap tunggal, dan membiarkan anggota lainnya menyusul nanti. Upaya ini mengurangi waktu henti dari sisi aplikasi, namun, ini menciptakan beban tambahan pada "kluster satu simpul" ini, sementara anggota yang tersisa masih tidak aktif atau pulih.
Xtrabackup dapat dibatasi dengan --throttle=
[sst]
rlimit=128k
inno-apply-opts="--use-memory=200M"Detail selengkapnya di halaman dokumentasi Percona Xtrabackup SST.
Namun, ada tangkapan. Prosesnya bisa sangat lambat sehingga tidak akan pernah mengejar log transaksi yang ditulis InnoDB, jadi SST mungkin tidak akan pernah selesai. Secara umum, situasi ini sangat jarang terjadi, kecuali jika Anda benar-benar memiliki beban kerja yang sangat intensif menulis atau Anda mengalokasikan sumber daya yang sangat terbatas ke SST.
Kesimpulan
SST sangat penting tetapi berat, dan berpotensi menjadi operasi yang berjalan lama tergantung pada ukuran kumpulan data dan throughput jaringan antara node. Terlepas dari konsekuensinya, masih ada kemungkinan untuk menghentikan operasi sehingga kami dapat memiliki rencana pemulihan yang lebih baik di waktu yang lebih baik.
