Sangat umum melihat database didistribusikan di beberapa lokasi geografis. Salah satu skenario untuk melakukan pengaturan jenis ini adalah untuk pemulihan bencana, di mana pusat data siaga Anda berada di lokasi yang terpisah dari pusat data utama Anda. Mungkin juga diperlukan agar database berada lebih dekat dengan pengguna.
Tantangan utama untuk mencapai penyiapan ini adalah dengan merancang database dengan cara yang mengurangi kemungkinan masalah yang terkait dengan partisi jaringan.
Cluster MariaDB dapat menjadi pilihan yang baik untuk membangun lingkungan seperti itu karena beberapa alasan. Kami ingin mendiskusikannya di sini dan juga berbicara sedikit tentang seperti apa lingkungan seperti itu.
Mengapa Menggunakan Cluster MariaDB untuk Lingkungan Geo-Distributed?
Alasan pertama adalah MariaDB Cluster dapat mendukung banyak penulis. Ini membuat cara merancang perutean tulis lebih mudah - Anda cukup menulis ke node MariaDB lokal. Tentu saja, dengan replikasi sinkron, latensi memengaruhi kinerja penulisan dan Anda mungkin melihat bahwa penulisan Anda menjadi lebih lambat jika Anda menyebarkan cluster terlalu jauh secara geografis. Lagi pula, Anda tidak dapat mengabaikan hukum fisika dan mereka mengatakan, setidaknya sampai sekarang, bahwa bahkan kecepatan cahaya dalam koneksi serat terbatas. Setiap router yang ditambahkan selain itu juga akan meningkatkan latensi meskipun hanya beberapa milidetik.
Kedua, penanganan lag di MariaDB Cluster. Replikasi asinkron adalah subjek untuk jeda replikasi - budak mungkin tidak up-to-date dengan data jika mereka berjuang untuk menerapkan semua perubahan dalam waktu. Di MariaDB Cluster ini berbeda - flow control adalah mekanisme yang dimaksudkan untuk menjaga agar cluster tetap sinkron. Yah, hampir - dalam beberapa kasus tepi Anda masih bisa mengamati lag. Yang kita bicarakan di sini, biasanya, milidetik, paling lama beberapa detik sementara di langit replikasi asinkron adalah batasnya.
Ketiga, segmen. Secara default MariaDB CLster menggunakan all to all communication dan setiap writeset dikirim oleh node ke semua node lain di cluster. Perilaku ini dapat diubah menggunakan segmen. Segmen memungkinkan pengguna untuk membagi Cluster MariaDB di beberapa bagian. Setiap segmen dapat berisi beberapa node dan memilih salah satu dari mereka sebagai node relay. Node tersebut menerima writeset dari segmen lain dan mendistribusikannya kembali di seluruh node MariaDB lokal ke segmen tersebut. Akibatnya, seperti yang Anda lihat pada diagram di atas, lalu lintas replikasi melalui WAN dapat dikurangi tiga kali - hanya dua "replika" aliran replikasi yang dikirim melalui WAN:satu per pusat data dibandingkan dengan satu per slave dalam replikasi asinkron.
Akhirnya, di mana MariaDB Cluster benar-benar bersinar adalah penanganan partisi jaringan. MariaDB Cluster terus memantau keadaan node di cluster. Setiap node mencoba untuk terhubung dengan rekan-rekannya dan bertukar status cluster. Jika subset node tidak dapat dijangkau, MariaDB mencoba untuk menyampaikan komunikasi sehingga jika ada cara untuk mencapai node tersebut, node tersebut akan tercapai.
Contoh dapat dilihat pada diagram di atas:DC 1 kehilangan konektivitas dengan DC2 tetapi DC2 dan DC3 dapat terhubung. Dalam hal ini salah satu node di DC3 akan digunakan untuk menyampaikan data dari DC1 ke DC2 untuk memastikan bahwa komunikasi intra-cluster dapat dipertahankan.
MariaDB dapat mengambil tindakan berdasarkan status cluster. Ini mengimplementasikan kuorum - mayoritas node harus tersedia agar cluster dapat beroperasi. Jika node terputus dari cluster dan tidak dapat menjangkau node lain, node tersebut akan berhenti beroperasi.
Seperti yang dapat dilihat pada diagram di atas, ada kehilangan sebagian komunikasi jaringan di DC1 dan node yang terpengaruh dihapus dari cluster, memastikan bahwa aplikasi tidak akan mengakses data yang sudah usang.
Hal ini juga berlaku dalam skala yang lebih besar. DC1 memutuskan semua komunikasinya. Akibatnya, seluruh pusat data telah dihapus dari cluster dan tidak satu pun dari node-nya yang akan melayani lalu lintas. Sisa dari cluster mempertahankan mayoritas (6 dari 9 node tersedia) dan mengkonfigurasi ulang sendiri untuk menjaga koneksi antara DC 2 dan DC3. Dalam diagram di atas, kami mengasumsikan penulis mencapai simpul di DC2 tetapi harap diingat bahwa MariaDB mampu berjalan dengan banyak penulis.
Merancang Cluster MariaDB yang Terdistribusi Secara Geografis
Kita telah mempelajari beberapa fitur yang membuat MariaDB Cluster cocok untuk lingkungan yang terdistribusi secara geografis, sekarang mari kita sedikit fokus pada desainnya. Pada awalnya, mari kita jelaskan lingkungan tempat kita bekerja. Kami akan menggunakan tiga pusat data jarak jauh, yang terhubung melalui Wide Area Network (WAN). Setiap pusat data akan menerima penulisan dari server aplikasi lokal. Bacaan juga hanya bersifat lokal. Ini dimaksudkan untuk menghindari lalu lintas yang tidak perlu melintasi WAN.
Agar blog ini tidak terlalu rumit, kami tidak akan membahas detail tentang bagaimana seharusnya konektivitas itu terlihat. Kami mengasumsikan semacam koneksi aman yang dikonfigurasi dengan benar di semua pusat data. VPN atau alat lain dapat digunakan untuk mengimplementasikannya.
Kami akan menggunakan MaxScale sebagai penyeimbang beban. MaxScale akan digunakan secara lokal di setiap pusat data. Ini juga akan mengarahkan lalu lintas hanya ke node lokal. Node jarak jauh selalu dapat ditambahkan secara manual dan kami akan menjelaskan kasus di mana ini mungkin merupakan solusi yang baik. Aplikasi dapat dikonfigurasi untuk terhubung ke salah satu node MaxScale lokal menggunakan algoritma round-robin. Kita juga dapat menggunakan Keepalive dan IP Virtual untuk mengarahkan lalu lintas menuju node MaxScale tunggal, selama satu node MaxScale dapat menangani semua lalu lintas.
Solusi lain yang mungkin adalah menempatkan MaxScale dengan node aplikasi dan mengonfigurasi aplikasi untuk terhubung ke proxy di localhost. Pendekatan ini bekerja cukup baik dengan asumsi bahwa MaxScale tidak akan tersedia namun aplikasi akan bekerja dengan baik pada node yang sama. Biasanya yang kita lihat adalah kegagalan node atau kegagalan jaringan, yang akan memengaruhi MaxScale dan aplikasi secara bersamaan.
Diagram di atas menunjukkan versi lingkungan, di mana MaxScale membentuk peternakan proxy - semua node proxy dengan konfigurasi yang sama, beban seimbang menggunakan Keepalive, atau cukup round robin dari aplikasi di semua node MaxScale. MaxScale dikonfigurasi untuk mendistribusikan beban kerja di semua node MariaDB di pusat data lokal. Salah satu node tersebut akan dipilih sebagai node untuk mengirim penulisan sementara SELECT akan didistribusikan ke semua node. Memiliki satu node penulis khusus di pusat data membantu mengurangi jumlah kemungkinan konflik sertifikasi, yang biasanya menghasilkan kinerja yang lebih baik. Untuk mengurangi ini lebih jauh kita harus mulai mengirimkan lalu lintas melalui koneksi WAN, yang tidak ideal karena pemanfaatan bandwidth akan meningkat secara signifikan. Saat ini, dengan segmen yang ada, hanya dua salinan set tulis yang dikirim melintasi pusat data - satu per DC.
Kesimpulan
Seperti yang Anda lihat, MariaDB Cluster dapat dengan mudah digunakan untuk membuat cluster yang didistribusikan secara geografis yang dapat bekerja bahkan di seluruh dunia. Faktor pembatasnya adalah latensi jaringan. Jika terlalu tinggi, Anda mungkin harus mempertimbangkan untuk menggunakan klaster MariaDB terpisah yang terhubung menggunakan replikasi asinkron.
