“Perbaiki database Anda ke versi terbaru - ini demi keselamatan Anda” adalah sesuatu yang mungkin sering Anda dengar sebagai saran dan praktik terbaik dalam hal pengelolaan database. Di sisi lain, memutakhirkan database Anda bisa menjadi tugas yang memakan waktu. Bahkan pemutakhiran versi kecil mengharuskan Anda menguji pemutakhiran secara menyeluruh di lingkungan pementasan sebelum memutakhirkan penyiapan produksi Anda. Jadi apa masalahnya? Jika Anda hanya tertinggal di belakang satu versi minor, itu tidak masalah, bukan? Yah, mungkin tidak... sampai itu terjadi. Dan apakah Anda benar-benar siap untuk mengambil risiko seperti itu?
Awal tahun ini, kerentanan baru yang berpotensi berbahaya telah diidentifikasi di Galera Cluster (CVE-2021-27928). Sepintas, kami melihat bahwa tingkat keparahannya ditandai sebagai tinggi, dan ketika kami mulai menggali masalah lebih jauh, itu memang terlihat parah. Tampaknya pengguna SUPER dapat mengeksekusi kode arbitrer apa pun dengan mengubah variabel wsrep_provider dan wsrep_notify_cmd saat runtime. Ini memungkinkan pengguna untuk memuat perpustakaan .so dan mengarahkan ke skrip yang akan dijalankan oleh server. Seperti yang dapat Anda bayangkan, ini bukan situasi yang baik. Tentu, Anda perlu memiliki akses ke pengguna SUPER, dan Anda harus memiliki sesuatu yang tersedia untuk dieksekusi pada node database, tetapi fakta bahwa Galera dapat dikonfigurasi untuk mengeksekusi kode arbitrer sebagai pengguna 'mysql' cukup buruk pada sendiri.
Seperti biasa, dalam kasus seperti ini, perbaikan telah dibuat, dan versi baru perangkat lunak, yang tidak terpengaruh oleh kerentanan, telah didorong. Masalah khusus ini telah diperbaiki di MariaDB 10.5.9, 10.4.18, 10.3.28, dan 10.2.37, serta Percona XtraDB Cluster 5.6.51-28.46, Percona XtraDB Cluster 5.7.33-31.49, dan Percona XtraDB Cluster 8.0.22-13.1. Semua sepertinya kembali normal. Benar?
Salah. Ada banyak sistem yang berjalan pada produksi yang belum ditingkatkan ke versi baru yang tidak terpengaruh. Tim dukungan Somenines berhubungan dengan banyak lingkungan database di alam liar, dan kami terus bekerja dengan prospek untuk membantu mereka bermigrasi ke lingkungan yang dikelola oleh ClusterControl. Kami melihat semua jenis MySQL (dan tidak hanya MySQL) berjalan dalam versi yang sudah ketinggalan zaman, terkadang bahkan versi yang telah mencapai End Of Life dan tidak lagi mendapatkan pembaruan keamanan. Seharusnya tidak demikian, terutama jika Anda adalah pengguna ClusterControl.
ClusterControl hadir dengan serangkaian fitur yang akan membantu Anda untuk tetap mengikuti semua perbaikan keamanan. Mari kita lihat:
Pertama-tama, ClusterControl hadir dengan Laporan Operasional, salah satunya adalah Laporan Peningkatan Paket:
Seperti semua laporan operasional ClusterControl, Laporan Peningkatan Paket dapat dijadwalkan ke dijalankan secara teratur dan kemudian dikirimkan melalui email. Ini akan berisi informasi tentang versi paket yang diinstal pada node dan jika ada jenis peningkatan yang harus dilakukan:
Laporan Peningkatan Paket menyajikan daftar paket yang harus diperbarui untuk semua database, loadbalancer, perbaikan keamanan, dan paket lain yang diinstal pada node. Untuk semua paket sistem, solusinya adalah memutakhirkannya menggunakan metode standar (apt, yum). Dalam hal database dan loadbalancer, ClusterControl hadir dengan fungsionalitas yang memungkinkan Anda melakukan upgrade versi minor langsung dari UI.
Sebelum kita menuju ke sana, mari kita asumsikan bahwa database harus diperbarui. Anda tidak ingin hanya melanjutkan dan menjalankan pemutakhiran secara membabi buta - ini dapat berpotensi menyebabkan masalah pada aplikasi Anda. Seharusnya tidak - versi minor tidak merusak kompatibilitas ke belakang (kecuali saat Anda menggunakan MySQL 8.0 - maka ya, Anda mungkin mengharapkan apa pun saat beralih dari 8.0.x ke 8.0.x+1); namun, selalu ada beberapa risiko yang terlibat. Hal pertama yang harus Anda lakukan adalah menguji pemutakhiran di lingkungan yang terpisah.
Kami memiliki klaster MariaDB Galera sederhana dengan ProxySQL dan Keepalive:
Kami ingin membangun kluster uji sehingga kami dapat menguji pemutakhiran proses. Dengan ClusterControl, semudah menggunakan pekerjaan Buat Replika Cluster:
Kita bisa mendapatkan data baru dari cluster yang ada, atau kita bisa menggunakan data dari cadangan.
Kita juga harus memilih node sumber di cluster produksi:
Kemudian kita harus melalui wizard penerapan reguler, memilih versi dan vendor database, mendefinisikan password root, dan sebagainya. Kami menyimpulkan dengan melewati node di mana cluster akan diinstal.
Sebagai hasilnya, Anda akan melihat cluster baru di daftar dengan tanda yang jelas bahwa itu mereplikasi dari cluster produksi. Satu hal yang perlu disebutkan, dalam pengaturan default, ClusterControl akan menggunakan versi terbaru dari paket untuk membuat cluster replika. Jika Anda ingin memeriksa ulang hanya kueri, ini sudah cukup. Jika Anda ingin menjalani seluruh proses peningkatan, Anda perlu menentukan versi lama dari paket MySQL untuk menginstal versi lama (lalu melepas pinnya dan menguji peningkatan).
Dengan satu atau lain cara, setelah pengujian berhasil, Anda akhirnya ingin melakukan peningkatan. ClusterControl dapat membantu Anda mencapai ini:
Di Kelola -> Peningkatan, Anda akan menemukan UI untuk melakukan peningkatan .
Anda dapat menggunakan “Periksa Paket Baru” untuk menyegarkan basis data yang tersedia paket. Kami juga dapat memilih node mana yang ingin diupgrade dan layanan mana:
Cukup konfirmasi dan hanya itu - ClusterControl akan melakukan peningkatan dan memberi Anda versi terbaru dari paket.
Seperti yang Anda lihat, ClusterControl membuat database Anda selalu terbarui dengan mudah dan mudah. Satu-satunya langkah yang harus Anda tangani secara manual adalah pengujian yang tepat. Jika tidak - segala sesuatu yang lain dapat dilakukan untuk Anda oleh ClusterControl. Tertarik untuk mempelajari lebih lanjut tentang bagaimana ClusterControl dapat membantu Anda mengelola database secara efektif? Cobalah gratis selama 30 hari.
