Untuk semua yang tidak akrab dengan Vitess, ini adalah sistem basis data berbasis MySQL yang dimaksudkan untuk memberikan sistem manajemen basis data relasional yang mudah diskalakan. Kami tidak akan masuk ke detail tentang desain tetapi, singkatnya, Vitess terdiri dari node proxy yang mengarahkan permintaan, gateway yang mengelola node database dan, akhirnya, node database MySQL itu sendiri, yang dimaksudkan untuk menyimpan data. Jika kita berbicara tentang MySQL, orang mungkin berpikir jika ada opsi untuk, sebenarnya, menggunakan alat eksternal seperti, misalnya, ClusterControl untuk mengelola basis data yang mendasarinya. Jawaban singkatnya adalah “ya”. Jawaban yang lebih panjang adalah posting blog ini.
MySQL di Vitess
Pertama-tama, kami ingin membahas sedikit tentang bagaimana Vitess menggunakan MySQL. Arsitektur tingkat tinggi dijelaskan pada halaman dokumentasi Vitess. Singkatnya, kami memiliki VTGate yang bertindak sebagai proxy, kami memiliki Layanan Topologi yang merupakan penyimpanan metadata berdasarkan Zookeeper, Consul atau Dll, di mana semua informasi tentang node dalam sistem berada, akhirnya kami memiliki VTTablets, yang bertindak sebagai perantara antara instance VTGate dan MySQL. Instans MySQL dapat berdiri sendiri atau dapat dikonfigurasi menggunakan replikasi standar asinkron (atau semi sinkron). MySQL digunakan untuk menyimpan data. Data dapat dipecah menjadi pecahan, dalam hal ini instance MySQL akan berisi subset data.
Semua ini bekerja dengan baik. Vitess dapat menentukan node mana yang menjadi master, node mana yang menjadi slave, merutekan kueri yang sesuai. Ada beberapa masalah, meskipun. Tidak semua fungsionalitas paling dasar diberikan oleh Vitess. Deteksi topologi dan perutean kueri, ya. Cadangan - ya juga, Vitess dapat dikonfigurasi untuk mengambil cadangan data dan memungkinkan pengguna untuk memulihkan apa pun yang telah dicadangkan. Sayangnya, tidak ada dukungan internal untuk failover otomatis. Tidak ada UI tren yang tepat yang akan membantu pengguna untuk memahami keadaan database dan beban kerja mereka. Untungnya, saat kita berbicara tentang MySQL standar, kita dapat dengan mudah menggunakan solusi eksternal untuk mencapai hal ini. Misalnya, untuk failover, Vitess dapat diintegrasikan dengan Orchestrator. Mari kita lihat bagaimana ClusterControl dapat digunakan bersama dengan Vitess untuk menyediakan manajemen, pemantauan, dan failover.
Menyebarkan cluster database baru menggunakan ClusterControl
Pertama, mari kita terapkan cluster baru. Seperti biasa dengan ClusterControl, Anda harus menyediakan perangkat keras dan memastikan bahwa ClusterControl dapat mengakses node tersebut menggunakan SSH.
Pertama, kita harus mendefinisikan konektivitas SSH.
Selanjutnya, kita akan memilih vendor dan versinya. Menurut dokumentasi, Vitess mendukung MySQL dan Server Percona di versi 5.7 dan 8.0 (walaupun tidak mendukung metode caching_sha2_password sehingga Anda harus berhati-hati saat membuat pengguna). Ini juga mendukung MariaDB hingga 10.3.
Akhirnya, kita mendefinisikan topologi. Setelah mengklik “Deploy”, ClusterControl akan melakukan penerapan cluster.
Setelah siap, Anda akan melihat cluster dan Anda harus dapat mengelolanya menggunakan ClusterControl. Jika Pemulihan Otomatis untuk Cluster dan Node diaktifkan, ClusterControl akan melakukan failover otomatis jika diperlukan.
Anda juga akan mendapat manfaat dari pemantauan berbasis agen di bagian “Dasbor” dari UI ClusterControl.
Mengimpor cluster ke Vitess
Sebagai langkah selanjutnya kita harus men-deploy Vitess. Apa yang kami jelaskan di sini sama sekali bukan pengaturan tingkat produksi oleh karena itu kami akan mengambil jalan pintas dan hanya menggunakan suite Vitess pada satu node mengikuti tutorial dari dokumentasi Vitess. Untuk membuatnya lebih mudah untuk ditangani, kami akan menggunakan panduan Instalasi Lokal, yang akan menerapkan semua layanan, bersama dengan contoh database pada satu node. Buatlah cukup besar untuk menampung mereka. Untuk tujuan pengujian, node dengan beberapa inti CPU dan memori 4 GB sudah cukup.
Mari kita asumsikan bahwa semuanya berjalan dengan baik dan Anda memiliki penerapan Vitess lokal yang berjalan di node. Langkah selanjutnya adalah mengimpor cluster kami yang digunakan oleh ClusterControl ke Vitess. Untuk itu kita harus menjalankan dua VTTablet lagi. Pertama, kita akan membuat direktori untuk VTTablet tersebut:
[email protected]:~$ cd /home/vagrant/my-vitess-example/
[email protected]:~/my-vitess-example$ source env.sh
[email protected]:~/my-vitess-example$ mkdir $VTDATAROOT/vt_0000000401
[email protected]:~/my-vitess-example$ mkdir $VTDATAROOT/vt_0000000402Kemudian, pada database, kita akan membuat pengguna yang akan digunakan Vitess untuk menghubungkan dan mengelola database.
mysql> CREATE USER [email protected]'%' IDENTIFIED BY 'pass';
Query OK, 0 rows affected (0.01 sec)
mysql> GRANT ALL ON *.* TO [email protected]'%' WITH GRANT OPTION;
Query OK, 0 rows affected (0.01 sec)Jika kita mau, kita mungkin juga ingin membuat lebih banyak pengguna. Vitess memungkinkan kami untuk melewati beberapa pengguna dengan hak akses yang berbeda:pengguna aplikasi, pengguna DBA, pengguna replikasi, pengguna dengan hak penuh, dan beberapa lainnya.
Hal terakhir yang harus kita lakukan adalah menonaktifkan super_read_only di semua MySQL node karena Vitess akan mencoba membuat metadata pada replika, mengakibatkan upaya yang gagal untuk memulai layanan vttablet.
Setelah ini selesai, kita harus memulai VTTablets. Dalam kedua kasus tersebut, kita harus memastikan bahwa port tersebut unik dan bahwa kita memberikan kredensial yang benar untuk mengakses instance database:
vttablet $TOPOLOGY_FLAGS -logtostderr -log_queries_to_file $VTDATAROOT/tmp/vttablet_0000000401_querylog.txt -tablet-path "zone1-0000000401" -init_keyspace clustercontrol -init_shard 0 -init_tablet_type replica -port 15401 -grpc_port 16401 -service_map 'grpc-queryservice,grpc-tabletmanager,grpc-updatestream' -pid_file $VTDATAROOT/vt_0000000401/vttablet.pid -vtctld_addr http://localhost:15000/ -db_host 10.0.0.181 -db_port 3306 -db_app_user vtuser -db_app_password pass -db_dba_user vtuser -db_dba_password pass -db_repl_user vtuser -db_repl_password pass -db_filtered_user vtuser -db_filtered_password pass -db_allprivs_user vtuser -db_allprivs_password pass -init_db_name_override clustercontrol -init_populate_metadata &
vttablet $TOPOLOGY_FLAGS -logtostderr -log_queries_to_file $VTDATAROOT/tmp/vttablet_0000000402_querylog.txt -tablet-path "zone1-0000000402" -init_keyspace clustercontrol -init_shard 0 -init_tablet_type replica -port 15402 -grpc_port 16402 -service_map 'grpc-queryservice,grpc-tabletmanager,grpc-updatestream' -pid_file $VTDATAROOT/vt_0000000402/vttablet.pid -vtctld_addr http://localhost:15000/ -db_host 10.0.0.182 -db_port 3306 -db_app_user vtuser -db_app_password pass -db_dba_user vtuser -db_dba_password pass -db_repl_user vtuser -db_repl_password pass -db_filtered_user vtuser -db_filtered_password pass -db_allprivs_user vtuser -db_allprivs_password pass -init_db_name_override clustercontrol -init_populate_metadata &Setelah siap, kita dapat memeriksa bagaimana Vitess melihat VTTablet baru:
[email protected]:~/my-vitess-example$ mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 5.7.9-vitess-10.0.2 Version: 10.0.2 (Git revision fc78470 branch 'HEAD') built on Thu May 27 08:45:22 UTC 2021 by [email protected] using go1.15.12 linux/amd64
Copyright (c) 2000, 2021, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> SHOW vitess_tablets;
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| Cell | Keyspace | Shard | TabletType | State | Alias | Hostname | MasterTermStartTime |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| zone1 | clustercontrol | 0 | REPLICA | SERVING | zone1-0000000401 | vagrant.vm | |
| zone1 | clustercontrol | 0 | REPLICA | SERVING | zone1-0000000402 | vagrant.vm | |
| zone1 | commerce | 0 | MASTER | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |
| zone1 | commerce | 0 | REPLICA | SERVING | zone1-0000000101 | vagrant.vm | |
| zone1 | commerce | 0 | RDONLY | SERVING | zone1-0000000102 | vagrant.vm | |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
5 rows in set (0.00 sec)Node ada tetapi keduanya dilaporkan sebagai replika oleh Vitess. Kami sekarang dapat memicu Vitess untuk memeriksa topologi master asli kami (node yang kami impor dengan ID 401)
[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401Sekarang semua terlihat benar:
mysql> SHOW vitess_tablets;
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| Cell | Keyspace | Shard | TabletType | State | Alias | Hostname | MasterTermStartTime |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| zone1 | clustercontrol | 0 | MASTER | SERVING | zone1-0000000401 | vagrant.vm | 2021-07-08T13:27:34Z |
| zone1 | clustercontrol | 0 | REPLICA | SERVING | zone1-0000000402 | vagrant.vm | |
| zone1 | commerce | 0 | MASTER | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |
| zone1 | commerce | 0 | REPLICA | SERVING | zone1-0000000101 | vagrant.vm | |
| zone1 | commerce | 0 | RDONLY | SERVING | zone1-0000000102 | vagrant.vm | |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
5 rows in set (0.00 sec)Mengintegrasikan failover otomatis ClusterControl ke dalam Vitess
Hal terakhir yang ingin kita lihat adalah penanganan failover otomatis dengan ClusterControl dan lihat bagaimana Anda dapat mengintegrasikannya dengan Vitess. Ini akan sangat mirip dengan apa yang baru saja kita lihat. Masalah utama yang harus dihadapi adalah bahwa failover tidak mengubah apa pun di Vitess. Solusinya adalah apa yang telah kami gunakan sebelumnya, perintah TabletExternallyReparented. Satu-satunya tantangan adalah memicunya ketika failover terjadi. Untungnya, ClusterControl dilengkapi dengan kait yang memungkinkan kita untuk menyambungkan ke proses failover. Kami akan menggunakannya untuk menjalankan vtctlclient. Itu harus diinstal pada instance ClusterControl terlebih dahulu. Cara termudah untuk melakukannya adalah dengan menyalin biner dari instance Vitess ke ClusterControl.
Pertama, mari buat direktori pada node ClusterControl:
mkdir -r /usr/local/vitess/binKemudian, salin saja filenya:
scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/Sebagai langkah selanjutnya, kita harus membuat skrip yang akan menjalankan perintah untuk mereparent shard. Kami akan menggunakan script Replication_post_failover_script dan Replication_post_switchover_script. Cmon akan mengeksekusi skrip dengan beberapa argumen. Kami tertarik pada yang ketiga, itu akan berisi nama host calon master - simpul yang telah dipilih sebagai master baru.
Contoh skrip mungkin terlihat seperti ini.
#!/bin/bash
if [[ $3 == 10.0.0.181 ]] ; then tablet="zone1-401" ; fi
if [[ $3 == 10.0.0.182 ]] ; then tablet="zone1-402" ; fi
vitess="10.0.0.50"
/usr/local/vitess/bin/vtctlclient -server ${vitess}:15999 TabletExternallyReparented ${tablet}Harap diingat bahwa ini hanya minimal yang berfungsi. Anda harus menerapkan skrip yang lebih rinci yang mungkin akan melakukan pemeriksaan kewarasan tambahan. Alih-alih melakukan hardcoding nama host dan nama tablet, Anda sebenarnya dapat meminta ClusterControl untuk mendapatkan daftar node dalam cluster, kemudian Anda mungkin ingin membandingkannya dengan konten Layanan Topologi untuk melihat alias tablet mana yang harus digunakan.
Setelah kita siap dengan skrip, kita harus mengonfigurasinya untuk dieksekusi oleh ClusterControl:
Kita dapat menguji ini dengan mempromosikan replika secara manual. Keadaan awal, seperti yang dilihat oleh Vitess, adalah:
mysql> SHOW vitess_tablets;
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| Cell | Keyspace | Shard | TabletType | State | Alias | Hostname | MasterTermStartTime |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| zone1 | clustercontrol | 0 | MASTER | SERVING | zone1-0000000401 | vagrant.vm | 2021-07-08T13:27:34Z |
| zone1 | clustercontrol | 0 | REPLICA | SERVING | zone1-0000000402 | vagrant.vm | |
| zone1 | commerce | 0 | MASTER | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |
| zone1 | commerce | 0 | REPLICA | SERVING | zone1-0000000101 | vagrant.vm | |
| zone1 | commerce | 0 | RDONLY | SERVING | zone1-0000000102 | vagrant.vm | |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
5 rows in set (0.00 sec)Kami tertarik pada keyspace 'clustercontrol'. 401 (10.0.0.181) adalah master dan 402 (10.0.0.182) adalah replikanya.
Kami dapat mempromosikan 10.0.0.182 untuk menjadi master baru. Pekerjaan dimulai dan kita dapat melihat bahwa skrip kita telah dieksekusi:
Akhirnya, pekerjaan selesai:
Semua berjalan dengan baik di ClusterControl. Mari kita lihat Vitess:
mysql> SHOW vitess_tablets;
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| Cell | Keyspace | Shard | TabletType | State | Alias | Hostname | MasterTermStartTime |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| zone1 | clustercontrol | 0 | MASTER | SERVING | zone1-0000000402 | vagrant.vm | 2021-07-09T13:38:00Z |
| zone1 | clustercontrol | 0 | REPLICA | SERVING | zone1-0000000401 | vagrant.vm | |
| zone1 | commerce | 0 | MASTER | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |
| zone1 | commerce | 0 | REPLICA | SERVING | zone1-0000000101 | vagrant.vm | |
| zone1 | commerce | 0 | RDONLY | SERVING | zone1-0000000102 | vagrant.vm | |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
5 rows in set (0.00 sec)Seperti yang Anda lihat, semuanya baik-baik saja di sini. 402 adalah master baru dan 401 ditandai sebagai replika.
Tentu saja, ini hanyalah contoh bagaimana Anda bisa mendapatkan keuntungan dari kemampuan ClusterControl untuk memantau dan mengelola database MySQL Anda sambil tetap dapat memanfaatkan kemampuan Vitess untuk memperbesar dan membagi data. Vitess adalah alat yang hebat tetapi tidak memiliki beberapa elemen. Untungnya, ClusterControl dapat mendukung Anda dalam kasus tersebut.
