Pemulihan Bencana Cloud untuk MariaDB dan MySQL

MySQL memiliki tradisi panjang dalam replikasi geografis. Mendistribusikan cluster ke pusat data jarak jauh mengurangi efek latensi geografis dengan mendorong data lebih dekat ke pengguna. Ini juga menyediakan kemampuan untuk pemulihan bencana. Karena biaya yang signifikan untuk menduplikasi perangkat keras di situs terpisah, tidak banyak perusahaan yang mampu membelinya di masa lalu. Biaya lainnya adalah staf terampil yang mampu merancang, menerapkan, dan memelihara lingkungan beberapa pusat data yang canggih.

Dengan revolusi otomatisasi Cloud dan DevOps, pusat data terdistribusi tidak pernah semudah ini diakses oleh massa. Penyedia cloud meningkatkan jangkauan layanan yang mereka tawarkan dengan harga yang lebih baik. Seseorang dapat membangun lingkungan hybrid lintas cloud dengan data yang tersebar di seluruh dunia. Seseorang dapat membuat rencana DR yang fleksibel dan terukur untuk mendekati berbagai skenario gangguan. Dalam beberapa kasus, itu hanya bisa menjadi cadangan yang disimpan di luar kantor. Dalam kasus lain, ini dapat berupa salinan 1 banding 1 dari lingkungan produksi yang berjalan di tempat lain.

Di blog ini kita akan melihat beberapa kasus ini, dan membahas skenario umum.

Menyimpan Cadangan di Cloud

Rencana DR adalah istilah umum yang menggambarkan proses untuk memulihkan sistem TI yang terganggu dan aset penting lainnya yang digunakan organisasi. Backup adalah metode utama untuk mencapai hal ini. Saat cadangan berada di pusat data yang sama dengan server produksi Anda, Anda berisiko kehilangan semua data jika Anda kehilangan pusat data tersebut. Untuk menghindarinya, Anda harus memiliki kebijakan untuk membuat salinan di lokasi fisik lain. Ini masih merupakan praktik yang baik untuk menyimpan cadangan pada disk untuk mengurangi waktu yang dibutuhkan untuk memulihkan. Dalam kebanyakan kasus, Anda akan menyimpan cadangan utama di pusat data yang sama (untuk meminimalkan waktu pemulihan), tetapi Anda juga harus memiliki cadangan yang dapat digunakan untuk memulihkan prosedur bisnis saat pusat data utama tidak berfungsi.

ClusterControl memungkinkan integrasi tanpa batas antara lingkungan database Anda dan cloud. Ini memberikan opsi untuk memigrasi data ke cloud. Kami menawarkan kombinasi lengkap cadangan basis data untuk Amazon Web Services (AWS), Layanan Google Cloud, atau Microsoft Azure. Pencadangan sekarang dapat dijalankan, dijadwalkan, diunduh, dan dipulihkan langsung dari penyedia cloud pilihan Anda. Kemampuan ini memberikan peningkatan redundansi, opsi pemulihan bencana yang lebih baik, dan manfaat baik dalam kinerja maupun penghematan biaya.

Langkah pertama untuk menyiapkan "kegagalan pusat data - cadangan bukti" adalah memberikan kredensial untuk operator cloud Anda. Anda dapat memilih dari beberapa vendor di sini. Mari kita lihat proses yang disiapkan untuk operator cloud paling populer - AWS.

Yang Anda butuhkan hanyalah ID Kunci AWS dan rahasia untuk wilayah tempat Anda ingin menyimpan cadangan. Anda bisa mendapatkannya dari konsol AWS. Anda dapat mengikuti beberapa langkah untuk mendapatkannya.

1. Gunakan alamat email dan kata sandi akun AWS Anda untuk masuk ke AWS Management Console sebagai pengguna root akun AWS.
2. Pada halaman Dasbor IAM, pilih nama akun Anda di bilah navigasi, lalu pilih Kredensial Keamanan Saya .
3. Jika Anda melihat peringatan tentang mengakses kredensial keamanan untuk akun AWS Anda, pilih untuk Lanjutkan ke Kredensial Keamanan .
4. Luaskan bagian Kunci akses (ID kunci akses dan kunci akses rahasia).
5. Pilih untuk Buat Kunci Akses Baru . Kemudian pilih Unduh File Kunci untuk menyimpan ID kunci akses dan kunci akses rahasia ke file di komputer Anda. Setelah Anda menutup kotak dialog, Anda tidak akan dapat mengambil kembali kunci akses rahasia ini.

