Sangat umum untuk 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 pengaturan ini adalah dengan merancang database dengan cara yang mengurangi kemungkinan masalah yang terkait dengan partisi jaringan. Salah satu solusinya mungkin menggunakan Galera Cluster alih-alih replikasi asinkron (atau semi-sinkron) biasa. Di blog ini kita akan membahas pro dan kontra dari pendekatan ini. Ini adalah bagian pertama dari rangkaian dua blog. Di bagian kedua, kita akan mendesain Galera Cluster yang terdistribusi secara geografis dan melihat bagaimana ClusterControl dapat membantu kita menerapkan lingkungan seperti itu.
Mengapa Cluster Galera Alih-alih Replikasi Asinkron untuk Cluster Terdistribusi-Geo?
Mari kita lihat perbedaan utama antara Galera dan replikasi biasa. Replikasi reguler memberi Anda hanya satu node untuk menulis, ini berarti bahwa setiap penulisan dari pusat data jarak jauh harus dikirim melalui Wide Area Network (WAN) untuk mencapai master. Ini juga berarti bahwa semua proxy yang terletak di pusat data jarak jauh harus dapat memantau seluruh topologi, mencakup semua pusat data yang terlibat karena mereka harus dapat mengetahui node mana yang saat ini menjadi master.
Hal ini menyebabkan sejumlah masalah. Pertama, beberapa koneksi harus dibuat di seluruh WAN, ini menambah latensi dan memperlambat pemeriksaan apa pun yang mungkin dijalankan oleh proxy. Selain itu, ini menambahkan overhead yang tidak perlu pada proxy dan database. Sebagian besar waktu Anda hanya tertarik untuk mengarahkan lalu lintas ke node database lokal. Satu-satunya pengecualian adalah master dan hanya karena proxy ini dipaksa untuk menonton seluruh infrastruktur daripada hanya bagian yang terletak di pusat data lokal. Tentu saja, Anda dapat mencoba mengatasi ini dengan menggunakan proxy untuk merutekan SELECT saja, sambil menggunakan beberapa metode lain (nama host khusus untuk master yang dikelola oleh DNS) untuk mengarahkan aplikasi ke master, tetapi ini menambah tingkat kerumitan dan bagian yang tidak perlu, yang dapat berdampak serius pada kemampuan Anda untuk menangani beberapa node dan kegagalan jaringan tanpa kehilangan konsistensi data.
Galera Cluster dapat mendukung banyak penulis. Latensi juga merupakan faktor, karena semua node di kluster Galera harus berkoordinasi dan berkomunikasi untuk mengesahkan set tulis, bahkan ini bisa menjadi alasan Anda memutuskan untuk tidak menggunakan Galera saat latensi terlalu tinggi. Ini juga merupakan masalah dalam kluster replikasi - dalam kluster replikasi, latensi hanya memengaruhi penulisan dari pusat data jarak jauh sementara koneksi dari pusat data tempat master berada akan mendapat manfaat dari komit latensi rendah.
Dalam Replikasi MySQL Anda juga harus mempertimbangkan skenario terburuk dan memastikan bahwa aplikasi baik-baik saja dengan penulisan yang tertunda. Master selalu dapat berubah dan Anda tidak dapat yakin bahwa setiap saat Anda akan menulis ke node lokal.
Perbedaan lain antara replikasi dan Galera Cluster adalah penanganan jeda replikasi. Cluster yang didistribusikan secara geografis dapat sangat terpengaruh oleh kelambatan:latensi, throughput terbatas dari koneksi WAN, semua ini akan memengaruhi kemampuan cluster yang direplikasi untuk mengikuti replikasi. Harap diingat bahwa replikasi menghasilkan satu untuk semua lalu lintas.
Semua budak harus menerima seluruh lalu lintas replikasi - jumlah data yang Anda miliki untuk mengirim ke budak jarak jauh melalui WAN meningkat dengan setiap budak jarak jauh yang Anda tambahkan. Ini dapat dengan mudah menyebabkan saturasi tautan WAN, terutama jika Anda melakukan banyak modifikasi dan tautan WAN tidak memiliki throughput yang baik. Seperti yang Anda lihat pada diagram di atas, dengan tiga pusat data dan tiga node di masing-masingnya, master harus mengirimkan 6x lalu lintas replikasi melalui koneksi WAN.
Dengan kluster Galera, semuanya sedikit berbeda. Sebagai permulaan, Galera menggunakan kontrol aliran untuk menjaga agar node tetap sinkron. Jika salah satu node mulai tertinggal, ia memiliki kemampuan untuk meminta sisa cluster untuk memperlambat dan membiarkannya mengejar. Tentu, ini mengurangi kinerja seluruh cluster, tetapi masih lebih baik daripada ketika Anda tidak dapat benar-benar menggunakan budak untuk SELECT karena mereka cenderung tertinggal dari waktu ke waktu - dalam kasus seperti itu, hasil yang Anda dapatkan mungkin sudah ketinggalan zaman dan salah.
Fitur lain dari Galera Cluster, yang dapat meningkatkan kinerjanya secara signifikan saat digunakan WAN, adalah segmen. Secara default Galera menggunakan semua untuk semua komunikasi dan setiap writeset dikirim oleh node ke semua node lain dalam cluster. Perilaku ini dapat diubah menggunakan segmen. Segmen memungkinkan pengguna untuk membagi klaster Galera menjadi 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 Galera 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 di Replikasi MySQL.
Penanganan Partisi Jaringan Cluster Galera
Yang menonjol dari Galera Cluster adalah penanganan partisi jaringan. Galera 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, Galera mencoba untuk menyampaikan komunikasi sehingga jika ada cara untuk mencapai node tersebut, mereka 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.
Galera Cluster 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 kluster dan tidak satu pun dari simpulnya 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 penulisan mencapai simpul di DC2, tetapi harap diingat bahwa Galera mampu berjalan dengan banyak penulis.
Replikasi MySQL tidak memiliki kesadaran cluster apa pun, membuatnya bermasalah untuk menangani masalah jaringan. Itu tidak dapat menutup sendiri setelah kehilangan koneksi dengan node lain. Tidak ada cara mudah untuk mencegah master lama muncul setelah pemisahan jaringan.
Satu-satunya kemungkinan terbatas pada lapisan proxy atau bahkan lebih tinggi. Anda harus merancang sebuah sistem, yang akan mencoba memahami keadaan cluster dan mengambil tindakan yang diperlukan. Salah satu cara yang mungkin adalah dengan menggunakan alat sadar-cluster seperti Orchestrator dan kemudian menjalankan skrip yang akan memeriksa status cluster RAFT Orchestrator dan, berdasarkan status ini, mengambil tindakan yang diperlukan pada lapisan database. Ini jauh dari ideal karena tindakan apa pun yang dilakukan pada lapisan yang lebih tinggi dari database, menambahkan latensi tambahan:hal ini memungkinkan sehingga masalah muncul dan konsistensi data terganggu sebelum tindakan yang benar dapat diambil. Galera, di sisi lain, mengambil tindakan di tingkat basis data, memastikan reaksi secepat mungkin.
