Cara Mencadangkan dan Mengembalikan ClusterControl

ClusterControl 1.7.1 memperkenalkan fitur baru yang memungkinkan Anda untuk membuat cadangan server ClusterControl Anda dan memulihkannya (bersama dengan metadata tentang database terkelola Anda) ke server lain. Ini mencadangkan aplikasi ClusterControl serta semua data konfigurasinya. Migrasi ClusterControl ke server baru dulunya menyusahkan, tapi sekarang tidak lagi.

Entri blog ini memandu Anda melalui fitur baru ini.

Kami akan memigrasikan ClusterControl dari satu server ke server lain, mempertahankan semua konfigurasi dan pengaturan.

Kami juga akan menunjukkan cara mentransfer pengelolaan cluster dari satu instance ClusterControl ke instance lainnya.

Contoh arsitektur kami dimulai dengan dua klaster produksi (ditunjukkan pada tangkapan layar di bawah):

• ID Cluster 1:3 node Galera (PXC) + 1 HAProxy + 1 ProxySQL (5 node)
• ID Cluster 2:1 MySQL master + 2 MySQL slave + 1 ProxySQL (4 node)

Pengantar

ClusterControl CLI (s9s) adalah alat antarmuka baris perintah untuk berinteraksi, mengontrol, dan mengelola cluster database menggunakan Platform ClusterControl. Mulai dari versi 1.4.1, skrip penginstal akan menginstal paket ini secara otomatis pada node ClusterControl.

Pada dasarnya ada 4 opsi baru yang diperkenalkan di bawah perintah "s9s backup", yang dapat digunakan untuk mencapai tujuan kita:

Posting blog ini akan membahas contoh kasus penggunaan tentang cara memanfaatkan opsi tersebut. Saat ini, mereka berada dalam tahap kandidat rilis dan hanya tersedia melalui alat CLI ClusterControl.

Mencadangkan ClusterControl

Untuk melakukan ini, server ClusterControl harus setidaknya pada v1.7.1 dan yang lebih baru. Untuk mencadangkan pengontrol ClusterControl, cukup jalankan perintah berikut pada node ClusterControl sebagai pengguna root (atau dengan sudo):

$ s9s backup \
--save-controller \
--backup-directory=$HOME/ccbackup \
--output-file=controller.tar.gz \
--log

--output-file harus berupa nama file atau jalur fisik (jika Anda ingin menghilangkan flag --backup-directory), dan file tersebut tidak boleh ada sebelumnya. ClusterControl tidak akan mengganti file output jika sudah ada. Dengan menentukan --log, itu akan menunggu sampai pekerjaan dijalankan dan log pekerjaan akan ditampilkan di terminal. Log yang sama dapat diakses melalui ClusterControl UI di bawah Aktivitas -> Pekerjaan -> Simpan Pengontrol :

Pekerjaan 'Simpan Pengontrol' pada dasarnya melakukan prosedur berikut:

1. Ambil konfigurasi pengontrol dan ekspor ke JSON
2. Ekspor database CMON sebagai file dump MySQL
3. Untuk setiap klaster basis data:
   1. Ambil konfigurasi cluster dan ekspor ke JSON

Pada output, Anda mungkin melihat pekerjaan yang ditemukan adalah N + 1 cluster, misalnya "Menemukan 3 cluster untuk disimpan" meskipun kami hanya memiliki dua cluster database. Ini termasuk cluster ID 0, yang membawa arti khusus di ClusterControl sebagai cluster yang diinisialisasi global. Namun, itu bukan milik komponen CmonCluster, yang merupakan cluster database di bawah manajemen ClusterControl.

Memulihkan ClusterControl ke Server ClusterControl baru

Seharusnya ClusterControl sudah terinstal di server baru, kami ingin memigrasi cluster database untuk dikelola oleh server baru. Diagram berikut mengilustrasikan latihan migrasi kami:

Pertama, transfer backup dari server lama ke server baru:

$ scp $HOME/ccbackup/controller.tar.gz 192.168.0.190:~

