Mayoritas DBA melakukan pemeriksaan kesehatan di database mereka sesekali. Biasanya, itu akan terjadi setiap hari atau setiap minggu. Kami sebelumnya telah membahas mengapa pemeriksaan tersebut penting dan apa yang harus disertakan.
Untuk memastikan sistem Anda dalam kondisi yang baik, Anda harus melalui cukup banyak informasi - statistik host, statistik MySQL, statistik beban kerja, status pencadangan, paket basis data, log, dan sebagainya. Data tersebut harus tersedia di setiap lingkungan yang dipantau dengan benar, meskipun terkadang tersebar di beberapa lokasi - Anda mungkin memiliki satu alat untuk memantau status MySQL, alat lain untuk mengumpulkan statistik sistem, mungkin satu set skrip, mis., untuk memeriksa status cadangan Anda. Hal ini membuat pemeriksaan kesehatan jauh lebih memakan waktu daripada yang seharusnya - DBA harus mengumpulkan bagian-bagian yang berbeda untuk memahami keadaan sistem.
Alat terintegrasi seperti ClusterControl memiliki keuntungan bahwa semua bit berada di tempat yang sama (atau dalam aplikasi yang sama). Ini tetap tidak berarti mereka terletak bersebelahan - mereka mungkin terletak di bagian UI yang berbeda dan DBA mungkin harus meluangkan waktu untuk mengklik UI untuk menjangkau semua data yang menarik.
Seluruh ide di balik pembuatan Laporan Operasional adalah untuk memasukkan semua data yang paling penting ke dalam satu dokumen, yang dapat dengan cepat ditinjau untuk mendapatkan pemahaman tentang keadaan database.
Laporan Operasional tersedia dari menu Menu Samping -> Laporan Operasional:
Setelah Anda pergi ke sana, Anda akan disajikan dengan daftar laporan yang dibuat secara manual atau otomatis, berdasarkan jadwal yang telah ditentukan:
Jika Anda ingin membuat laporan baru secara manual, Anda akan menggunakan opsi 'Buat'. Pilih jenis laporan, nama cluster (untuk laporan per cluster), penerima email (opsional - jika Anda ingin laporan dikirimkan kepada Anda), dan Anda sudah selesai:
Laporan juga dapat dijadwalkan untuk dibuat secara teratur:
Saat ini, 5 jenis laporan tersedia:
- Laporan ketersediaan - Semua cluster.
- Laporan cadangan - Semua cluster.
- Laporan perubahan skema - kluster berbasis MySQL/MariaDB saja.
- Laporan sistem harian - Per cluster.
- Laporan peningkatan versi paket - Per cluster.
Laporan Ketersediaan
Laporan ketersediaan berfokus pada ketersediaan. Ini mencakup tiga bagian. Pertama, ringkasan ketersediaan:
Anda dapat melihat informasi tentang statistik ketersediaan database Anda, jenis cluster, total waktu aktif dan waktu henti, status cluster saat ini, dan kapan status terakhir diubah.
Bagian lain memberikan rincian lebih lanjut tentang ketersediaan untuk setiap cluster. Tangkapan layar di bawah ini hanya menunjukkan salah satu cluster database:
Kita bisa melihat kapan sebuah node beralih status dan apa transisinya. Ini adalah tempat yang bagus untuk memeriksa apakah ada masalah baru-baru ini dengan cluster. Data serupa ditampilkan di bagian ketiga laporan ini, tempat Anda dapat menelusuri riwayat perubahan status cluster.
Laporan Cadangan
Jenis laporan kedua adalah yang mencakup pencadangan semua klaster. Ini berisi dua bagian - ringkasan cadangan dan detail cadangan, di mana yang pertama pada dasarnya memberi Anda ringkasan singkat tentang kapan cadangan terakhir dibuat, jika berhasil atau gagal diselesaikan, status verifikasi cadangan, tingkat keberhasilan, dan periode penyimpanan:
ClusterControl juga memberikan contoh kebijakan pencadangan jika menemukan salah satu klaster basis data yang dipantau berjalan tanpa pencadangan terjadwal atau budak tertunda yang dikonfigurasi. Berikut detail backupnya:
Anda juga dapat memeriksa daftar cadangan yang dijalankan di cluster dengan status, jenis, dan ukurannya dalam interval yang ditentukan. Ini sedekat Anda bisa memastikan bahwa cadangan berfungsi dengan benar tanpa menjalankan tes pemulihan penuh. Kami sangat merekomendasikan bahwa tes semacam itu dilakukan sesekali. Kabar baiknya adalah ClusterControl mendukung pemulihan dan verifikasi berbasis MySQL pada host mandiri di bawah Backup -> Restore Backup.
Laporan Sistem Harian
Jenis laporan ini berisi informasi rinci tentang cluster tertentu. Dimulai dengan ringkasan berbagai peringatan yang terkait dengan cluster:
Bagian selanjutnya adalah tentang status node yang merupakan bagian dari cluster:
Anda memiliki daftar node dalam cluster, jenisnya, perannya (master atau slave), status node, waktu aktif, dan OS.
Bagian lain dari laporan ini adalah ringkasan cadangan, sama seperti yang telah kita bahas di atas. Berikutnya menyajikan ringkasan kueri teratas di cluster:
Terakhir, kami melihat “Ikhtisar status node” di mana Anda akan disajikan dengan grafik yang terkait dengan metrik OS dan MySQL untuk setiap node.
Seperti yang Anda lihat, kami memiliki grafik di sini yang mencakup semua aspek beban pada host - CPU, memori, jaringan, disk, beban CPU, dan bebas disk. Ini cukup untuk mendapatkan gambaran apakah sesuatu yang aneh terjadi baru-baru ini atau tidak. Anda juga dapat melihat beberapa detail tentang beban kerja MySQL - berapa banyak kueri yang dieksekusi, jenis kueri apa, bagaimana data diakses (melalui pengendali mana)? Ini, di sisi lain, harus cukup untuk memilih sebagian besar masalah di sisi MySQL. Apa yang ingin Anda lihat adalah semua lonjakan dan penurunan yang belum pernah Anda lihat di masa lalu. Mungkin kueri baru telah ditambahkan ke campuran dan, sebagai hasilnya, handler_read_rnd_next meroket? Mungkin ada peningkatan beban CPU dan jumlah koneksi yang tinggi mungkin menunjukkan peningkatan beban pada MySQL, tetapi juga beberapa jenis pertengkaran. Pola yang tidak terduga mungkin bagus untuk diselidiki, jadi Anda tahu apa yang sedang terjadi.
Laporan Peningkatan Paket
Laporan ini memberikan ringkasan paket yang tersedia untuk ditingkatkan oleh manajer repositori pada host yang dipantau. Untuk pelaporan yang akurat, pastikan Anda selalu menggunakan repositori yang stabil dan tepercaya di setiap host. Dalam beberapa kesempatan yang tidak diinginkan, host yang dipantau dapat dikonfigurasi dengan repositori usang setelah pemutakhiran (misalnya, setiap versi utama MariaDB menggunakan repositori yang berbeda), repositori internal yang tidak lengkap (mis. paket nightly-build).
Bagian pertama adalah ringkasan peningkatan:
Ini merangkum jumlah total paket yang tersedia untuk peningkatan serta layanan terkelola terkait untuk cluster seperti penyeimbang beban, alamat IP virtual, dan arbiter. Selanjutnya, ClusterControl menyediakan daftar paket terperinci, dikelompokkan berdasarkan jenis paket untuk setiap host:
Laporan ini menyediakan versi yang tersedia dan dapat sangat membantu kami merencanakan masa pemeliharaan secara efisien. Untuk pemutakhiran penting seperti keamanan dan paket basis data, kami dapat memprioritaskannya daripada pemutakhiran yang tidak penting, yang dapat digabungkan dengan periode pemeliharaan yang kurang prioritas.
Laporan Perubahan Skema
Laporan ini membandingkan perubahan database MySQL/MariaDB yang dipilih dalam struktur tabel yang terjadi antara dua laporan berbeda yang dihasilkan. Dalam versi MySQL/MariaDB yang lebih lama, operasi DDL adalah operasi non-atomik (sebelum 8.0) dan memerlukan salinan tabel lengkap (sebelum 5.6 untuk sebagian besar operasi) - memblokir transaksi lain hingga selesai. Perubahan skema bisa menjadi masalah besar setelah tabel Anda mendapatkan sejumlah besar data dan harus direncanakan dengan hati-hati terutama dalam pengaturan berkerumun. Dalam lingkungan pengembangan multi-tingkat, kami telah melihat banyak kasus di mana pengembang secara diam-diam memodifikasi struktur tabel, menghasilkan dampak yang signifikan terhadap kinerja kueri.
Agar ClusterControl menghasilkan laporan yang akurat, opsi khusus harus dikonfigurasi di dalam file konfigurasi CMON untuk masing-masing cluster:
- schema_change_detection_address - Pemeriksaan akan dilakukan menggunakan SHOW TABLES/SHOW CREATE TABLE untuk menentukan apakah skema telah berubah. Pemeriksaan dijalankan pada alamat yang ditentukan dan dalam format HOSTNAME:PORT. schema_change_detection_databases juga harus ditetapkan. Diferensial dari tabel yang diubah dibuat (menggunakan diff).
- schema_change_detection_databases - Daftar database yang dipisahkan koma untuk memantau perubahan skema. Jika kosong, tidak ada pemeriksaan yang dilakukan.
Dalam contoh ini, kami ingin memantau perubahan skema untuk database "myapp" dan "sbtest" di MariaDB Cluster kami dengan ID cluster 27. Pilih salah satu node database sebagai nilai schema_change_detection_address . Untuk replikasi MySQL, ini harus menjadi host master, atau host budak apa pun yang menyimpan database (jika replikasi parsial aktif). Kemudian, di dalam /etc/cmon.d/cmon_27.cnf, tambahkan dua baris berikut:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestMulai ulang layanan CMON untuk memuat perubahan:
$ systemctl restart cmonUntuk laporan pertama dan terpenting, ClusterControl hanya mengembalikan hasil pengumpulan metadata, seperti di bawah ini:
Dengan laporan pertama sebagai baseline, laporan berikutnya akan mengembalikan output yang kita harapkan:
Perhatikan hanya tabel baru atau tabel yang diubah yang dicetak dalam laporan. Laporan pertama hanya untuk pengumpulan metadata untuk perbandingan di putaran berikutnya, jadi kami harus menjalankannya setidaknya dua kali untuk melihat perbedaannya.
Dengan laporan ini, Anda sekarang dapat mengumpulkan jejak struktur database dan memahami bagaimana database Anda berkembang dari waktu ke waktu.
Pemikiran Terakhir
Laporan operasional adalah cara yang komprehensif untuk memahami keadaan infrastruktur database Anda. Itu dibangun untuk staf operasional atau manajerial, dan bisa sangat berguna dalam menganalisis operasi basis data Anda. Laporan dapat dibuat di tempat atau dapat dikirimkan kepada Anda melalui email, yang memudahkan segalanya jika Anda memiliki silo pelaporan.
Kami ingin mendengar masukan Anda tentang hal lain yang ingin Anda sertakan dalam laporan, apa yang hilang dan apa yang tidak diperlukan.
