Optimasi Mesin Penyimpanan MySQL:Mengonfigurasi Optimasi InnoDB Untuk Kinerja Tinggi

InnoDB adalah salah satu mesin penyimpanan yang paling banyak digunakan di MySQL. Mesin penyimpanan ini dikenal sebagai mesin penyimpanan dengan keandalan tinggi dan kinerja tinggi dan keunggulan utamanya termasuk mendukung penguncian tingkat baris, kunci asing, dan mengikuti model ACID. InnoDB menggantikan MyISAM sebagai mesin penyimpanan default sejak MySQL 5.5, yang dirilis pada 2010.

Mesin penyimpanan ini dapat menjadi sangat berperforma dan kuat jika dioptimalkan dengan benar - hari ini kita melihat hal-hal yang dapat kita lakukan untuk membuatnya bekerja dengan kemampuan terbaiknya, tetapi sebelum kita menyelami ke InnoDB, kita harus memahami apa model ACID yang disebutkan di atas.

Apa itu ACID dan Mengapa Penting?

ACID adalah sekumpulan properti dari transaksi basis data. Singkatan ini diterjemahkan menjadi empat kata:Atomicity, Consistency, Isolation, dan Durability. Singkatnya, properti ini memastikan bahwa transaksi basis data diproses dengan andal dan menjamin validitas data meskipun ada kesalahan, pemadaman listrik, atau masalah semacam itu. Sebuah sistem manajemen database yang menganut prinsip-prinsip ini dikatakan sebagai DBMS yang sesuai dengan ACID. Begini cara kerja semuanya di InnoDB:

• Atomicity memastikan bahwa pernyataan dalam transaksi beroperasi sebagai unit yang tidak dapat dibagi dan bahwa efeknya terlihat secara kolektif atau tidak sama sekali;
• Konsistensi ditangani oleh mekanisme logging MySQL yang mencatat semua perubahan ke database;
• Isolasi mengacu pada penguncian tingkat baris InnoDB;
• Daya tahan juga dipertahankan karena InnoDB memelihara file log yang melacak semua perubahan pada sistem.

Memahami InnoDB

Sekarang kita telah membahas ACID, kita mungkin harus melihat bagaimana tampilan InnoDB di bawah tenda. Begini tampilan InnoDB dari dalam (gambar milik Percona):

Dari gambar di atas kita dapat melihat dengan jelas bahwa InnoDB memiliki beberapa parameter penting untuk kinerjanya dan ini adalah sebagai berikut:

• Parameter innodb_data_file_path menjelaskan tablespace sistem (sistem tablespace adalah area penyimpanan untuk kamus data InnoDB, buffer tulis dan ubah ganda, dan log undo). Parameter menggambarkan file tempat data yang berasal dari tabel InnoDB akan disimpan;
• Parameter innodb_buffer_pool_size adalah buffer memori yang digunakan InnoDB untuk menyimpan data dan indeks tabelnya di cache;
• Parameter innodb_log_file_size menggambarkan ukuran file log InnoDB;
• Parameter innodb_log_buffer_size digunakan untuk menulis ke file log di disk;
• Parameter innodb_flush_log_at_trx_commit mengontrol keseimbangan antara kepatuhan ACID yang ketat dan kinerja yang lebih tinggi;
• Parameter innodb_lock_wait_timeout adalah lamanya waktu dalam detik transaksi InnoDB menunggu kunci baris sebelum menyerah;
• Parameter innodb_flush_method mendefinisikan metode yang digunakan untuk menyiram data ke file data InnoDB dan file log yang dapat memengaruhi throughput I/O.

InnoDB juga menyimpan data dari tabelnya dalam file bernama ibdata1 - log disimpan dalam dua file terpisah bernama ib_logfile0 dan ib_logfile1:ketiga file tersebut berada di /var/lib/mysql direktori.

Untuk membuat InnoDB berkinerja sebaik mungkin, kita harus menyempurnakan parameter ini dan mengoptimalkannya sebanyak mungkin dengan melihat sumber daya perangkat keras yang tersedia.

Menyetel InnoDB Untuk Performa Tinggi