Sebelum melakukan pemulihan, kita harus menyiapkan SSH tanpa kata sandi ke semua node dari server ClusterControl baru:

$ ssh-copy-id 192.168.0.11 #proxysql cluster 1
$ ssh-copy-id 192.168.0.12 #proxysql cluster 1
$ ssh-copy-id 192.168.0.21 #pxc cluster 1
$ ssh-copy-id 192.168.0.22 #pxc cluster 1
$ ssh-copy-id 192.168.0.23 #pxc cluster 1
$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2

Kemudian, di server baru, lakukan pemulihan:

$ s9s backup \
--restore-controller \
--input-file=$HOME/controller.tar.gz \
--debug \
--log

Kemudian kita harus menyinkronkan cluster di UI dengan masuk ke Global Settings -> Cluster Registrations -> Synchronize Cluster . Kemudian jika Anda kembali ke dasbor utama ClusterControl, Anda akan melihat yang berikut:

Jangan panik. UI ClusterControl baru tidak dapat mengambil data pemantauan dan pengelolaan karena token API RPC yang salah. Kita hanya perlu memperbaruinya sesuai dengan itu. Pertama, ambil nilai rpc_key untuk masing-masing cluster:

$ cat /etc/cmon.d/cmon_*.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=8fgkzdW8gAm2pL4L
cluster_id=2
rpc_key=tAnvKME53N1n8vCC

Di UI, klik tautan "di sini" di baris "Ubah token API RPC di sini". Maka akan muncul dialog berikut:

Rekatkan nilai rpc_key masing-masing di bidang teks dan klik Simpan. Ulangi untuk cluster berikutnya. Tunggu beberapa saat dan daftar cluster akan di-refresh secara otomatis.

Langkah terakhir adalah memperbaiki hak pengguna MySQL cmon untuk perubahan alamat IP ClusterControl baru, 192.168.0.190. Login ke salah satu node PXC dan jalankan perintah berikut:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** Ganti dengan password cmon MySQL yang sama seperti pada nilai mysql_password di dalam /etc/cmon.cnf. Ulangi langkah yang sama pada cluster kedua, replikasi MySQL tetapi hanya jalankan sekali pada master node.

Setelah hak istimewa diatur, Anda akan melihat daftar cluster berwarna hijau, mirip dengan yang lama:

Perlu disebutkan bahwa secara default, ClusterControl akan menonaktifkan pemulihan otomatis cluster (seperti yang Anda lihat ikon merah di sebelah kata 'Cluster') untuk menghindari kondisi balapan dengan instance ClusterControl lainnya. Sebaiknya aktifkan fitur ini (dengan mengeklik ikon berwarna hijau) setelah server lama dinonaktifkan.

Migrasi kami sekarang selesai. Semua konfigurasi dan pengaturan dari server lama disimpan dan ditransfer ke server baru.

Memigrasikan Pengelolaan Cluster ke Server ClusterControl Lain

Mencadangkan Informasi Cluster

Ini tentang mencadangkan metadata dan informasi cluster sehingga kami dapat mentransfernya ke server ClusterControl lain, juga dikenal sebagai pencadangan parsial. Jika tidak, kita harus melakukan "Impor Server/Cluster yang Ada" untuk mengimpornya kembali ke ClusterControl baru yang berarti Anda akan kehilangan data pemantauan dari server lama. Jika Anda memiliki penyeimbang beban atau instans budak asinkron, ini harus diimpor setelah kluster diimpor, satu node pada satu waktu. Jadi agak merepotkan jika Anda memiliki satu set lengkap penyiapan produksi.

Latihan migrasi cluster "manajer" diilustrasikan dalam diagram berikut:

Pada dasarnya, kami ingin memigrasikan Replikasi MySQL kami (ID cluster:2) untuk dikelola oleh instance ClusterControl lain. Kami akan menggunakan opsi --save-cluster-info dan --restore-cluster-info untuk yang satu ini. Opsi --save-cluster-info akan mengekspor informasi cluster yang sesuai untuk disimpan di tempat lain. Mari ekspor Cluster Replikasi MySQL kita (ID cluster:2). Pada server ClusterControl saat ini, lakukan:

