Di salah satu blog sebelumnya, kami membahas fitur-fitur baru yang keluar di MariaDB 10.4. Kami menyebutkan di sana bahwa termasuk dalam versi ini akan menjadi rilis Galera Cluster baru. Dalam postingan blog ini, kita akan membahas fitur Galera Cluster 26.4.0 (atau Galera 4), lihat sekilas, dan jelajahi bagaimana fitur tersebut akan memengaruhi penyiapan Anda saat bekerja dengan MariaDB Galera Cluster.
Replikasi Streaming
Galera Cluster sama sekali bukan pengganti drop-in untuk MySQL mandiri. Cara kerja sertifikasi writeset memperkenalkan beberapa batasan dan kasus tepi yang mungkin sangat membatasi kemampuan untuk bermigrasi ke Galera Cluster. Tiga batasan yang paling umum adalah...
- Masalah dengan transaksi lama
- Masalah dengan transaksi besar
- Masalah dengan hot-spot di tabel
Yang menarik untuk dilihat adalah Galera 4 memperkenalkan Replikasi Streaming, yang dapat membantu mengurangi batasan ini. Mari kita tinjau keadaan saat ini dengan sedikit lebih detail.
Transaksi Jangka Panjang
Dalam hal ini kita berbicara tepat waktu, yang pasti bermasalah di Galera. Hal utama yang harus dipahami adalah bahwa Galera mereplikasi transaksi sebagai writeset. Writeset tersebut disertifikasi pada anggota cluster, memastikan bahwa semua node dapat menerapkan writeset yang diberikan. Masalahnya adalah, kunci dibuat pada node lokal, mereka tidak direplikasi di seluruh cluster oleh karena itu jika transaksi Anda membutuhkan beberapa menit untuk diselesaikan dan jika Anda menulis ke lebih dari satu node Galera, seiring waktu kemungkinan besar akan terjadi pada salah satu node yang tersisa, beberapa transaksi akan mengubah beberapa baris yang diperbarui dalam transaksi jangka panjang Anda. Ini akan menyebabkan sertifikasi gagal dan transaksi yang berjalan lama harus dibatalkan. Singkatnya, jika Anda mengirim tulisan ke lebih dari satu node dalam cluster, semakin lama transaksi, semakin besar kemungkinan gagal sertifikasi karena beberapa konflik.
Hotspot
Yang kami maksud adalah baris, yang sering diperbarui. Biasanya ini semacam penghitung yang diperbarui berulang kali. Penyebab masalahnya sama seperti dalam transaksi panjang - baris hanya dikunci secara lokal. Sekali lagi, jika Anda mengirim tulisan ke lebih dari satu node, kemungkinan counter yang sama akan dimodifikasi secara bersamaan di lebih dari satu node, menyebabkan konflik dan membuat sertifikasi gagal.
Untuk kedua masalah tersebut ada satu solusi - Anda dapat mengirim tulisan Anda hanya ke satu node alih-alih mendistribusikannya ke seluruh cluster. Anda dapat menggunakan proxy untuk itu - ClusterControl menyebarkan HAProxy dan ProxySQL, keduanya dapat dikonfigurasi sehingga penulisan hanya akan dikirim ke satu node. Jika Anda tidak dapat mengirim penulisan ke satu node saja, Anda harus menerima bahwa Anda akan melihat konflik sertifikasi dan kemunduran dari waktu ke waktu. Secara umum, aplikasi harus mampu menangani rollback dari database - tidak ada jalan lain, tetapi bahkan lebih penting lagi ketika aplikasi bekerja dengan Galera Cluster.
Namun, mengirimkan lalu lintas ke satu node tidak cukup untuk menangani masalah ketiga.
Transaksi Besar
Yang penting untuk diingat adalah bahwa writeset dikirim untuk sertifikasi hanya ketika transaksi selesai. Kemudian, writeset dikirim ke semua node dan proses sertifikasi berlangsung. Hal ini menyebabkan batasan seberapa besar transaksi tunggal dapat dilakukan karena Galera, saat menyiapkan writeset, menyimpannya dalam buffer dalam memori. Transaksi yang terlalu besar akan menurunkan kinerja cluster. Oleh karena itu, dua variabel telah diperkenalkan:wsrep_max_ws_rows, yang membatasi jumlah baris per transaksi (walaupun dapat diatur ke 0 - tidak terbatas) dan, yang lebih penting:wsrep_max_ws_size, yang dapat diatur hingga 2 GB. Jadi, transaksi terbesar yang bisa Anda lakukan dengan Galera Cluster adalah hingga 2GB. Selain itu, Anda harus ingat bahwa sertifikasi dan penerapan transaksi besar juga membutuhkan waktu, menciptakan "lag" - baca setelah tulis, node hit selain tempat Anda pertama kali melakukan transaksi, kemungkinan besar akan menghasilkan data yang salah karena transaksi masih diterapkan.
Galera 4 hadir dengan Replikasi Streaming, yang dapat digunakan untuk mengatasi semua masalah tersebut. Perbedaan utama adalah bahwa writeset sekarang dapat dipecah menjadi beberapa bagian - tidak perlu lagi menunggu seluruh transaksi selesai sebelum data direplikasi. Ini mungkin membuat Anda bertanya-tanya - seperti apa sertifikasi dalam kasus seperti itu? Singkatnya, sertifikasi dilakukan dengan cepat - setiap fragmen disertifikasi dan semua baris yang terlibat dikunci di semua node dalam cluster. Ini adalah perubahan serius dalam cara kerja Galera - hingga sekarang kunci dibuat secara lokal, dengan kunci replikasi streaming akan dibuat di semua node. Ini membantu dalam kasus yang kita diskusikan di atas - mengunci baris saat fragmen transaksi masuk, membantu mengurangi kemungkinan transaksi harus dibatalkan. Transaksi bentrok yang dijalankan secara lokal tidak akan bisa mendapatkan kunci yang mereka butuhkan dan harus menunggu transaksi replikasi selesai dan melepaskan kunci baris.
Dalam kasus hotspot, dengan replikasi streaming dimungkinkan untuk mendapatkan kunci pada semua node saat memperbarui baris. Kueri lain yang ingin memperbarui baris yang sama harus menunggu kunci dilepaskan sebelum mereka menjalankan perubahannya.
Transaksi besar akan mendapatkan keuntungan dari replikasi streaming karena tidak perlu lagi menunggu seluruh transaksi selesai atau dibatasi oleh ukuran transaksi - transaksi besar akan dipecah menjadi beberapa bagian. Ini juga membantu untuk memanfaatkan jaringan dengan lebih baik - alih-alih mengirim 2 GB data sekaligus, 2 GB data yang sama dapat dipecah menjadi beberapa bagian dan dikirim dalam jangka waktu yang lebih lama.
Ada dua opsi konfigurasi untuk replikasi streaming:wsrep_trx_fragment_size, yang memberi tahu seberapa besar fragmen seharusnya (secara default disetel ke 0, yang berarti replikasi streaming dinonaktifkan) dan wsrep_trx_fragment_unit, yang memberi tahu apa sebenarnya fragmen itu. Secara default adalah byte, tetapi juga bisa berupa 'pernyataan' atau 'baris'. Variabel tersebut dapat (dan harus) diatur pada tingkat sesi, sehingga memungkinkan pengguna untuk memutuskan kueri tertentu mana yang harus direplikasi menggunakan replikasi streaming. Menyetel unit ke 'pernyataan' dan ukuran ke 1 memungkinkan, misalnya, menggunakan replikasi streaming hanya untuk satu kueri yang, misalnya, memperbarui hotspot.
Tentu saja, ada kelemahan menjalankan replikasi streaming, terutama karena fakta bahwa kunci sekarang diambil pada semua node dalam cluster. Jika Anda telah melihat transaksi besar bergulir kembali selama berabad-abad, sekarang transaksi tersebut harus memutar kembali semua node. Jelas, praktik terbaik adalah mengurangi ukuran transaksi sebanyak mungkin untuk menghindari pengembalian yang membutuhkan waktu berjam-jam untuk diselesaikan. Kelemahan lainnya adalah, untuk alasan pemulihan crash, writeset yang dibuat dari setiap fragmen disimpan dalam tabel wsrep_schema.SR di semua node, yang, semacam, mengimplementasikan buffer penulisan ganda, meningkatkan beban pada cluster. Oleh karena itu, Anda harus hati-hati memutuskan transaksi mana yang harus direplikasi menggunakan replikasi streaming dan, selama memungkinkan, Anda harus tetap berpegang pada praktik terbaik dengan melakukan transaksi kecil dan pendek atau membagi transaksi besar menjadi kumpulan yang lebih kecil.
Kunci Cadangan
Terakhir, pengguna MariaDB akan dapat memanfaatkan kunci cadangan untuk SST. Ide di balik SST yang dieksekusi menggunakan (untuk MariaDB) mariabackup adalah bahwa seluruh dataset harus ditransfer, dengan cepat, dengan redo log yang dikumpulkan di latar belakang. Kemudian, kunci global harus diperoleh, memastikan bahwa tidak ada penulisan yang akan terjadi, posisi akhir dari redo log harus dikumpulkan dan disimpan. Secara historis, untuk MariaDB, bagian penguncian dilakukan menggunakan FLUSH TABLES WITH READ LOCK yang melakukan tugasnya tetapi di bawah beban berat itu cukup sulit untuk diperoleh. Ini juga cukup berat - tidak hanya transaksi yang harus menunggu kunci dilepaskan, tetapi juga data harus di-flush ke disk. Sekarang, dengan MariaDB 10.4, dimungkinkan untuk menggunakan BACKUP LOCK yang tidak terlalu mengganggu, yang tidak memerlukan data untuk dihapus, hanya komit yang akan diblokir selama penguncian. Ini berarti operasi SST yang tidak terlalu mengganggu, yang pasti enak didengar. Setiap orang yang harus menjalankan Galera Cluster mereka dalam mode darurat, pada satu node, menjaga agar SST tidak memengaruhi operasi cluster harus lebih dari senang mendengar tentang peningkatan ini.
Pembacaan Kausal Dari Aplikasi
Galera 4 memperkenalkan tiga fungsi baru yang dimaksudkan untuk membantu menambahkan dukungan untuk pembacaan kausal dalam aplikasi - WSREP_LAST_WRITTEN_GTID(), yang mengembalikan GTID dari penulisan terakhir yang dibuat oleh klien, WSREP_LAST_SEEN_GTID(), yang mengembalikan GTID dari transaksi penulisan terakhir yang diamati oleh klien dan WSREP_SYNC_WAIT_UPTO_GTID(), yang akan memblokir klien hingga GTID yang diteruskan ke fungsi akan dikomit pada node. Tentu, Anda dapat menerapkan pembacaan kausal di Galera bahkan sekarang, tetapi dengan memanfaatkan fungsi-fungsi itu, dimungkinkan untuk mengimplementasikan pembacaan setelah penulisan yang aman di bagian-bagian aplikasi yang diperlukan, tanpa perlu membuat perubahan dalam konfigurasi Galera.
Meningkatkan ke MariaDB Galera 10.4
Jika Anda ingin mencoba Galera 4, itu tersedia di kandidat rilis terbaru untuk MariaDB 10.4. Sesuai dokumentasi MariaDB, saat ini tidak ada cara untuk melakukan upgrade langsung dari 10.3 Galera ke 10.4. Anda harus menghentikan seluruh cluster 10.3, meningkatkannya ke 10.4 dan kemudian memulainya kembali. Ini adalah pemblokir yang serius dan kami berharap batasan ini akan dihapus di salah satu versi berikutnya. Sangat penting untuk memiliki opsi untuk peningkatan langsung dan untuk itu MariaDB 10.3 dan MariaDB 10.4 harus hidup berdampingan di Galera Cluster yang sama. Opsi lain, yang mungkin juga cocok, adalah menyiapkan replikasi asinkron antara Cluster Galera lama dan baru.
Kami sangat berharap Anda menikmati ulasan singkat tentang fitur-fitur MariaDB 10.4 Galera Cluster, kami menantikan untuk melihat replikasi streaming di lingkungan produksi langsung yang sebenarnya. Kami juga berharap perubahan tersebut akan membantu meningkatkan adopsi Galera lebih jauh lagi. Lagi pula, replikasi streaming memecahkan banyak masalah yang dapat mencegah orang bermigrasi ke Galera.