Untuk menyesuaikan kinerja InnoDB pada perangkat keras Anda, ikuti langkah-langkah berikut:

• Untuk memperluas innodb_data_file_path secara otomatis, tentukan atribut autoextend dalam pengaturan dan mulai ulang server. Misalnya:

innodb_data_file_path=ibdata1:10M:autoextend

Bila parameter autoextend digunakan, ukuran file data secara otomatis bertambah sebesar 8MB setiap ruang waktu diperlukan. File data perpanjangan otomatis baru juga dapat ditentukan seperti itu (dalam hal ini, file data baru disebut ibdata2):

innodb_data_file_path=ibdata1:10M;ibdata2:10M:autoextend

• Saat menggunakan InnoDB, mekanisme utama yang digunakan adalah buffer pool. InnoDB sangat bergantung pada buffer pool dan sebagai aturan praktis, parameter innodb_buffer_pool_size harus sekitar 60% hingga 80% dari total RAM yang tersedia di server. Ingatlah bahwa Anda juga harus meninggalkan sebagian RAM untuk proses yang berjalan di OS;

• Innodb_log_file_size InnoDB harus disetel sebesar mungkin, tetapi tidak lebih besar dari yang diperlukan. Dalam hal ini, perlu diingat bahwa ukuran file log yang lebih besar lebih baik untuk kinerja, tetapi semakin besar, semakin banyak waktu pemulihan setelah crash diperlukan. Dengan demikian, tidak ada solusi "satu ukuran cocok untuk semua", tetapi dikatakan bahwa ukuran gabungan file log harus cukup besar. Ini membantu server MySQL dari secara teratur bekerja pada pos pemeriksaan dan aktivitas pembilasan disk. Ini menghemat terlalu banyak CPU dan IO disk dan dapat berjalan dengan lancar selama waktu puncaknya atau aktivitas beban kerja yang tinggi. Meskipun pendekatan yang disarankan adalah menguji dan bereksperimen sendiri dan menemukan nilai optimal sendiri;

• Nilai innodb_log_buffer_size harus disetel ke setidaknya 16 juta. Buffer log yang besar memungkinkan transaksi besar berjalan tanpa perlu menulis log ke disk sebelum transaksi melakukan penyimpanan beberapa I/O disk;

• Saat menyetel innodb_flush_log_at_trx_commit, ingatlah bahwa parameter ini menerima tiga nilai - 0, 1 dan 2. Dengan nilai 1 Anda mendapatkan kepatuhan ACID dan dengan nilai 0 atau 2 Anda mendapatkan kinerja yang lebih baik, tetapi keandalannya lebih rendah karena dalam kasus tersebut transaksi yang lognya belum di-flush ke disk dapat hilang dalam kecelakaan;

• Untuk menyetel innodb_lock_wait_timeout ke nilai yang tepat, ingatlah bahwa parameter ini menentukan waktu dalam detik (nilai defaultnya adalah 50) sebelum mengeluarkan kesalahan berikut dan memutar kembali pernyataan saat ini:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

• Di InnoDB, ada beberapa metode flush yang tersedia. Secara default, pengaturan ini disetel ke “async_unbuffered” pada mesin Windows jika nilainya disetel ke NULL dan ke “fsync” di mesin Linux. Inilah metode dan fungsinya:

• Anda juga harus mempertimbangkan untuk mengaktifkan pengaturan innodb_file_per_table. Parameter ini AKTIF secara default di MySQL 5.6 dan lebih tinggi. Parameter ini membebaskan Anda dari masalah manajemen yang berkaitan dengan tabel InnoDB dengan menyimpannya dalam file terpisah dan menghindari kamus utama dan tabel sistem yang membengkak. Mengaktifkan variabel ini juga menghindari kerumitan pemulihan data saat tabel tertentu rusak
• Sekarang setelah Anda mengubah pengaturan ini sesuai petunjuk yang diuraikan di atas, Anda seharusnya hampir siap untuk pergi! Sebelum Anda mulai bekerja, Anda mungkin harus mengawasi file tersibuk di seluruh infrastruktur InnoDB - ibdata1.