$ s9s backup \
--save-cluster-info \
--cluster-id=2 \
--backup-directory=$HOME/ccbackup \
--output-file=cc-replication-2.tar.gz \
--log

Anda akan melihat banyak baris baru tercetak di terminal, menunjukkan pekerjaan pencadangan sedang berjalan (outputnya juga dapat diakses melalui ClusterControl -> Activity -> Jobs ):

Jika Anda melihat log pekerjaan dengan cermat, Anda akan melihat pekerjaan itu mencoba mengekspor semua informasi dan metadata terkait untuk ID cluster 2. Outputnya disimpan sebagai file terkompresi dan terletak di bawah jalur yang telah kami tentukan di bawah menggunakan --backup -tanda direktori. Jika flag ini diabaikan, ClusterControl akan menyimpan output ke direktori backup default yang merupakan direktori home dari pengguna SSH, di bawah $HOME/backups.

Memulihkan Informasi Cluster

Langkah-langkah yang dijelaskan di sini mirip dengan langkah-langkah pemulihan untuk cadangan penuh ClusterControl. Transfer cadangan dari server saat ini ke server ClusterControl lainnya:

$ scp $HOME/ccbackup/cc-replication-2.tar.gz 192.168.0.190:~

Sebelum melakukan pemulihan, kita harus menyiapkan SSH tanpa kata sandi ke semua node dari server ClusterControl baru:

$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2
$ ssh-copy-id 192.168.0.19 #prometheus cluster 2

Kemudian, di server baru, lakukan pemulihan informasi cluster untuk Replikasi MySQL kami:

$ s9s backup \
--restore-cluster-info \
--input-file=$HOME/cc-replication-2.tar.gz \
--log

Anda dapat memverifikasi kemajuan di bawah Aktivitas -> Pekerjaan -> Pulihkan Cluster :

Jika Anda melihat pesan pekerjaan dengan cermat, Anda dapat melihat bahwa ClusterControl secara otomatis menetapkan ulang ID cluster ke 1 pada instance baru ini (itu adalah ID cluster 2 pada instance lama).

Kemudian sinkronkan cluster di UI dengan membuka Global Settings -> Cluster Registrations -> Synchronize Cluster . Jika Anda kembali ke dasbor utama ClusterControl, Anda akan melihat yang berikut:

Kesalahan berarti UI ClusterControl baru tidak dapat mengambil data pemantauan dan pengelolaan karena token API RPC yang salah. Kita hanya perlu memperbaruinya sesuai dengan itu. Pertama, ambil nilai rpc_key untuk ID cluster kami 1:

$ cat /etc/cmon.d/cmon_1.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=tAnvKME53N1n8vCC

Di UI, klik tautan "di sini" di baris "Ubah token API RPC di sini". Maka akan muncul dialog berikut:

Rekatkan nilai rpc_key masing-masing di bidang teks dan klik Simpan. Tunggu beberapa saat dan daftar cluster akan di-refresh secara otomatis.

Langkah terakhir adalah memperbaiki hak pengguna MySQL cmon untuk perubahan alamat IP ClusterControl baru, 192.168.0.190. Masuk ke master node (192.168.0.31) dan jalankan pernyataan berikut:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** Ganti dengan password cmon MySQL yang sama seperti pada nilai mysql_password di dalam /etc/cmon.cnf.

Anda juga dapat mencabut hak pengguna lama (mencabut tidak akan menghapus pengguna) atau cukup lepaskan pengguna lama:

$ mysql -uroot -p -e 'DROP USER [email protected]"192.168.0.19"'

Setelah hak istimewa diatur, Anda akan melihat semuanya berwarna hijau:

Pada titik ini, arsitektur kita terlihat seperti ini:

Latihan migrasi kami sekarang selesai.

Pemikiran Terakhir

Sekarang dimungkinkan untuk melakukan pencadangan penuh dan sebagian dari instans ClusterControl Anda dan kluster yang mereka kelola, memungkinkan Anda untuk memindahkannya secara bebas antar host dengan sedikit usaha. Saran dan masukan diterima.