Satu titik kegagalan (SPOF) adalah alasan umum mengapa organisasi berupaya mendistribusikan keberadaan lingkungan database mereka ke lokasi lain secara geografis. Ini adalah bagian dari rencana strategis Pemulihan Bencana dan Kelangsungan Bisnis.
Perencanaan Pemulihan Bencana (DR) mewujudkan prosedur teknis yang mencakup persiapan untuk masalah yang tidak terduga seperti bencana alam, kecelakaan (seperti kesalahan manusia), atau insiden (seperti tindakan kriminal).
Selama dekade terakhir, mendistribusikan lingkungan database Anda di beberapa lokasi geografis telah menjadi pengaturan yang cukup umum, karena cloud publik menawarkan banyak cara untuk menangani hal ini. Tantangannya datang dalam menyiapkan lingkungan database. Ini menciptakan tantangan saat Anda mencoba mengelola database, memindahkan data Anda ke geo-lokasi lain, atau menerapkan keamanan dengan tingkat observabilitas yang tinggi.
Dalam blog ini, kami akan menunjukkan bagaimana Anda dapat melakukannya menggunakan Replikasi MySQL. Kami akan membahas bagaimana Anda dapat menyalin data Anda ke node database lain yang terletak di negara berbeda yang jauh dari geografi cluster MySQL saat ini. Untuk contoh ini, wilayah target kami didasarkan pada kami-timur, sedangkan lokal saya berada di Asia yang terletak di Filipina.
Mengapa Saya Membutuhkan Cluster Database Geo-Location?
Bahkan Amazon AWS, penyedia cloud publik teratas, mengklaim bahwa mereka mengalami waktu henti atau pemadaman yang tidak disengaja (seperti yang terjadi pada tahun 2017). Katakanlah Anda menggunakan AWS sebagai pusat data sekunder Anda selain dari lokal Anda. Anda tidak dapat memiliki akses internal ke perangkat keras yang mendasarinya atau ke jaringan internal yang mengelola node komputasi Anda. Ini adalah layanan terkelola sepenuhnya yang Anda bayar, tetapi Anda tidak dapat menghindari fakta bahwa itu dapat mengalami pemadaman kapan saja. Jika lokasi geografis seperti itu mengalami pemadaman, Anda dapat memiliki waktu henti yang lama.
Jenis masalah ini harus diramalkan selama perencanaan kesinambungan bisnis Anda. Itu harus dianalisis dan diimplementasikan berdasarkan apa yang telah didefinisikan. Kelangsungan bisnis untuk database MySQL Anda harus mencakup waktu aktif yang tinggi. Beberapa lingkungan melakukan tolok ukur dan menetapkan standar pengujian yang ketat termasuk sisi yang lemah untuk mengekspos kerentanan apa pun, seberapa tangguhnya, dan seberapa skala arsitektur teknologi Anda termasuk infrastruktur database Anda. Untuk bisnis terutama yang menangani transaksi tinggi, sangat penting untuk memastikan bahwa database produksi tersedia untuk aplikasi sepanjang waktu bahkan ketika bencana terjadi. Jika tidak, waktu henti dapat dialami dan Anda mungkin memerlukan banyak uang.
Dengan skenario yang teridentifikasi ini, organisasi mulai memperluas infrastruktur mereka ke penyedia cloud yang berbeda dan menempatkan node ke lokasi geografis yang berbeda untuk mendapatkan waktu kerja yang lebih tinggi (jika mungkin pada 99,999999999999), RPO yang lebih rendah, dan tidak memiliki SPOF.
Untuk memastikan database produksi bertahan dari bencana, situs Disaster Recovery (DR) harus dikonfigurasi. Lokasi produksi dan DR harus menjadi bagian dari dua pusat data yang jauh secara geografis. Artinya, database siaga harus dikonfigurasi di situs DR untuk setiap database produksi sehingga, perubahan data yang terjadi pada database produksi segera disinkronkan ke database siaga melalui log transaksi. Beberapa penyiapan juga menggunakan node DR-nya untuk menangani pembacaan sehingga menyediakan penyeimbangan beban antara aplikasi dan lapisan data.
Pengaturan Arsitektur yang Diinginkan
Di blog ini, pengaturan yang diinginkan sederhana namun implementasinya sangat umum saat ini. Lihat di bawah pada pengaturan arsitektur yang diinginkan untuk blog ini:
Dalam blog ini, saya memilih Google Cloud Platform (GCP) sebagai publik penyedia cloud, dan menggunakan jaringan lokal saya sebagai lingkungan database lokal saya.
Ini adalah suatu keharusan bahwa ketika menggunakan jenis desain ini, Anda selalu membutuhkan lingkungan atau platform untuk berkomunikasi dengan cara yang sangat aman. Menggunakan VPN atau menggunakan alternatif seperti AWS Direct Connect. Meskipun awan publik ini saat ini menawarkan layanan VPN terkelola yang dapat Anda gunakan. Tetapi untuk pengaturan ini, kami akan menggunakan OpenVPN karena saya tidak memerlukan perangkat keras atau layanan yang canggih untuk blog ini.
Cara Terbaik dan Paling Efisien
Untuk lingkungan database MySQL/Percona/MariaDB, cara terbaik dan efisien adalah dengan mengambil salinan cadangan database Anda, mengirim ke node target untuk disebarkan atau dipakai. Ada berbagai cara untuk menggunakan pendekatan ini baik Anda dapat menggunakan mysqldump, mydumper, rsync, atau menggunakan Percona XtraBackup/Mariabackup dan mengalirkan data ke node target Anda.
Menggunakan mysqldump
mysqldump membuat cadangan logis dari seluruh database Anda atau Anda dapat secara selektif memilih daftar database, tabel, atau bahkan catatan tertentu yang ingin Anda buang.
Perintah sederhana yang dapat Anda gunakan untuk mengambil cadangan penuh adalah,
$ mysqldump --single-transaction --all-databases --triggers --routines --events --master-data | mysql -h <target-host-db-node -u<user> -p<password> -vvv --show-warningsDengan perintah sederhana ini, pernyataan MySQL akan langsung dijalankan ke node database target, misalnya node database target Anda di Google Compute Engine. Ini bisa efisien ketika data lebih kecil atau Anda memiliki bandwidth yang cepat. Jika tidak, mengemas database Anda ke file lalu mengirimkannya ke node target dapat menjadi pilihan Anda.
$ mysqldump --single-transaction --all-databases --triggers --routines --events --master-data | gzip > mydata.db
$ scp mydata.db <target-host>:/some/pathKemudian jalankan mysqldump ke node database target seperti itu,
zcat mydata.db | mysqlKelemahan dengan menggunakan pencadangan logis menggunakan mysqldump adalah lebih lambat dan menghabiskan ruang disk. Itu juga menggunakan satu utas sehingga Anda tidak dapat menjalankan ini secara paralel. Secara opsional, Anda dapat menggunakan mydumper terutama ketika data Anda terlalu besar. mydumper dapat dijalankan secara paralel tetapi tidak fleksibel dibandingkan dengan mysqldump.
Menggunakan xtrabackup
xtrabackup adalah cadangan fisik tempat Anda dapat mengirim aliran atau biner ke node target. Ini sangat efisien dan sebagian besar digunakan saat melakukan streaming cadangan melalui jaringan terutama ketika node target memiliki geografi yang berbeda atau wilayah yang berbeda. ClusterControl menggunakan xtrabackup saat menyediakan atau membuat instance slave baru di mana pun ia berada selama akses dan izin telah disiapkan sebelum tindakan.
Jika Anda menggunakan xtrabackup untuk menjalankannya secara manual, Anda dapat menjalankan perintah seperti itu,
## Node target
$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | xbstream -x -C /var/lib/mysql## Node sumber
$ innobackupex --defaults-file=/etc/my.cnf --stream=xbstream --socket=/var/lib/mysql/mysql.sock --host=localhost --tmpdir=/tmp /tmp | socat -u stdio TCP:192.168.10.70:9999Untuk menguraikan kedua perintah tersebut, perintah pertama harus dijalankan atau dijalankan terlebih dahulu pada node target. Perintah node target tidak mendengarkan pada port 9999 dan akan menulis aliran apa pun yang diterima dari port 9999 di node target. Itu tergantung pada perintah socat dan xbstream yang berarti Anda harus memastikan bahwa Anda telah menginstal paket-paket ini.
Pada node sumber, ia mengeksekusi skrip perl innobackupex yang memanggil xtrabackup di latar belakang dan menggunakan xbstream untuk mengalirkan data yang akan dikirim melalui jaringan. Perintah socat membuka port 9999 dan mengirimkan datanya ke host yang diinginkan, yaitu 192.168.10.70 dalam contoh ini. Namun, pastikan Anda telah menginstal socat dan xbstream saat menggunakan perintah ini. Cara alternatif menggunakan socat adalah nc tetapi socat menawarkan fitur yang lebih canggih dibandingkan dengan nc seperti serialisasi seperti beberapa klien dapat mendengarkan pada port.
ClusterControl menggunakan perintah ini saat membangun kembali budak atau membangun budak baru. Ini cepat dan menjamin salinan persis dari data sumber Anda akan disalin ke node target Anda. Saat menyediakan database baru ke dalam lokasi geografis yang terpisah, menggunakan pendekatan ini menawarkan lebih banyak efisiensi dan menawarkan Anda lebih banyak kecepatan untuk menyelesaikan pekerjaan. Meskipun mungkin ada pro dan kontra saat menggunakan pencadangan logis atau biner saat dialirkan melalui kabel. Menggunakan metode ini adalah pendekatan yang sangat umum saat menyiapkan cluster database geo-lokasi baru ke wilayah berbeda dan membuat salinan persis dari lingkungan database Anda.
Efisiensi, Observabilitas, dan Kecepatan
Pertanyaan yang ditinggalkan oleh kebanyakan orang yang tidak terbiasa dengan pendekatan ini selalu mencakup masalah "BAGAIMANA, APA, DIMANA". Di bagian ini, kami akan membahas bagaimana Anda dapat secara efisien mengatur database geo-lokasi Anda dengan lebih sedikit pekerjaan untuk ditangani dan dengan observabilitas mengapa gagal. Menggunakan ClusterControl sangat efisien. Dalam pengaturan saat ini yang saya miliki, lingkungan berikut seperti yang diterapkan pada awalnya:
Memperluas Node ke GCP
Mulai menyiapkan cluster database geo-Location, untuk memperluas cluster dan membuat salinan snapshot cluster, Anda dapat menambahkan slave baru. Seperti disebutkan sebelumnya, ClusterControl akan menggunakan xtrabackup (mariabackup untuk MariaDB 10.2 dan seterusnya) dan menyebarkan node baru di dalam cluster Anda. Sebelum Anda dapat mendaftarkan node komputasi GCP sebagai node target, Anda harus terlebih dahulu menyiapkan pengguna sistem yang sesuai dengan pengguna sistem yang Anda daftarkan di ClusterControl. Anda dapat memverifikasi ini di /etc/cmon.d/cmon_X.cnf Anda, di mana X adalah cluster_id. Misalnya, lihat di bawah:
# grep 'ssh_user' /etc/cmon.d/cmon_27.cnf
ssh_user=maximusmaximus (dalam contoh ini) harus ada di node komputasi GCP Anda. Pengguna di node GCP Anda harus memiliki hak istimewa sudo atau admin super. Itu juga harus diatur dengan akses SSH tanpa kata sandi. Silakan baca dokumentasi kami lebih lanjut tentang pengguna sistem dan hak istimewa yang diperlukan.
Mari kita lihat contoh daftar server di bawah ini (dari GCP console:dasbor Compute Engine):
Pada tangkapan layar di atas, wilayah target kami didasarkan pada AS-Timur wilayah. Seperti disebutkan sebelumnya, jaringan lokal saya diatur melalui lapisan aman melalui GCP (sebaliknya) menggunakan OpenVPN. Jadi komunikasi dari GCP yang menuju ke jaringan lokal saya juga dienkapsulasi melalui terowongan VPN.
Tambahkan Node Budak Ke GCP
Tangkapan layar di bawah menunjukkan bagaimana Anda dapat melakukannya. Lihat gambar di bawah ini:
Seperti yang terlihat pada tangkapan layar kedua, kami menargetkan simpul 10.142.0.12 dan master sumbernya adalah 192.168.70.10. ClusterControl cukup pintar untuk menentukan firewall, modul keamanan, paket, konfigurasi, dan pengaturan yang perlu dilakukan. Lihat di bawah contoh log aktivitas pekerjaan:
Tugas yang cukup sederhana, bukan?
Selesaikan Cluster MySQL GCP
Kita perlu menambahkan dua node lagi ke cluster GCP agar memiliki topologi yang seimbang seperti yang kita miliki di jaringan lokal. Untuk node kedua dan ketiga, pastikan master harus menunjuk ke node GCP Anda. Dalam contoh ini, masternya adalah 10.142.0.12. Lihat di bawah cara melakukannya,
Seperti yang terlihat pada tangkapan layar di atas, saya memilih 10.142.0.12 (budak ) yang merupakan node pertama yang telah kita tambahkan ke dalam cluster. Hasil lengkapnya adalah sebagai berikut,
Pengaturan Akhir Anda untuk Kluster Basis Data Lokasi-Geografis
Dari tangkapan layar terakhir, jenis topologi ini mungkin bukan pengaturan ideal Anda. Sebagian besar, itu harus menjadi pengaturan multi-master, di mana cluster DR Anda berfungsi sebagai cluster siaga, sedangkan lokal Anda berfungsi sebagai cluster aktif utama. Untuk melakukan ini, cukup sederhana di ClusterControl. Lihat tangkapan layar berikut untuk mencapai tujuan ini.
Anda cukup menyeret master Anda saat ini ke master target yang harus setup sebagai penulis utama-siaga untuk berjaga-jaga di tempat Anda dalam bahaya. Dalam contoh ini, kami menyeret host penargetan 10.142.0.12 (node komputasi GCP). Hasil akhirnya ditunjukkan di bawah ini:
Kemudian mencapai hasil yang diinginkan. Mudah, dan sangat cepat untuk menelurkan cluster Database Geo-Location Anda menggunakan Replikasi MySQL.
Kesimpulan
Memiliki Cluster Database Geo-Location bukanlah hal baru. Ini adalah pengaturan yang diinginkan untuk perusahaan dan organisasi yang menghindari SPOF yang menginginkan ketahanan dan RPO yang lebih rendah.
Takeaways utama untuk pengaturan ini adalah keamanan, redundansi, dan ketahanan. Ini juga mencakup seberapa layak dan efisien Anda dapat menerapkan cluster baru Anda ke wilayah geografis yang berbeda. Meskipun ClusterControl dapat menawarkan ini, berharap kami dapat memiliki lebih banyak peningkatan dalam hal ini lebih cepat di mana Anda dapat membuat secara efisien dari cadangan dan menelurkan cluster baru yang berbeda di ClusterControl, jadi pantau terus.
