Uji rilis biasanya merupakan salah satu langkah dalam keseluruhan proses penerapan. Anda menulis kode, dan kemudian Anda memverifikasi bagaimana perilakunya di lingkungan pementasan, dan kemudian, akhirnya, Anda menyebarkan kode baru pada produksi. Basis data bersifat internal untuk semua jenis aplikasi, dan oleh karena itu, penting untuk memverifikasi bagaimana perubahan terkait basis data mengubah aplikasi. Dimungkinkan untuk memverifikasinya dalam beberapa cara; salah satunya adalah menggunakan replika khusus. Mari kita lihat bagaimana hal itu dapat dilakukan.
Jelas, Anda tidak ingin proses ini menjadi manual - ini harus menjadi bagian dari proses CI/CD perusahaan Anda. Bergantung pada aplikasi, lingkungan, dan proses yang Anda miliki, Anda bisa menggunakan replika yang dibuat secara ad-hoc atau replika yang selalu menjadi bagian dari lingkungan database.
Cara kerja Galera Cluster adalah menangani perubahan skema dengan cara tertentu. Dimungkinkan untuk mengeksekusi perubahan skema pada satu node di cluster tetapi itu rumit, karena tidak mendukung semua kemungkinan perubahan skema, dan itu akan memengaruhi produksi jika terjadi kesalahan. Node tersebut harus sepenuhnya dibangun kembali menggunakan SST, yang berarti bahwa salah satu node Galera yang tersisa harus bertindak sebagai donor dan mentransfer semua datanya melalui jaringan.
Alternatifnya adalah menggunakan replika atau bahkan Cluster Galera tambahan yang berfungsi sebagai replika. Jelas, prosesnya harus diotomatisasi untuk menghubungkannya ke jalur pengembangan. Ada banyak cara untuk melakukan ini:skrip atau berbagai alat orkestrasi infrastruktur seperti Ansible, Chef, Puppet, atau Salt stack. Kami tidak akan menjelaskannya secara mendetail, tetapi kami ingin Anda menunjukkan langkah-langkah yang diperlukan agar seluruh proses berfungsi dengan baik, dan kami akan menyerahkan penerapan di salah satu alat kepada Anda.
Mengotomatiskan Tes Rilis
Pertama-tama, kami ingin dapat menerapkan database baru dengan mudah. Itu harus dilengkapi dengan data terbaru, dan ini dapat dilakukan dengan banyak cara - Anda dapat menyalin data dari database produksi ke server pengujian; itu hal yang paling sederhana untuk dilakukan. Atau, Anda dapat menggunakan cadangan terbaru - pendekatan semacam itu memiliki manfaat tambahan untuk menguji pemulihan cadangan. Verifikasi pencadangan adalah hal yang harus dimiliki dalam segala jenis penerapan serius, dan membangun kembali penyiapan pengujian adalah cara yang bagus untuk memeriksa ulang pekerjaan proses pemulihan Anda. Ini juga membantu Anda mengatur waktu proses pemulihan - mengetahui berapa lama waktu yang diperlukan untuk memulihkan cadangan Anda membantu menilai situasi dengan benar dalam skenario pemulihan bencana.
Setelah data disediakan dalam database, Anda mungkin ingin menyiapkan node tersebut sebagai replika dari cluster utama Anda. Ini memiliki pro dan kontra. Jika Anda dapat menjalankan kembali semua lalu lintas Anda ke node mandiri, itu akan sempurna - dalam kasus seperti itu, tidak perlu menyiapkan replikasi. Beberapa penyeimbang beban, seperti ProxySQL, memungkinkan Anda untuk mencerminkan lalu lintas dan mengirim salinannya ke lokasi lain. Di sisi lain, replikasi adalah hal terbaik berikutnya. Ya, Anda tidak dapat mengeksekusi penulisan secara langsung pada node tersebut yang memaksa Anda untuk merencanakan bagaimana Anda akan mengeksekusi ulang kueri karena pendekatan paling sederhana dengan hanya membalasnya tidak akan berhasil. Di sisi lain, semua penulisan pada akhirnya akan dieksekusi melalui utas SQL, jadi Anda hanya perlu merencanakan cara menangani kueri SELECT.
Tergantung pada perubahan yang tepat, Anda mungkin ingin menguji proses perubahan skema. Perubahan skema cukup umum untuk dilakukan, dan mungkin memiliki dampak kinerja yang serius pada database. Oleh karena itu, penting untuk memverifikasinya sebelum menerapkannya pada produksi. Kami ingin melihat waktu yang diperlukan untuk menjalankan perubahan dan memverifikasi apakah perubahan dapat diterapkan pada node secara terpisah atau diperlukan untuk melakukan perubahan pada seluruh topologi pada saat yang bersamaan. Ini akan memberi tahu kita proses apa yang harus kita gunakan untuk perubahan skema tertentu.
Menggunakan ClusterControl untuk Meningkatkan Otomatisasi Tes Rilis
ClusterControl hadir dengan serangkaian fitur yang dapat digunakan untuk membantu Anda mengotomatiskan pengujian rilis. Mari kita lihat apa yang ditawarkannya. Untuk memperjelas, fitur yang akan kami tunjukkan tersedia dalam beberapa cara. Cara paling sederhana adalah dengan menggunakan UI, tetapi tidak perlu melakukan apa yang ingin Anda lakukan jika Anda memiliki otomatisasi di pikiran Anda. Ada dua cara lagi untuk melakukannya:Antarmuka Baris Perintah ke ClusterControl dan RPC API. Dalam kedua kasus, pekerjaan dapat dipicu dari skrip eksternal, memungkinkan Anda untuk menghubungkannya ke proses CI/CD yang ada. Ini juga akan menghemat banyak waktu Anda, karena menerapkan cluster bisa jadi hanya soal menjalankan satu perintah daripada menyiapkannya secara manual.
Menerapkan cluster pengujian
Pertama dan terpenting, ClusterControl hadir dengan opsi untuk menyebarkan cluster baru dan menyediakannya dengan data dari database yang ada. Fitur ini sendiri memungkinkan Anda untuk dengan mudah menerapkan penyediaan server pementasan.
Seperti yang Anda lihat, selama Anda telah membuat cadangan, Anda dapat membuat cluster baru dan menyediakannya menggunakan data dari cadangan:
Seperti yang bisa kita lihat, ada ringkasan singkat tentang apa yang akan terjadi. Jika Anda mengklik Lanjutkan, Anda akan melanjutkan lebih jauh.
Sebagai langkah selanjutnya, Anda harus menentukan konektivitas SSH - konektivitas tersebut harus sudah ada sebelum ClusterControl dapat menerapkan node.
Terakhir, Anda harus memilih (antara lain) vendor, versi, dan nama host dari node yang ingin Anda gunakan di cluster. Itu saja.
Perintah CLI yang akan melakukan hal yang sama terlihat seperti ini:
s9s cluster --create --cluster-type=galera --nodes="10.0.0.156;10.0.0.157;10.0.0.158" --vendor=percona --cluster-name=PXC --provider-version=8.0 --os-user=root --os-key-file=/root/.ssh/id_rsa --backup-id=6Mengonfigurasi ProxySQL untuk mencerminkan lalu lintas
Jika kita memiliki cluster yang di-deploy, kita mungkin ingin mengirimkan lalu lintas produksi ke sana untuk memverifikasi bagaimana skema baru menangani lalu lintas yang ada. Salah satu cara untuk melakukannya adalah dengan menggunakan ProxySQL.
Prosesnya mudah. Pertama, Anda harus menambahkan node ke ProxySQL. Mereka harus menjadi bagian dari grup host terpisah yang belum digunakan. Pastikan bahwa pengguna monitor ProxySQL dapat mengaksesnya.
Setelah ini selesai dan Anda memiliki semua (atau beberapa) node Anda yang dikonfigurasi di hostgroup, Anda dapat mengedit aturan kueri dan menentukan Mirror Hostgroup (tersedia dalam opsi lanjutan). Jika Anda ingin melakukannya untuk semua lalu lintas, Anda mungkin ingin mengedit semua aturan kueri dengan cara ini. Jika Anda hanya ingin mencerminkan kueri SELECT, Anda harus mengedit aturan kueri yang sesuai. Setelah ini selesai, cluster staging Anda akan mulai menerima traffic produksi.
Menyebarkan cluster sebagai budak
Seperti yang telah kita bahas sebelumnya, solusi alternatif adalah membuat cluster baru yang akan bertindak sebagai replika dari pengaturan yang ada. Dengan pendekatan seperti itu, kita dapat menguji semua penulisan secara otomatis, menggunakan replikasi. SELECT dapat diuji menggunakan pendekatan yang kami jelaskan di atas - pencerminan melalui ProxySQL.
Penyebaran kluster budak cukup mudah.
Pilih tugas Create Slave Cluster.
Anda harus memutuskan bagaimana Anda ingin mengatur replikasi. Anda dapat memiliki semua data yang ditransfer dari master ke node baru.
Sebagai alternatif, Anda dapat menggunakan cadangan yang ada untuk menyediakan cluster baru. Ini akan membantu mengurangi beban kerja pada master node - alih-alih mentransfer semua data, hanya transaksi yang dijalankan antara waktu pencadangan dibuat dan saat replikasi telah disiapkan yang harus ditransfer.
Selebihnya adalah mengikuti wizard penerapan standar, menentukan konektivitas SSH, versi, vendor, host, dan sebagainya. Setelah di-deploy, Anda akan melihat cluster pada daftar.
Solusi alternatif untuk UI adalah melakukannya melalui RPC.
{
"command": "create_cluster",
"job_data": {
"cluster_name": "",
"cluster_type": "galera",
"company_id": null,
"config_template": "my.cnf.80-pxc",
"data_center": 0,
"datadir": "/var/lib/mysql",
"db_password": "pass",
"db_user": "root",
"disable_firewall": true,
"disable_selinux": true,
"enable_mysql_uninstall": true,
"generate_token": true,
"install_software": true,
"port": "3306",
"remote_cluster_id": 6,
"software_package": "",
"ssh_keyfile": "/root/.ssh/id_rsa",
"ssh_port": "22",
"ssh_user": "root",
"sudo_password": "",
"type": "mysql",
"user_id": 5,
"vendor": "percona",
"version": "8.0",
"nodes": [
{
"hostname": "10.0.0.155",
"hostname_data": "10.0.0.155",
"hostname_internal": "",
"port": "3306"
},
{
"hostname": "10.0.0.159",
"hostname_data": "10.0.0.159",
"hostname_internal": "",
"port": "3306"
},
{
"hostname": "10.0.0.160",
"hostname_data": "10.0.0.160",
"hostname_internal": "",
"port": "3306"
}
],
"with_tags": []
}
}Melangkah Maju
Jika Anda tertarik untuk mempelajari lebih lanjut tentang cara Anda dapat mengintegrasikan proses Anda dengan ClusterControl, kami ingin mengarahkan Anda ke dokumentasi, di mana kami memiliki seluruh bagian tentang pengembangan solusi di mana ClusterControl memainkan peran peran penting:
https://docs.severalnines.com/docs/clustercontrol/developer-guide/cmon-rpc/
https://docs.severalnines.com/docs/clustercontrol/user-guide-cli/
Kami harap Anda menemukan blog singkat ini informatif dan bermanfaat. Jika Anda memiliki pertanyaan terkait mengintegrasikan ClusterControl ke dalam lingkungan Anda, hubungi kami, dan kami akan melakukan yang terbaik untuk membantu Anda.
