MariaDB
 sql >> Teknologi Basis Data >  >> RDS >> MariaDB

Pengujian Otomatis dari Proses Peningkatan untuk PXC/MariaDB Galera Cluster

Memperbarui database Anda untuk kluster berbasis Galera seperti Percona XtraDB Cluster (PXC) atau MariaDB Galera Cluster dapat menjadi tantangan, terutama untuk lingkungan berbasis produksi. Anda tidak dapat kehilangan status ketersediaan tinggi Anda dan menempatkannya dalam risiko.

Prosedur pemutakhiran harus didokumentasikan dengan baik, dan idealnya, dokumentasi, pengujian ketat, dan pembandingan harus dilakukan sebelum pemutakhiran. Yang terpenting, keamanan dan peningkatan juga harus diidentifikasi berdasarkan changelog dari peningkatan versi databasenya.

Dengan segala kekhawatirannya, otomatisasi membantu mencapai proses peningkatan yang lebih efisien, dan membantu menghindari kesalahan manusia serta meningkatkan RTO.

Cara Mengelola Proses Peningkatan Klaster Galera PXC/MariaDB 

Memutakhirkan PXC/MariaDB Galera Cluster Anda memerlukan dokumentasi yang tepat dan alur proses yang mencantumkan hal-hal yang harus dilakukan dan hal-hal yang harus dilakukan jika terjadi masalah. Itu berarti Rencana Kesinambungan Bisnis yang juga mencakup Rencana Pemulihan Bencana Anda harus disusun. Anda tidak dapat kehilangan bisnis Anda jika terjadi masalah.

Pengambilan yang biasa dilakukan adalah memulai terlebih dahulu dengan lingkungan pengujian. Lingkungan pengujian harus memiliki pengaturan dan konfigurasi yang sama persis dengan lingkungan produksi Anda. Anda tidak dapat melanjutkan secara langsung dengan memutakhirkan lingkungan produksi karena Anda tidak yakin apa efek dan dampak yang akan terjadi jika hal-hal tidak sesuai dengan rencana.

Bekerja dengan lingkungan produksi sangat sensitif, jadi dalam banyak kasus, periode waktu henti dan pemeliharaan selalu ada untuk menghindari dampak drastis.

Ada dua jenis upgrade untuk PCX atau MariaDB Galera Cluster yang perlu Anda ketahui. Ini adalah peningkatan rilis utama dan peningkatan rilis kecil atau sering disebut sebagai peningkatan di tempat. Pemutakhiran di tempat adalah tempat Anda dapat memutakhirkan versi basis data ke versi minor terbarunya menggunakan data biner yang sama dari basis data Anda. Tidak akan ada perubahan fisik pada data itu sendiri, tetapi hanya pada biner basis datanya atau paket perangkat lunak yang mendasarinya.

Mengupgrade PCX atau MariaDB Galera Cluster ke Rilis Utama

Meningkatkan versi ke rilis utama dapat menjadi tantangan, terutama untuk lingkungan produksi. Ini melibatkan jenis konfigurasi database yang kompleks dan fitur bawaan khusus dari PXC atau MariaDB Galera Cluster. Spaiotemporal, data yang dicap waktu, data mesin, atau data multifaset lainnya sangat konservatif dan sensitif terhadap peningkatan. Anda tidak dapat menerapkan pemutakhiran di tempat untuk proses ini karena banyak perubahan besar yang akan dibuat. Kecuali Anda memiliki data yang sangat kecil atau data yang terdiri dari idempoten atau data yang dapat dihasilkan dengan mudah dapat dilakukan dengan aman selama Anda tahu dampaknya tidak akan memengaruhi data Anda.

Jika volume data Anda besar, sebaiknya proses upgrade diotomatiskan. Namun, Ini mungkin bukan solusi ideal untuk mengotomatiskan semua urutan dalam proses peningkatan karena mungkin ada masalah tak terduga yang merayap selama fase peningkatan utama. Yang terbaik adalah mengotomatiskan langkah dan proses berulang dengan hasil yang diketahui dalam peningkatan besar. Pada titik mana pun, sumber daya diperlukan untuk mengevaluasi apakah proses otomatisasi aman untuk menghindari penghentian dalam proses peningkatan. Pengujian otomatis setelah pemutakhiran sama pentingnya, dan harus disertakan sebagai bagian dari proses pasca pemutakhiran.

