Saat ini, cukup umum untuk memiliki database yang direplikasi di server/pusat data lain, dan itu juga suatu keharusan dalam beberapa kasus. Ada berbagai alasan untuk mereplikasi database Anda ke lingkungan yang benar-benar terpisah.
- Bermigrasi ke pusat data lain.
- Persyaratan peningkatan versi (perangkat keras/perangkat lunak).
- Mempertahankan sistem operasional yang disinkronkan sepenuhnya di situs Disaster Recovery (DR) yang dapat mengambil alih kapan saja
- Simpan database slave sebagai bagian dari Paket DR dengan biaya lebih rendah.
- Untuk persyaratan geo-lokasi (data harus lokal di negara tertentu).
- Memiliki lingkungan pengujian.
- Tujuan pemecahan masalah.
- Database pelaporan.
Dan, ada berbagai cara untuk melakukan tugas replikasi ini:
- Cadangkan/Pulihkan :Mencadangkan basis data produksi dan memulihkannya di server/lingkungan baru adalah cara klasik untuk melakukan ini, tetapi ini juga merupakan cara kuno karena Anda tidak akan memperbarui data dan Anda harus menunggu untuk setiap proses pemulihan jika Anda memerlukan beberapa data terbaru. Jika Anda memiliki kluster (master-slave, multi-master), dan jika Anda ingin membuatnya kembali, Anda harus memulihkan cadangan awal dan kemudian membuat ulang node lainnya, yang dapat menjadi tugas yang memakan waktu.
- Kluster Klon :Ini mirip dengan yang sebelumnya tetapi proses pencadangan dan pemulihan adalah untuk seluruh cluster, tidak hanya satu server database tertentu. Dengan cara ini, Anda dapat mengkloning seluruh cluster dalam tugas yang sama dan Anda tidak perlu membuat ulang node lainnya secara manual. Metode ini masih memiliki masalah dalam menjaga agar data tetap mutakhir di antara klon.
- Replikasi :Cara ini menyertakan opsi pencadangan/pemulihan, tetapi setelah pemulihan awal, proses replikasi akan membuat data Anda tetap sinkron dengan node master. Dengan cara ini, jika Anda memiliki cluster database, Anda perlu memulihkan cadangan ke satu node, dan membuat ulang semua node secara manual.
Di blog ini, kita akan melihat fitur ClusterControl 1.7.4 baru yang memungkinkan Anda menggunakan campuran metode yang kami sebutkan sebelumnya untuk meningkatkan tugas ini.
Apa itu Replikasi Cluster-to-Cluster?
Replikasi antara dua klaster tidak sama dengan memperluas klaster untuk dijalankan di dua pusat data. Saat mengatur replikasi antara dua cluster, kami sebenarnya memiliki 2 sistem terpisah yang dapat beroperasi secara mandiri. Replikasi digunakan untuk menjaganya tetap sinkron, sehingga sistem slave memiliki status yang diperbarui dan dapat mengambil alih.
Dari ClusterControl 1.7.4, dimungkinkan untuk membuat cluster baru dengan langsung mengkloning cluster sumber yang sedang berjalan, atau dengan menggunakan cadangan terbaru dari cluster sumber.
Setelah mengkloning cluster, Anda akan memiliki data penerima Slave Cluster (SC), dan Master Cluster (MC) mengirim perubahan ke slave.
ClusterControl mendukung Replikasi Cluster-to-Cluster untuk tipe cluster berikut:
- Percona XtraDB Cluster versi 5.6.x dan yang lebih baru.
- Kluster MariaDB Galera versi 10.x dan yang lebih baru.
- PostgreSQL 9.6 dan yang lebih baru.
Replikasi Cluster-to-Cluster untuk Percona XtraDB / MariaDB Galera Cluster
Untuk mesin berbasis MySQL, GTID diperlukan untuk menggunakan fitur ini, dan replikasi asinkron antara cluster Master dan Slave akan digunakan.
Ada beberapa tindakan yang harus dilakukan untuk mempersiapkan cluster saat ini untuk tugas ini. Pertama, setidaknya satu node pada cluster saat ini harus mengaktifkan log biner. Kemudian, Anda perlu menambahkan pengguna cadangan yang dikonfigurasi di node database di file konfigurasi ClusterControl, yang akan digunakan untuk tugas manajemen. Semua tindakan ini dapat dilakukan dengan menggunakan ClusterControl UI atau ClusterControl CLI.
Sekarang Anda siap untuk membuat replikasi Percona XtraDB/MariaDB Galera Cluster-to-Cluster. Ketika pekerjaan selesai, Anda akan memiliki:
- Satu node di Slave Cluster akan mereplikasi dari satu node di Master Cluster.
- Replikasi akan berlangsung dua arah antar cluster.
- Semua node dalam Slave Cluster akan menjadi read-only secara default. Dimungkinkan untuk menonaktifkan flag read-only pada node satu per satu.
- Pengelompokan Aktif-Aktif hanya disarankan jika aplikasi hanya menyentuh kumpulan data yang terpisah di salah satu Cluster karena mesin tidak menawarkan Deteksi atau Penyelesaian Konflik.
Dari UI ClusterControl atau CLI ClusterControl, Anda akan dapat:
- Buat Cluster Replikasi ini.
- Aktifkan konfigurasi Aktif-Aktif.
- Ubah Topologi Cluster.
- Membangun Kembali Cluster Replikasi.
- Hentikan/Mulai Replikasi Budak.
- Reset Replication Slave (hanya diimplementasikan menggunakan ClusterControl CLI atm).
Pertimbangan
- Pengguna cadangan harus ditambahkan secara manual di file konfigurasi ClusterControl.
- Kredensial pengguna cadangan harus sama di cluster saat ini dan baru.
- Kata sandi root MySQL yang ditentukan saat membuat Slave Cluster harus sama dengan kata sandi root yang digunakan pada Master Cluster.
Batasan yang Diketahui
- Failover Otomatis belum didukung. Jika master gagal, maka administrator bertanggung jawab untuk mengalihkan ke master lain.
- Hanya memungkinkan untuk “RESET” slave replikasi dari ClusterControl CLI karena belum diimplementasikan di UI ClusterControl.
- Hanya dimungkinkan untuk Membangun Kembali Cluster yang berada dalam mode hanya-baca. Semua node dalam Cluster harus read-only untuk dihitung sebagai Cluster read-only.
Replikasi Cluster-to-Cluster untuk PostgreSQL
ClusterControl Replikasi Cluster-to-Cluster didukung di PostgreSQL menggunakan replikasi streaming.
Sebagai persyaratan, harus ada server PostgreSQL dengan peran ClusterControl 'master', dan saat Anda menyiapkan Slave Cluster, kredensial Admin harus sama dengan Master Cluster.
Sekarang Anda siap membuat replikasi PostgreSQL Cluster-to-Cluster. Ketika pekerjaan selesai, Anda akan memiliki:
- Satu node di Slave Cluster akan mereplikasi dari satu node di Master Cluster.
- Replikasi akan searah antara cluster.
- Node dalam Slave Cluster akan bersifat read-only.
Dari UI ClusterControl atau CLI ClusterControl, Anda akan dapat:
- Buat Cluster Replikasi ini.
- Membangun Kembali Cluster Replikasi.
- Hentikan/Mulai Replikasi Budak.
Pertimbangan
- Kredensial Admin harus sama di Cluster Master dan Slave.
Batasan yang Diketahui
- Ukuran maksimal Slave Cluster adalah satu node.
- Kluster Budak tidak dapat dipentaskan dari cadangan.
- Perubahan topologi tidak didukung.
- Hanya replikasi searah yang didukung.
Kesimpulan
Dengan menggunakan fitur ClusterControl baru ini, Anda tidak perlu melakukan setiap langkah untuk membuat Replikasi Cluster secara terpisah atau manual, dan sebagai hasil dari menggunakannya, Anda akan menghemat waktu dan tenaga. Cobalah!
