Produsen server dan penyedia cloud menawarkan berbagai jenis solusi penyimpanan untuk memenuhi kebutuhan database Anda. Saat membeli server baru atau memilih instance cloud untuk menjalankan database, kita sering bertanya pada diri sendiri - berapa banyak ruang disk yang harus kita alokasikan? Seperti yang akan kita ketahui, jawabannya tidak sepele karena ada beberapa aspek yang perlu dipertimbangkan. Ruang disk adalah sesuatu yang harus dipikirkan terlebih dahulu, karena mengecilkan dan memperluas ruang disk dapat menjadi operasi yang berisiko untuk basis data berbasis disk.
Dalam posting blog ini, kita akan melihat bagaimana awalnya mengukur ruang penyimpanan Anda, dan kemudian merencanakan kapasitas untuk mendukung pertumbuhan database MySQL atau MariaDB Anda.
Bagaimana MySQL Memanfaatkan Ruang Disk
MySQL menyimpan data dalam file pada hard disk di bawah direktori tertentu yang memiliki variabel sistem "datadir". Isi datadir akan bergantung pada versi server MySQL, dan parameter konfigurasi yang dimuat serta variabel server (mis., general_log, slow_query_log, log biner).
Penyimpanan dan pengambilan informasi yang sebenarnya tergantung pada mesin penyimpanan. Untuk mesin MyISAM, indeks tabel disimpan dalam file .MYI, di direktori data, bersama dengan file .MYD dan .frm untuk tabel. Untuk mesin InnoDB, indeks disimpan di tablespace, bersama dengan tabel. Jika innodb_file_per_table Jika opsi diatur, indeks akan berada di file .ibd tabel bersama dengan file .frm. Untuk mesin memori, data disimpan di memori (heap) sedangkan strukturnya disimpan dalam file .frm di disk. Di MySQL 8.0 yang akan datang, file metadata (.frm, .par, dp.opt) dihapus dengan pengenalan skema kamus data baru.
Penting untuk dicatat bahwa jika Anda menggunakan tablespace bersama InnoDB untuk menyimpan data tabel (innodb_file_per_table=OFF ), ukuran data fisik MySQL Anda diperkirakan akan terus bertambah bahkan setelah Anda memotong atau menghapus baris data yang sangat besar. Satu-satunya cara untuk mendapatkan kembali ruang kosong dalam konfigurasi ini adalah dengan mengekspor, menghapus database saat ini dan mengimpornya kembali melalui mysqldump. Jadi, penting untuk menyetel innodb_file_per_table=ON jika Anda khawatir tentang ruang disk, jadi saat memotong tabel, ruang dapat diambil kembali. Selain itu, dengan konfigurasi ini, operasi DELETE yang besar tidak akan mengosongkan ruang disk kecuali OPTIMIZE TABLE dijalankan sesudahnya.
MySQL menyimpan setiap database di direktorinya sendiri di bawah jalur "datadir". Selain itu, file log dan file MySQL terkait lainnya seperti file soket dan PID, secara default, juga akan dibuat di bawah datadir. Untuk alasan kinerja dan keandalan, disarankan untuk menyimpan file log MySQL pada disk atau partisi terpisah - terutama log kesalahan MySQL dan log biner.
Estimasi Ukuran Basis Data
Cara dasar untuk memperkirakan ukuran adalah menemukan rasio pertumbuhan antara dua titik waktu yang berbeda, dan kemudian mengalikannya dengan ukuran database saat ini. Mengukur lalu lintas basis data jam sibuk Anda untuk tujuan ini bukanlah praktik terbaik, dan tidak mewakili penggunaan basis data Anda secara keseluruhan. Pikirkan tentang operasi batch atau prosedur tersimpan yang berjalan pada tengah malam, atau seminggu sekali. Basis data Anda berpotensi tumbuh secara signifikan di pagi hari, sebelum kemungkinan menyusut oleh operasi pembersihan di tengah malam.
Salah satu cara yang mungkin adalah menggunakan cadangan kami sebagai elemen dasar untuk pengukuran ini. Pencadangan fisik seperti Percona Xtrabackup, Cadangan MariaDB, dan snapshot sistem file akan menghasilkan representasi yang lebih akurat dari ukuran basis data Anda dibandingkan dengan pencadangan logis, karena berisi salinan biner dari basis data dan indeks. Pencadangan logis seperti mysqldump hanya menyimpan pernyataan SQL yang dapat dieksekusi untuk mereproduksi definisi objek database asli dan data tabel. Namun demikian, Anda masih bisa mendapatkan rasio pertumbuhan yang baik dengan membandingkan cadangan mysqldump.
Kita dapat menggunakan rumus berikut untuk memperkirakan ukuran database:
Dimana,
- B - Ukuran cadangan penuh minggu ini,
- B - Ukuran cadangan penuh minggu sebelumnya,
- Dbdata - Total ukuran data basis data,
- Dbindeks - Total ukuran indeks basis data,
- 52 - Jumlah minggu dalam setahun,
- Y - Tahun.
Total ukuran database (data dan indeks) dalam MB dapat dihitung dengan menggunakan pernyataan berikut:
mysql> SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) "DB Size in MB" FROM information_schema.tables;
+---------------+
| DB Size in MB |
+---------------+
| 2013.41 |
+---------------+Persamaan di atas dapat dimodifikasi jika Anda ingin menggunakan cadangan bulanan sebagai gantinya. Ubah nilai konstan 52 menjadi 12 (12 bulan dalam setahun) dan Anda siap melakukannya.
Juga, jangan lupa untuk memperhitungkan innodb_log_file_size x 2, innodb_data_file_path dan untuk Galera Cluster, tambahkan gcache.size nilai.
Estimasi Ukuran Log Biner
Log biner dihasilkan oleh master MySQL untuk tujuan replikasi dan pemulihan tepat waktu. Ini adalah kumpulan file log yang berisi informasi tentang modifikasi data yang dibuat di server MySQL. Ukuran log biner tergantung pada jumlah operasi tulis dan format log biner - PERNYATAAN, BARIS atau CAMPURAN. Log biner berbasis pernyataan biasanya jauh lebih kecil dibandingkan dengan log biner berbasis baris, karena hanya terdiri dari pernyataan tulis sedangkan berbasis baris terdiri dari informasi baris yang dimodifikasi.
Cara terbaik untuk memperkirakan penggunaan disk maksimum dari log biner adalah dengan mengukur ukuran log biner selama sehari dan mengalikannya dengan expire_logs_days nilai (default adalah 0 - tidak ada penghapusan otomatis). Penting untuk menyetel expire_logs_days sehingga Anda dapat memperkirakan ukuran dengan benar. Secara default, setiap log biner dibatasi sekitar 1GB sebelum MySQL memutar file log biner. Kita dapat menggunakan event MySQL untuk menghapus log biner untuk tujuan estimasi ini.
Pertama, pastikan variabel event_scheduler diaktifkan:
mysql> SET GLOBAL event_scheduler = ON;Kemudian, sebagai pengguna dengan hak istimewa (dengan hak istimewa EVENT dan RELOAD), buat acara berikut:
mysql> USE mysql;
mysql> CREATE EVENT flush_binlog
ON SCHEDULE EVERY 1 HOUR STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 2 HOUR
COMMENT 'Flush binlogs per hour for the next 2 hours'
DO FLUSH BINARY LOGS;Untuk beban kerja tulis yang intensif, Anda mungkin perlu mempersingkat interval menjadi 30 menit atau 10 menit sebelum log biner mencapai ukuran maksimum 1GB, lalu membulatkan output hingga satu jam. Kemudian verifikasi status event dengan menggunakan pernyataan berikut dan lihat pada kolom LAST_EXECUTED:
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...Kemudian, lihat log biner yang kita miliki sekarang:
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 146 |
| binlog.000002 | 1073742058 |
| binlog.000003 | 1073742302 |
| binlog.000004 | 1070551371 |
| binlog.000005 | 1070254293 |
| binlog.000006 | 562350055 | <- hour #1
| binlog.000007 | 561754360 | <- hour #2
| binlog.000008 | 434015678 |
+---------------+------------+Kami kemudian dapat menghitung rata-rata pertumbuhan log biner kami yaitu sekitar ~562 MB per jam selama jam sibuk. Kalikan nilai ini dengan 24 jam dan expire_logs_days nilai:
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+Kita akan mendapatkan 94416 MB yaitu sekitar ~95 GB ruang disk untuk log biner kami. Log relai Slave pada dasarnya sama dengan log biner master, kecuali bahwa mereka disimpan di sisi slave. Oleh karena itu, perhitungan ini juga berlaku untuk log relai budak.
Spindle Disk atau Solid State?
Ada dua jenis operasi I/O pada file MySQL:
- Berkas berorientasi I/O berurutan:
- Ruang tabel sistem InnoDB (ibdata)
- File log MySQL:
- Log biner (binlog.xxxx)
- ULANG log (ib_logfile*)
- Log umum
- Log kueri lambat
- Log kesalahan
- File berorientasi I/O acak:
- File data per tabel InnoDB (*.ibd) dengan innodb_file_per_table=ON (bawaan).
Pertimbangkan untuk menempatkan file berorientasi I/O acak dalam subsistem disk dengan throughput tinggi untuk kinerja terbaik. Ini bisa berupa flash drive - baik SSD atau kartu NVRAM, atau disk spindel RPM tinggi seperti SAS 15K atau 10K, dengan pengontrol RAID perangkat keras dan unit yang didukung baterai. Untuk file berorientasi I/O sekuensial, penyimpanan di HDD dengan cache tulis yang didukung baterai harus cukup baik untuk MySQL. Perhatikan bahwa penurunan kinerja mungkin terjadi jika baterai mati.
Kami akan membahas area ini (memperkirakan throughput disk dan alokasi file) dalam posting terpisah.
Perencanaan dan Dimensi Kapasitas
Perencanaan kapasitas dapat membantu kami membangun server basis data produksi dengan sumber daya yang cukup untuk bertahan dalam operasi sehari-hari. Kami juga harus menyediakan kebutuhan yang tidak terduga, memperhitungkan penyimpanan di masa mendatang dan kebutuhan throughput disk. Oleh karena itu, perencanaan kapasitas penting untuk memastikan database memiliki cukup ruang untuk bernafas hingga siklus penyegaran perangkat keras berikutnya.
Yang terbaik adalah mengilustrasikan ini dengan sebuah contoh. Mempertimbangkan skenario berikut:
- Siklus perangkat keras berikutnya:3 tahun
- Ukuran basis data saat ini:2013 MB
- Ukuran cadangan penuh saat ini (minggu N):1177 MB
- Ukuran cadangan penuh sebelumnya (minggu N-1):936 MB
- Ukuran delta:241 MB per minggu
- Rasio delta:kenaikan 25,7% per minggu
- Total minggu dalam 3 tahun:156 minggu
- Estimasi ukuran basis data total:((1177 - 936) x 2013 x 156)/936 =80856 MB ~ 81 GB setelah 3 tahun
Jika Anda menggunakan log biner, jumlahkan dari nilai yang kita dapatkan di bagian sebelumnya:
- 81 + 95 =176 GB penyimpanan untuk database dan log biner.
Tambahkan setidaknya 100% lebih banyak ruang untuk tugas operasional dan pemeliharaan (pencadangan lokal, staging data, log kesalahan, file sistem operasi, dll):
- 176 + 176 =352 GB total ruang disk.
Berdasarkan estimasi ini, kami dapat menyimpulkan bahwa kami membutuhkan setidaknya 352 GB ruang disk untuk database kami selama 3 tahun. Anda dapat menggunakan nilai ini untuk membenarkan pembelian perangkat keras baru Anda. Misalnya, jika Anda ingin membeli server khusus baru, Anda dapat memilih 6 x 128 SSD RAID 10 dengan pengontrol RAID yang didukung baterai yang akan memberi Anda sekitar 384 GB total ruang disk. Atau, jika Anda lebih suka cloud, Anda bisa mendapatkan penyimpanan blok 100GB dengan IOPS yang disediakan untuk penggunaan database 81GB kami dan menggunakan penyimpanan blok persisten standar untuk log biner 95GB dan penggunaan operasional lainnya.
Selamat mengukur dimensi!