Upgrade PCX atau MariaDB Galera Cluster ke Rilis Kecil

Upgrade rilis minor yang disebut sebagai upgrade di tempat biasanya merupakan pendekatan yang lebih aman untuk melakukan proses upgrade. Ini karena, perubahan paling umum untuk rilis ini adalah keamanan dan eksploitasi patch atau perbaikan, bug (biasanya yang parah), atau masalah kompatibilitas yang memerlukan patch terutama jika perangkat keras atau OS saat ini memiliki perubahan yang diterapkan yang juga dapat menyebabkan database tidak berfungsi. berfungsi dengan baik. Meskipun dampak biasanya dapat dipulihkan dengan efek minimal, Anda tetap harus melihat dan membaca log perubahan yang didorong ke pemutakhiran versi minor tertentu.

Menerapkan pekerjaan untuk melakukan proses peningkatan versi adalah contoh ideal untuk otomatisasi. Alur yang biasa sangat berulang dan sebagian besar tidak membahayakan PXC atau MariaDB Galera Cluster Anda yang sudah ada. Yang paling penting adalah bahwa setelah pemutakhiran, pengujian otomatis akan dilanjutkan untuk menentukan penyiapan, konfigurasi, efisiensi, dan fungsionalitas tidak rusak.

Hindari Kegagalan! Bersiaplah, Otomatiskan!

Seorang klien kami menghubungi kami untuk meminta bantuan karena, setelah peningkatan minor basis data, fitur yang mereka gunakan dalam basis data tidak berfungsi dengan baik. Mereka menanyakan langkah-langkah dan proses tentang cara menurunkan versi dan seberapa amannya. Pelanggan mereka mengeluh bahwa aplikasi mereka sama sekali tidak berfungsi, menggeneralisasi bahwa itu tidak berguna.

Bahkan untuk kesalahan kecil seperti itu, pelanggan yang kesal mungkin akan memberikan komentar buruk pada produk Anda. Pelajaran yang dipetik dari skenario ini adalah bahwa kegagalan dalam pengujian setelah pemutakhiran menyebabkan asumsi bahwa semua fungsi dalam database berfungsi seperti yang diharapkan.

Misalkan Anda memiliki rencana untuk mengotomatisasi proses peningkatan versi, lalu perhatikan bahwa jenis proses otomatisasi berbeda-beda untuk jenis peningkatan yang harus Anda lakukan. Seperti disebutkan sebelumnya, peningkatan besar versus peningkatan kecil memiliki pendekatan berbeda yang berbeda. Jadi, pengaturan otomat Anda mungkin tidak berlaku untuk kedua pemutakhiran perangkat lunak basis data.

Otomatis Setelah Proses Upgrade

Pada titik ini, proses upgrade Anda diharapkan selesai, idealnya, melalui otomatisasi. Setelah database Anda siap menerima koneksi klien, database harus mengikuti fase pengujian yang ketat.

Jalankan mysql_upgrade

Sangat penting dan sangat disarankan untuk mengeksekusi mysql_upgrade setelah proses upgrade selesai. mysql_upgrade mencari ketidaksesuaian dengan server MySQL yang ditingkatkan dengan melakukan hal-hal berikut:

  • Ini memutakhirkan tabel sistem dalam skema mysql sehingga Anda dapat memanfaatkan hak istimewa atau kemampuan baru yang mungkin telah ditambahkan.

  • Ini meningkatkan Skema Kinerja dan skema sistem.

  • Ini memeriksa skema pengguna.

Mysql_upgrade menentukan apakah tabel memiliki masalah seperti ketidakcocokan karena perubahan dalam versi terbaru setelah peningkatan dan mencoba menyelesaikannya dengan memperbaiki tabel. Jika tidak, jika gagal, maka pengujian otomatisasi Anda harus gagal dan tidak boleh melanjutkan ke hal lain. Itu harus diselidiki terlebih dahulu dan dilakukan perbaikan manual.

Periksa log kesalahan