Berurusan dengan ibdata1

Ada beberapa kelas informasi yang disimpan di ibdata1:

1. Data tabel InnoDB;
2. Indeks tabel InnoDB;
3. Metadata tabel InnoDB;
4. Data Kontrol Konkurensi Multiversi (MVCC);
5. Buffer doublewrite - buffer semacam itu memungkinkan InnoDB memulihkan dari halaman yang setengah ditulis. Tujuan buffer tersebut adalah untuk mencegah kerusakan data;
6. Buffer sisipan - buffer semacam itu digunakan oleh InnoDB untuk menyangga pembaruan ke halaman yang sama sehingga dapat dilakukan sekaligus dan tidak satu per satu.

Ketika berhadapan dengan kumpulan data besar, file ibdata1 bisa menjadi sangat besar dan ini bisa menjadi inti dari masalah yang sangat membuat frustrasi - file hanya dapat tumbuh dan secara default, tidak dapat menyusut. Anda dapat mematikan MySQL dan menghapus file ini tetapi ini tidak disarankan kecuali Anda tahu apa yang Anda lakukan. Saat dihapus, MySQL tidak akan berfungsi dengan baik karena kamus dan tabel sistem hilang, sehingga tabel sistem utama rusak.

Untuk mengecilkan ibdata1 untuk selamanya, ikuti langkah-langkah berikut:

1. Buang semua data dari database InnoDB. Anda dapat menggunakan mysqldump atau mysqlpump untuk tindakan ini;
2. Lepaskan semua database kecuali database mysql, performance_schema, dan information_schema;
3. Hentikan MySQL;
4. Tambahkan berikut ini ke file my.cnf Anda:

   [mysqld]
   innodb_file_per_table = 1
   innodb_flush_method = O_DIRECT
   innodb_log_file_size = 25% of innodb_buffer_pool_size
   innodb_buffer_pool_size = up to 60-80% of available RAM.

5. Hapus file ibdata1 dan ib_logfile* (ini akan dibuat ulang setelah MySQL memulai ulang berikutnya);
6. Mulai MySQL dan pulihkan data dari dump yang Anda ambil sebelumnya. Setelah melakukan langkah-langkah yang diuraikan di atas, file ibdata1 akan tetap bertambah, tetapi tidak lagi berisi data dari tabel InnoDB - file hanya akan berisi metadata dan setiap tabel InnoDB akan ada di luar ibdata1. Sekarang, jika Anda pergi ke direktori /var/lib/mysql, Anda akan melihat dua file yang mewakili setiap tabel yang Anda miliki dengan mesin InnoDB. File akan terlihat seperti ini:
   1. dapat didemo.frm
   2. demotable.ibd

File .frm berisi header mesin penyimpanan dan file .ibd berisi data tabel dan indeks tabel Anda.

Sebelum meluncurkan perubahan, pastikan untuk menyempurnakan parameter sesuai dengan infrastruktur Anda. Parameter ini dapat meningkatkan atau merusak kinerja InnoDB, jadi pastikan untuk selalu mengawasinya. Sekarang Anda harus siap!

Ringkasan

Ringkasnya, mengoptimalkan kinerja InnoDB dapat menjadi keuntungan besar jika Anda mengembangkan aplikasi yang memerlukan integritas data dan kinerja tinggi pada saat yang sama - InnoDB memungkinkan Anda untuk mengubah berapa banyak memori yang diizinkan mesin konsumsi, untuk mengubah ukuran file log, metode flush yang digunakan mesin, dan sebagainya - perubahan ini dapat membuat InnoDB berkinerja sangat baik jika disetel dengan benar. Namun, sebelum melakukan peningkatan apa pun, waspadalah terhadap konsekuensi tindakan Anda terhadap server dan MySQL Anda.

Seperti biasa, sebelum mengoptimalkan apa pun untuk kinerja, selalu ambil (dan uji!) cadangan sehingga Anda dapat memulihkan data jika perlu dan selalu menguji perubahan apa pun di server lokal sebelum meluncurkan perubahan ke produksi.