Pemulihan Penuh Cluster MySQL atau MariaDB Galera dari Cadangan

Melakukan pencadangan rutin klaster database Anda sangat penting untuk ketersediaan tinggi dan pemulihan bencana. Jika karena alasan apa pun Anda kehilangan seluruh cluster dan harus melakukan pemulihan penuh dari pencadangan, Anda akan memerlukan pencadangan yang andal dan terbaru untuk memulai.

Praktik Terbaik untuk Pencadangan

Beberapa rekomendasi yang perlu dipertimbangkan untuk rezim pencadangan terjadwal yang baik:

• Anda harus dapat sepenuhnya pulih dari kegagalan bencana dari setidaknya dua pencadangan penuh sebelumnya. Untuk berjaga-jaga jika cadangan lengkap terbaru rusak, hilang, atau rusak,
• Cadangan Anda harus berisi setidaknya satu cadangan lengkap dalam siklus yang dipilih, biasanya setiap minggu,
• Simpan cadangan jauh dari lokasi data saat ini, sebaiknya di luar situs,
• Gunakan campuran mysqldump dan Xtrabackup untuk keamanan ekstra, dan tidak bergantung pada satu metode,
• Uji pemulihan cadangan Anda secara teratur, mis. setiap dua bulan.

Cadangan penuh mingguan yang dikombinasikan dengan pencadangan tambahan harian biasanya sudah cukup. Menyimpan sejumlah cadangan untuk jangka waktu tertentu selalu merupakan rencana yang baik, mungkin menyimpan setiap cadangan mingguan selama satu bulan. Ini memungkinkan Anda memulihkan database lama jika terjadi keadaan darurat atau jika karena alasan tertentu Anda memiliki file cadangan lokal yang rusak.

mysqldump atau Xtrabackup

mysqldump kemungkinan besar cara paling populer untuk mencadangkan MySQL. Itu melakukan pencadangan logis dari data, membaca dari setiap tabel menggunakan pernyataan SQL kemudian mengekspor data ke file teks. Pemulihan mysqldump semudah membuat file dump. Kelemahan utamanya adalah sangat lambat untuk database besar, tidak 'panas' dan menghapus kumpulan buffer InnoDB.

Xtrabackup melakukan pencadangan panas, tidak mengunci basis data selama pencadangan dan umumnya lebih cepat. Pencadangan panas penting untuk ketersediaan tinggi, karena berjalan tanpa memblokir aplikasi. Ini juga merupakan faktor penting saat digunakan dengan Galera, karena Galera mengandalkan replikasi sinkron. Namun, memulihkan xtrabackup bisa sedikit rumit menggunakan cara manual.

ClusterControl mendukung penjadwalan mysqldump dan Xtrabackup (penuh dan inkremental), serta pemulihan cadangan langsung dari UI.

Pemulihan Penuh dari Cadangan

Dalam posting ini, kami akan menunjukkan cara mengembalikan Xtrabackup (penuh + tambahan) ke cluster kosong yang berjalan di MariaDB Galera Cluster. Langkah-langkah ini juga harus bekerja pada Percona XtraDB Cluster atau Galera Cluster untuk MySQL dari Codership.

Di cluster asli kami, kami memiliki xtrabackup penuh yang dijadwalkan setiap hari, dengan backup tambahan dibuat setiap jam. Cadangan disimpan di ClusterControl seperti yang ditunjukkan pada tangkapan layar berikut:

Sekarang, mari kita asumsikan kita telah kehilangan kluster asli kita dan harus melakukan pemulihan penuh ke kluster baru. Langkah-langkahnya antara lain:

0. Siapkan server ClusterControl baru.
1. Siapkan Cluster MariaDB baru.
2. Ekspor catatan dan file cadangan ke server ClusterControl baru.
3. Mulai proses pemulihan.
4. Mulai node yang tersisa.

Diagram berikut mengilustrasikan arsitektur kita untuk latihan ini:

Langkah 1 - Siapkan Cluster MariaDB Baru

Instal ClusterControl dan terapkan MariaDB Cluster baru. Buka ClusterControl -> Deploy -> Deploy Database Cluster -> MySQL Galera dan tentukan informasi yang diperlukan dalam dialog penerapan:

Klik tombol Deploy dan mulai penerapan. Karena kami hanya memiliki cluster di server lama, maka ID cluster harus sama (ID cluster:1) dalam instance baru ini.

Di server ClusterControl lama, ekspor tabel backup_records ke file dump:

$ mysqldump -uroot -p --single-transaction --no-create-info cmon backup_records > backup_records.sql