Setelah mysql_upgrade selesai, Anda perlu memeriksa dan memverifikasi kesalahan yang terjadi. Anda dapat memasukkan ini ke dalam skrip dan memeriksa label "kesalahan" atau "peringatan" di log kesalahan. Sangat penting untuk menentukan apakah ada seperti itu. Pengujian otomatis Anda harus memiliki kemampuan untuk menangkap jebakan kesalahan baik itu dapat menunggu masukan pengguna untuk melanjutkan jika kesalahannya sangat kecil atau diharapkan, jika tidak, hentikan proses peningkatan versi.

Lakukan pengujian unit

Lingkungan basis data TDD (Test Driven Development) adalah pendekatan pengembangan perangkat lunak di mana ada serangkaian kasus uji untuk divalidasi dan menentukan apakah validasi benar (lulus) atau salah (gagal). Sesuatu seperti yang kita miliki di tangkapan layar di bawah ini:

Gambar milik guru99.com

Ini adalah jenis pengujian unit yang membantu menghindari bug yang tidak diinginkan atau kesalahan logika pada aplikasi dan database Anda. Ingat, jika ada data yang tidak valid yang disimpan dalam database, itu akan membahayakan semua analitik dan transaksi bisnis, terutama jika itu melibatkan perhitungan keuangan atau persamaan matematika yang rumit.

Jika Anda bertanya, apakah benar-benar perlu melakukan pengujian unit setelah pemutakhiran? Tentu saja! Anda tidak perlu menjalankan ini di bawah lingkungan produksi. Selama fase pengujian, yaitu memutakhirkan terlebih dahulu QA Anda, lingkungan pengembangan/pementasan, itu harus diterapkan di area itu. Data harus berupa salinan persis setidaknya atau hampir sama dengan lingkungan produksinya. Tujuan Anda di sini adalah untuk menghindari hasil yang tidak diinginkan dan hasil logis yang pasti salah. Tentu saja Anda harus menjaga data Anda dengan baik dan menentukan apakah hasilnya lulus uji validasi.

Jika Anda ingin menjalankan produksi Anda, lakukanlah. Namun, jangan kaku seperti fase pengujian yang diterapkan di lingkungan QA, pengembangan, atau pementasan. Itu karena Anda harus merencanakan waktu Anda berdasarkan jendela pemeliharaan yang tersedia dan menghindari penundaan dan RTO yang lebih lama.

Menurut pengalaman saya, selama fase peningkatan, pelanggan memilih pendekatan yang lebih cepat yang penting untuk menentukan apakah fitur tersebut memberikan hasil yang benar. Selain itu, Anda dapat memiliki skrip untuk mengotomatiskan pengujian serangkaian fungsi logika bisnis atau prosedur tersimpan karena skrip membantu untuk menyimpan kueri dan membuat database Anda hangat.

Saat mempersiapkan Pengujian Unit untuk database Anda, hindari menciptakan kembali roda. Sebagai gantinya, lihat alat yang tersedia yang dapat Anda pilih apakah itu bagus untuk kebutuhan dan kebutuhan Anda. Lihat Selenium, atau kunjungi blog ini.

Verifikasi identitas kueri

Alat paling umum yang dapat Anda gunakan adalah pt-upgrade. Ini memverifikasi bahwa hasil kueri identik pada server yang berbeda. Itu mengeksekusi kueri berdasarkan log yang diberikan dan koneksi yang disediakan (atau disebut sebagai DSN), kemudian membandingkan hasilnya dan melaporkan perbedaan yang signifikan. Ini menawarkan lebih dari itu sebagai opsi Anda untuk mengumpulkan atau menganalisis kueri seperti melalui tcpdump, misalnya.

Menggunakan pt-upgrade itu mudah. Misalnya, Anda dapat menjalankan dengan perintah berikut:

## Comparing via slow log for the given hosts
pt-upgrade h=host1 h=host2 slow.log

## or use fingerprints, useful for debugging purposes
pt-upgrade --fingerprints --run-time=1h mysqld-slow.log h=127.0.0.1,P=5091 h=127.0.0.1,P=5517

## or with tcpdump,
tcpdump -i eth0 port 3306 -s 65535  -x -n -q -tttt     \
  | pt-query-digest --type tcpdump --no-report --print \
  | pt-upgrade h=host1 h=host2

