Migrasi Jaringan Tanpa Waktu Henti Dengan MySQL Galera Cluster Menggunakan Relay Node

Penyediaan node otomatis Galera Cluster menyederhanakan kerumitan penskalaan cluster database dengan konsistensi data yang terjamin. SST dan IST meningkatkan kegunaan sinkronisasi data awal tanpa perlu membuat cadangan database secara manual dan menyalinnya ke node baru. Menggabungkan ini dengan kemampuan Galera untuk mentolerir pengaturan jaringan yang berbeda (misalnya, replikasi WAN), kami sekarang dapat memigrasikan database antara jaringan terisolasi yang berbeda tanpa gangguan layanan.

Dalam posting blog ini, kita akan melihat bagaimana cara memigrasi Cluster MySQL Galera kita tanpa downtime. Kami akan memindahkan database dari Amazon Web Service (AWS) EC2 ke Google Cloud Platform (GCP) Compute Engine, dengan bantuan node relai. Perhatikan bahwa kami memiliki entri blog serupa di masa lalu, tetapi yang ini menggunakan pendekatan yang berbeda.

Diagram berikut menyederhanakan rencana migrasi kami:

Persiapan Situs Lama

Karena kedua situs tidak dapat berkomunikasi satu sama lain karena grup keamanan atau isolasi VPC, kita perlu memiliki node relai untuk menjembatani kedua situs ini bersama-sama. Node ini dapat ditemukan di kedua situs, tetapi harus dapat terhubung ke satu atau lebih node di sisi lain pada port 3306 (MySQL), 4444 (SST), 4567 (gcomm) dan 4568 (IST). Inilah yang sudah kami miliki, dan bagaimana kami akan menskalakan situs lama:

Anda juga dapat menggunakan node Galera yang ada (misalnya node ketiga) sebagai node relai, selama node tersebut memiliki konektivitas ke sisi lain. Kelemahannya adalah kapasitas cluster akan berkurang menjadi dua, karena satu node akan digunakan untuk SST dan menyampaikan aliran replikasi Galera antar situs. Bergantung pada ukuran kumpulan data dan koneksi antar situs, hal ini dapat menimbulkan masalah keandalan basis data pada klaster saat ini.

Jadi, kita akan menggunakan node keempat, untuk mengurangi risiko pada kluster produksi saat ini saat menyinkronkan ke sisi lain. Pertama, buat instans baru di AWS Dashboard dengan alamat IP publik (sehingga dapat berbicara dengan dunia luar) dan izinkan port komunikasi Galera yang diperlukan (TCP 3306, 4444, 4567-4568).

Deploy node keempat (relay node) di situs lama. Jika Anda menggunakan ClusterControl, Anda cukup menggunakan fitur "Tambah Node" untuk menskalakan cluster (jangan lupa untuk mengatur SSH tanpa kata sandi dari node ClusterControl ke host keempat ini sebelumnya):

Pastikan node relai sinkron dengan cluster saat ini dan dapat berkomunikasi ke sisi lain.

Dari situs baru, kita akan terhubung ke node relay karena ini adalah satu-satunya node yang memiliki konektivitas ke dunia luar.

Penerapan Situs Baru

Di situs baru, kami akan menerapkan pengaturan serupa dengan satu node ClusterControl dan tiga node Galera Cluster. Kedua situs harus menggunakan versi MySQL yang sama. Inilah arsitektur kami di situs baru:

Dengan ClusterControl, penyebaran cluster baru hanya dengan beberapa klik saja dan fitur gratis di edisi komunitas. Buka ClusterControl -> Deploy Database Cluster -> MySQL Galera dan ikuti wizard penerapan:

Klik Terapkan dan pantau kemajuannya di bawah Aktivitas -> Pekerjaan -> Buat Cluster. Setelah selesai, Anda harus memiliki yang berikut di dasbor:

Pada titik ini, Anda memiliki dua Cluster Galera yang terpisah - 4 node di situs lama dan 3 node di situs baru.

Menghubungkan Kedua Situs

Di situs baru (GCP), pilih satu node untuk berkomunikasi dengan node relai di situs lama. Kita akan memilih galera-gcp1 sebagai konektor ke node relay (galera-aws4). Diagram berikut mengilustrasikan rencana menjembatani kami:

Hal penting yang harus dikonfigurasi adalah parameter berikut:

wsrep_sst_donor :wsrep_node_name dari simpul donor. Di galera-gcp1, setel donor ke galera-aws4.
wsrep_sst_auth :Kredensial pengguna SST dalam format nama pengguna:sandi harus mengikuti situs lama (AWS).
wsrep_sst_receive_address :Alamat IP yang akan menerima SST pada node joiner. Di galera-gcp1, setel ini ke alamat IP publik dari node ini.
wsrep_cluster_address :String koneksi Galera. Di galera-gcp1, tambahkan alamat IP publik galera-aws4.
wsrep_provider_options :
- gmcast.segment:Defaultnya adalah 0. Tetapkan bilangan bulat yang berbeda pada semua node di GCP.

Pada node relai (galera-aws4), ambil wsrep_node_name:

$ mysql -uroot -p -e 'SELECT @@wsrep_node_name'
Enter password:
+-------------------+
| @@wsrep_node_name |
+-------------------+
| 10.0.0.13         |
+-------------------+