Setelah semuanya diatur, Anda dapat menyesuaikan jadwal pencadangan dan mengaktifkan opsi pencadangan ke cloud. Untuk mengurangi lalu lintas jaringan, pastikan untuk mengaktifkan kompresi data. Itu membuat cadangan lebih kecil dan meminimalkan waktu yang dibutuhkan untuk mengunggah. Praktik baik lainnya adalah mengenkripsi cadangan. ClusterControl membuat kunci secara otomatis dan menggunakannya jika Anda memutuskan untuk memulihkannya. Kebijakan pencadangan lanjutan harus memiliki waktu penyimpanan yang berbeda untuk cadangan yang disimpan di server di pusat data yang sama, dan cadangan yang disimpan di lokasi fisik lain. Anda harus menyetel periode penyimpanan yang lebih lama untuk pencadangan berbasis cloud, dan periode yang lebih singkat untuk cadangan yang disimpan di dekat lingkungan produksi, karena kemungkinan pemulihan menurun seiring dengan masa pakai cadangan.

Perluas Cluster Anda Dengan Replikasi Asinkron

Galera dengan replikasi asinkron dapat menjadi solusi yang sangat baik untuk membangun simpul DR aktif di pusat data jarak jauh. Ada beberapa alasan bagus untuk memasang slave asinkron ke Galera Cluster. Kueri jenis OLAP yang berjalan lama pada node Galera mungkin memperlambat seluruh cluster. Dengan opsi penerapan penundaan, replikasi yang tertunda dapat menyelamatkan Anda dari kesalahan manusia sehingga semua entri emas tersebut tidak akan segera diterapkan ke node cadangan Anda.

Di ClusterControl, memperluas grup node Galera dengan replikasi asinkron dilakukan dalam satu halaman wizard. Anda perlu memberikan informasi yang diperlukan tentang masa depan Anda atau server budak yang ada. Slave akan diatur dari cadangan yang ada, atau XtraBackup yang baru saja dialirkan dari master ke slave.

Load Balancer di Multi-Datacenter

Load balancer adalah komponen penting dalam ketersediaan tinggi database MySQL dan MariaDB. Tidaklah cukup untuk memiliki klaster yang mencakup beberapa pusat data. Anda masih memerlukan layanan Anda untuk mengaksesnya. Kegagalan penyeimbang beban yang tersedia di satu pusat data akan membuat seluruh lingkungan Anda tidak dapat dijangkau.

Salah satu metode populer untuk menyembunyikan kompleksitas lapisan basis data dari suatu aplikasi adalah dengan menggunakan proxy. Proxy bertindak sebagai titik masuk ke database, mereka melacak keadaan node database dan harus selalu mengarahkan lalu lintas hanya ke node yang tersedia. ClusterControl memudahkan penerapan dan konfigurasi beberapa teknologi penyeimbangan beban yang berbeda untuk MySQL dan MariaDB, termasuk ProxySQL, HAProxy, dengan antarmuka grafis tunjuk dan klik.

Hal ini juga memungkinkan membuat komponen ini berlebihan dengan menambahkan keepalive di atasnya. Untuk mencegah penyeimbang beban Anda menjadi satu titik kegagalan, seseorang akan menyiapkan dua instans HAProxy, ProxySQL atau MariaDB Maxscale yang identik (satu aktif dan satu lagi di DC berbeda) dan menggunakan Keepalive untuk menjalankan Virtual Router Redundancy Protocol (VRRP) antara mereka. VRRP memberikan alamat IP Virtual ke penyeimbang beban aktif dan mentransfer IP Virtual ke HAProxy siaga jika terjadi kegagalan. Ini mulus karena dua instance proxy tidak memerlukan status bersama.

Tentu saja, ada banyak hal yang perlu dipertimbangkan untuk membuat database Anda kebal terhadap kegagalan pusat data.
Perencanaan dan otomatisasi yang tepat akan membuatnya bekerja! Selamat Mengelompokkan!