Ini adalah praktik yang baik bahwa setelah pemutakhiran, terutama pemutakhiran rilis utama telah dilakukan, pt-upgrade digunakan untuk melanjutkan dan melakukan analisis kueri yang mengidentifikasi perbedaan berdasarkan hasil. Ini adalah praktik yang baik untuk melakukan ini selama fase pengujian saat melakukannya di QA Anda atau lingkungan staging dan pengembangan sehingga Anda dapat memutuskan apakah lebih aman untuk melanjutkan. Anda dapat menambahkan ini ke alat otomatisasi dan menjalankannya sebagai pedoman setelah siap menjalankan tugasnya.

Bagaimana Mengotomatiskan Proses Pengujian?

Di blog kami sebelumnya, kami telah menyajikan berbagai cara untuk mengotomatisasi database Anda. Alat paling umum yang sedang populer adalah alat perangkat lunak penyebaran IaC (Infrastructure as Code) ini. Anda dapat menggunakan Puppet, Chef, SaltStack, atau Ansible untuk melakukan pekerjaan tersebut.

Preferensi saya selalu memungkinkan untuk melakukan pengujian otomatis saya, memungkinkan saya untuk membuat buku pedoman dengan peran tugasnya. Tentu saja, saya tidak dapat membuat satu otomat utuh yang akan melakukan semua hal karena situasi dan lingkungan berbeda-beda. Berdasarkan jenis upgrade yang diberikan sebelumnya (upgrade mayor vs minor), Anda harus membedakan prosesnya. Meskipun itu hanya peningkatan di tempat, Anda tetap harus memastikan bahwa buku pedoman Anda akan melakukan pekerjaan yang benar.

ClusterControl adalah Teman Otomasi Basis Data Anda!

ClusterControl adalah opsi yang baik untuk melakukan pengujian dasar dan otomatis. ClusterControl bukan kerangka kerja untuk pengujian; itu bukan alat untuk menyediakan pengujian unit. Namun, ini adalah alat manajemen dan pemantauan basis data yang menggabungkan banyak penerapan otomatis berdasarkan pemicu yang diminta dari pengguna atau administrator perangkat lunak.

ClusterControl menawarkan pemutakhiran versi kecil, yang memberikan kemudahan bagi DBA saat melakukan pemutakhiran. Itu melakukan mysql_upgrade dengan cepat juga. Jadi Anda tidak perlu melakukannya secara manual. ClusterControl juga mendeteksi versi baru untuk ditingkatkan dan merekomendasikan langkah selanjutnya untuk Anda lakukan. Jika terjadi kegagalan, pemutakhiran tidak akan dilanjutkan.

Berikut ini contoh tugas peningkatan kecil:

Jika diperhatikan dengan seksama, mysql_upgrade berjalan dengan sukses. Meskipun tidak merekomendasikan dan melakukan peningkatan otomatis master, itu karena itu bukan pendekatan yang tepat untuk melanjutkan. Dalam hal ini, Anda harus mempromosikan budak baru, lalu menurunkan master sebagai budak untuk melakukan peningkatan.

Kesimpulan

Hal yang hebat dengan ClusterControl adalah Anda dapat menggabungkan pemeriksaan log kesalahan, melakukan pengujian unit, memverifikasi identitas kueri dengan membuat Penasihat. Tidak sulit untuk melakukannya. Anda dapat merujuk ke blog kami sebelumnya Menggunakan ClusterControl Advisor untuk Membuat Cek untuk SELinux dan Meltdown/Spectre:Bagian Satu. Ini mencontohkan bagaimana Anda dapat mengambil keuntungan dan memicu pekerjaan berikutnya yang harus dilakukan setelah pemutakhiran dijalankan. ClusterControl memiliki peringatan atau alarm bawaan yang dapat diintegrasikan ke sistem peringatan pihak ketiga favorit Anda untuk memberi tahu Anda tentang status pengujian otomatis Anda saat ini.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Bagaimana FROM_BASE64() Bekerja di MariaDB

  2. Cara Menyebarkan MariaDB Cluster 10.5 untuk Ketersediaan Tinggi

  3. Bagaimana COALESCE() Bekerja di MariaDB

  4. Bagaimana COLLATION() Bekerja di MariaDB

  5. Perbaiki "ERROR 1054 (42S22):Kolom tidak dikenal 'colname' di 'order clause' di MariaDB