Di my.cnf galera-gcp1, setel wsrep_sst_donor nilai ke wsrep_node_name node relai dan wsrep_sst_receive_address ke alamat IP publik galera-gcp1:
```
wsrep_sst_donor=10.0.0.13
wsrep_sst_receive_address=35.197.136.232
```
Di semua node di GCP, pastikan wsrep_sst_auth nilainya identik dengan situs lama (AWS) dan ubah segmen Galera menjadi 1 (sehingga Galera tahu kedua situs berada di jaringan yang berbeda):
```
wsrep_sst_auth=backupuser:mysecretP4ssW0rd
wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"
```
Pada galera-gcp1, setel wsrep_cluster_address untuk menyertakan alamat IP publik node relai:
```
wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149
```
**Hanya ubah wsrep_cluster_address di galera-gcp1. Jangan ubah parameter ini di galera-gcp2 dan galera-gcp3.
Hentikan semua node di GCP. Jika Anda menggunakan ClusterControl, buka dropdown Cluster Actions -> Stop Cluster. Anda juga diharuskan untuk menonaktifkan pemulihan otomatis di tingkat cluster dan node, sehingga ClusterControl tidak akan mencoba memulihkan node yang gagal.

Sekarang bagian sinkronisasi. Mulai galera-gcp1. Anda dapat melihat dari log kesalahan MySQL pada node donor bahwa SST dimulai antara node relai (10.0.0.13) menggunakan alamat publik di galera-gcp1 (35.197.136.232):

2017-12-19T13:58:04.765238Z 0 [Note] WSREP: Initiating SST/IST transfer on DONOR side (wsrep_sst_xtrabackup-v2 --role 'donor' --address '35.197.136.232:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/m
ysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix ''   '' --gtid 'df23adb8-b567-11e7-8c50-a386c8cc7711:151181')
2017-12-19T13:58:04.765468Z 5 [Note] WSREP: DONOR thread signaled with 0
        2017-12-19T13:58:15.158757Z WSREP_SST: [INFO] Streaming the backup to joiner at 35.197.136.232 4444
2017-12-19T13:58:52.512143Z 0 [Note] WSREP: 1.0 (10.0.0.13): State transfer to 0.0 (10.148.0.2) complete.

Perhatikan bahwa, pada saat ini, galera-gcp1 akan dibanjiri dengan baris berikut:

2017-12-19T13:32:47.111002Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.118:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:48.111123Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.90:4567 timed out, no messages seen in PT3S
2017-12-19T13:32:50.611462Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.25:4567 timed out, no messages seen in PT3S

Anda dapat mengabaikan peringatan ini dengan aman karena galera-gcp1 terus mencoba melihat node yang tersisa di luar node relai di AWS.

Setelah SST di galera-gcp1 selesai, ClusterControl di GCE tidak akan dapat menghubungkan node database, karena GRANT yang hilang (GRANT yang ada telah diganti setelah disinkronkan dari AWS). Jadi, inilah yang perlu kita lakukan setelah SST selesai di galera-gcp1:
```
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;
```
Setelah ini selesai, ClusterControl akan melaporkan status galera-gcp1 dengan benar seperti yang disorot di bawah ini:
Bagian terakhir adalah memulai galera-gcp2 dan galera-gcp3 yang tersisa, satu per satu. Pergi ke ClusterControl -> Nodes -> pilih node -> Start Node. Setelah semua node disinkronkan, Anda akan mendapatkan 7 sebagai ukuran cluster:

Cluster sekarang beroperasi di kedua situs dan penskalaan selesai.

Penonaktifan

Setelah migrasi selesai dan semua node disinkronkan, Anda dapat mulai mengalihkan aplikasi ke cluster baru di GCP:

Pada titik ini data MySQL direplikasi ke semua node sampai dekomisioning. Kinerja replikasi akan sebaik node terjauh dalam izin cluster. Node relai sangat penting, karena menyiarkan set tulis ke sisi lain. Dari sudut pandang aplikasi, disarankan untuk menulis hanya ke satu situs dalam satu waktu, yang berarti Anda harus mulai mengalihkan baca/tulis dari AWS dan menayangkannya dari cluster GCP.

Untuk menonaktifkan node database lama dan pindah ke cluster di GCP, kita harus melakukan shutdown yang baik (satu node pada satu waktu) di AWS. Sangat penting untuk mematikan node dengan anggun, karena situs AWS memiliki jumlah node terbanyak (4/7) untuk cluster ini. Menonaktifkan semuanya sekaligus akan menyebabkan cluster di GCP beralih ke status non-utama, sehingga memaksa cluster untuk menolak operasi. Pastikan node terakhir yang dimatikan di sisi AWS adalah node relai.

Jangan lupa untuk memperbarui parameter berikut di galera-gcp1 sesuai dengan itu:

wsrep_cluster_address - Hapus alamat IP publik simpul relai.
wsrep_sst_donor - Komentari baris ini. Biarkan Galera memilih donor secara otomatis.
wsrep_sst_receive_address - Komentari baris ini. Biarkan Galera memilih antarmuka penerima secara otomatis.

Cluster Galera Anda sekarang berjalan di platform, host, dan jaringan yang benar-benar baru tanpa waktu henti sedetik pun ke layanan database Anda selama migrasi. Keren banget kan?