Kemudian, lakukan salinan jarak jauh dari file cadangan dari server lama ke server ClusterControl baru:

$ scp -r /root/backups 192.168.55.150:/root/
$ scp ~/backup_records.sql 192.168.55.150:~

Selanjutnya adalah memodifikasi file dump untuk mencerminkan alamat IP server ClusterControl baru. Jangan lupa untuk menghindari titik di alamat IP:

$ sed -i "s/192\.168\.55\.170/192\.168\.55\.150/g" backup_records.sql

Di server ClusterControl baru, impor file dump:

$ mysql -uroot -p cmon < backup_records.sql

Verifikasi bahwa daftar cadangan sudah benar di server ClusterControl baru:

Seperti yang Anda lihat, semua kemunculan alamat IP sebelumnya (192.168.55.170) telah diganti dengan alamat IP baru (192.168.55.150). Sekarang kita siap untuk melakukan restorasi di server baru.

Langkah 3 - Lakukan Pemulihan

Melakukan pemulihan melalui ClusterControl UI adalah langkah tunjuk dan klik sederhana. Pilih cadangan mana yang akan dipulihkan dan klik tombol "Pulihkan". Kami akan memulihkan cadangan tambahan terbaru yang tersedia (Cadangan:9). Klik tombol “Pulihkan” tepat di bawah nama cadangan dan Anda akan disajikan dialog pra-pemulihan berikut:

Sepertinya ukuran cadangannya cukup kecil (165,6 kB). Itu tidak terlalu penting karena ClusterControl akan menyiapkan semua cadangan tambahan yang dikelompokkan di dalam Set Cadangan 6, yang menyimpan Xtrabackup penuh. Anda juga memiliki beberapa opsi pasca-pemulihan:

• Pulihkan cadangan aktif - Pilih node untuk memulihkan cadangan.
• Tmp Dir - Direktori akan digunakan di server ClusterControl lokal sebagai penyimpanan sementara selama persiapan pencadangan. Itu harus sebesar perkiraan direktori data MySQL.
• Bootstrap cluster dari node yang dipulihkan - Karena ini adalah cluster baru, kami akan mengaktifkannya agar ClusterControl akan mem-bootstrap cluster secara otomatis setelah pemulihan berhasil.
• Buat salinan direktori data sebelum memulihkan cadangan - Jika data yang dipulihkan rusak atau tidak seperti yang diharapkan, Anda akan memiliki cadangan dari direktori data MySQL sebelumnya. Karena ini adalah cluster baru, kami akan mengabaikan yang ini.

Restorasi Percona Xtrabackup akan menyebabkan cluster dihentikan. ClusterControl akan:

1. Hentikan semua node dalam cluster.
2. Pulihkan cadangan pada node yang dipilih.
3. Bootstrap node yang dipilih.

Untuk melihat kemajuan pemulihan, buka Aktivitas -> Pekerjaan -> Pulihkan Cadangan dan klik tombol "Rincian Pekerjaan Lengkap". Anda akan melihat sesuatu seperti ini:

Satu hal penting yang perlu Anda lakukan adalah memantau output dari log kesalahan MySQL pada node target (192.168.55.151) selama proses pemulihan. Setelah pemulihan selesai dan selama proses bootstrap, Anda akan melihat baris berikut mulai muncul:

Version: '10.1.22-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:52 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:53 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:54 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:55 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)

Jangan panik. Ini adalah perilaku yang diharapkan karena kumpulan cadangan ini tidak menyimpan kredensial masuk cmon dari kata sandi cmon ClusterControl baru. Itu telah memulihkan/mengganti pengguna cmon lama sebagai gantinya. Yang perlu Anda lakukan adalah memberikan kembali pengguna cmon ke server dengan menjalankan pernyataan berikut pada node DB ini:

GRANT ALL PRIVILEGES ON *.* to [email protected]'192.168.55.150' IDENTIFIED BY 'mynewCMONpassw0rd' WITH GRANT OPTION;
FLUSH PRIVILEGES;

ClusterControl kemudian akan dapat terhubung ke node bootstrap dan menentukan node dan status cadangan. Jika semuanya OK, Anda akan melihat sesuatu seperti ini:

Pada titik ini, node target di-bootstrap dan berjalan. Kita dapat memulai node yang tersisa di bawah Nodes -> pilih node -> Start Node dan centang kotak “Perform an Initial Start”:

Pemulihan sekarang selesai dan Anda dapat mengharapkan Performance -> DB Growth melaporkan ukuran terbaru dari kumpulan data kami yang baru dipulihkan :

Selamat memulihkan!