Hari belanja online terbesar dalam setahun sudah dekat. Apakah database Anda sudah siap? Dengan menyetel 20 variabel kunci sistem MariaDB, Anda akan meningkatkan kinerja database Anda , skalabilitas dan ketersediaan , memastikan setiap calon pelanggan mendapatkan pengalaman pengguna yang lancar. Variabel sistem berikut muncul berulang kali dalam mengonfigurasi lingkungan server MariaDB yang optimal. Terapkan rekomendasi kami untuk nilai yang paling sesuai, dan jadikan periode Black Friday–Cyber Monday tahun ini yang terbaik.
Beberapa catatan penting:
- Jangan terima saran ini secara membabi buta. Setiap lingkungan MariaDB bersifat unik dan memerlukan pemikiran tambahan sebelum membuat perubahan apa pun. Kemungkinan besar Anda perlu menyesuaikan setelan ini untuk kasus penggunaan dan lingkungan spesifik Anda.
- File konfigurasi MariaDB terletak di /etc/my.cnf. Setiap kali Anda memodifikasi file ini, Anda harus memulai ulang layanan MySQL agar perubahan baru dapat diterapkan.
20 Rekomendasi Penyetelan Black Friday dan Cyber Monday
1. Ukuran Pool Buffer InnoDB
Ukuran kumpulan buffer InnoDB ini adalah setelan #1 yang harus diperhatikan untuk penginstalan apa pun yang menggunakan InnoDB. Kumpulan buffer adalah tempat data dan indeks di-cache; membuatnya sebesar mungkin akan memastikan Anda menggunakan memori dan bukan disk untuk sebagian besar operasi baca.
2. Ukuran File Log InnoDB
innodb_log-file-size adalah ukuran log redo, yang digunakan untuk memastikan penulisan berlangsung cepat dan tahan lama. Ada dua saran umum untuk ukuran file log InnoDB:
- Tetapkan ukuran total gabungan file log InnoDB lebih besar dari 25–50% ukuran kumpulan buffer InnoDB
atau
- Setel gabungan ukuran log file log InnoDB sama dengan entri log senilai satu jam selama pemuatan puncak
File log yang lebih besar dapat menyebabkan pemulihan yang lebih lambat jika terjadi kerusakan pada server. Namun, mereka juga mengurangi jumlah pos pemeriksaan yang diperlukan dan mengurangi I/O disk.
Evaluasi ukuran log biner senilai satu jam di bawah beban operasional, lalu putuskan apakah akan menambah ukuran file log InnoDB.
Mendapatkan ukuran file log innodb dengan benar adalah penting untuk mencapai kinerja sistem yang baik. Mesin penyimpanan InnoDB MariaDB menggunakan ruang redo log ukuran tetap (melingkar). Ukurannya dikontrol oleh innodb_log_file_size dan innodb_log_files_in_group (default 2). Kalikan nilai tersebut untuk mendapatkan ruang redo log yang tersedia untuk digunakan. Meskipun secara teknis tidak masalah apakah Anda menggunakan variabel innodb_log_file_size atau innodb_log_files_in_group untuk mengontrol ukuran ruang redo, kebanyakan orang hanya bekerja dengan innodb_log_file_size dan membiarkan innodb_log_files_in_group saja.
Ukuran ruang redo InnoDB adalah salah satu opsi konfigurasi terpenting untuk beban kerja intensif penulisan. Namun, itu datang dengan trade-off. Semakin banyak ruang redo yang dikonfigurasi, semakin baik InnoDB dapat mengoptimalkan I/O tulis. Namun, menambah ruang pengulangan juga berarti waktu pemulihan yang lebih lama saat sistem kehilangan daya atau mogok karena alasan lain.
3. Ukuran Penyangga Log InnoDB
Ukuran buffer log InnoDB yang lebih besar berarti lebih sedikit I/O disk untuk transaksi yang lebih besar. Disarankan untuk menyetel ini ke 64M di semua server.
4. Interval Penyiraman Log InnoDB
Variabel innodb_flush_log_at_trx_commit mengontrol saat pembilasan buffer log ke disk terjadi. innodb_flush_log_at_trx_commit =1 (default) mem-flush buffer log ke disk pada setiap commit transaksi. Ini adalah opsi yang paling aman tetapi juga dengan performa paling rendah.
innodb_flush_log_at_trx_commit =0 mem-flush buffer log ke disk setiap detik, tetapi tidak ada apa pun pada commit transaksi. Hingga satu detik (mungkin lebih karena penjadwalan proses) dapat hilang. Jika terjadi error, MySQL atau server dapat kehilangan data. Ini adalah opsi tercepat namun paling tidak aman.
innodb_flush_log_at_trx_commit =2 menulis buffer log ke file pada setiap komit, tetapi membuang ke disk setiap detik. Jika cache disk memiliki cadangan baterai (misalnya pengontrol serangan cache yang didukung baterai), ini biasanya merupakan keseimbangan terbaik antara kinerja dan keamanan. Sebuah crash MySQL seharusnya tidak kehilangan data. Kerusakan server atau pemadaman listrik dapat hilang hingga satu detik (mungkin lebih karena penjadwalan proses). Cache yang didukung baterai mengurangi kemungkinan ini.
Sebaiknya gunakan opsi pertama untuk keamanan.
5. Kapasitas IO InnoDB
innodb_io_capacity harus disetel ke kira-kira jumlah maksimum IOPS yang dapat ditangani oleh penyimpanan dasarnya.
Secara default, ini disetel ke 1000. Kami menyarankan untuk melakukan benchmarking penyimpanan untuk menentukan apakah Anda dapat meningkatkan nilai ini lebih lanjut.
6. Ukuran Tembolok Utas
Pantau nilai dari Threads_created. Jika terus meningkat lebih dari beberapa utas per menit, tingkatkan nilai utas_cache_size.
Ukuran cache thread disetel ke 200 dalam konfigurasi default saat ini.
7. Tembolok Tabel dan Tembolok Definisi Tabel
Variabel table_open_cache dan table_defintion_cache mengontrol jumlah tabel dan definisi agar tetap terbuka untuk semua rangkaian pesan.
Pantau Open_tables, Open_table_defintitions, Opened_tables, dan Opened_table_definitions untuk menentukan nilai terbaik. Saran umumnya adalah menyetel table_open_cache (dan selanjutnya table_definition_cache) hanya cukup tinggi untuk mengurangi tingkat peningkatan nilai status Opened_tables (dan Opened_table_definitions).
Baik table_open_cache dan table_defintion_cache diatur ke 2048 dalam konfigurasi default.
8. Tembolok Kueri
Tembolok kueri adalah hambatan terkenal yang dapat dilihat bahkan saat konkurensi sedang. Opsi terbaik adalah menonaktifkannya sejak hari pertama dengan menyetel query_cache_size =0 (default di MariaDB 10) dan menggunakan cara lain untuk mempercepat kueri baca:memiliki pengindeksan yang baik, menambahkan replika untuk menyebarkan beban baca atau menggunakan cache eksternal ( memcache atau redis, misalnya). Jika Anda telah membangun aplikasi MariaDB Anda dengan cache kueri diaktifkan dan tidak pernah melihat masalah apa pun, cache kueri mungkin bermanfaat bagi Anda. Dalam hal ini, berhati-hatilah jika Anda memutuskan untuk menonaktifkannya.
9. Tabel Sementara, tmp_table_size, dan max_heap_table_size
MySQL menggunakan yang lebih rendah dari max_heap_table_size dan tmp_table_size untuk membatasi ukuran tabel sementara di memori. Ini adalah per variabel klien. Meskipun memiliki nilai yang besar ini dapat membantu mengurangi jumlah tabel sementara yang dibuat pada disk, hal ini juga meningkatkan risiko mencapai kapasitas memori server karena ini adalah per klien. Umumnya 32M hingga 64M adalah nilai yang disarankan untuk memulai kedua variabel dan menyesuaikan sesuai kebutuhan.
Tabel sementara sering digunakan untuk GROUP BY, ORDER BY, DISTINCT, UNION, sub-kueri, dll. Idealnya, MySQL harus membuatnya di memori, dengan sesedikit mungkin di disk.
Penting untuk diperhatikan bahwa kueri yang tidak menggunakan gabungan dengan tepat dan membuat tabel sementara yang besar dapat menjadi salah satu alasan untuk jumlah tabel sementara yang lebih banyak di disk. Alasan lainnya adalah mesin penyimpanan memori menggunakan kolom dengan panjang tetap dan mengasumsikan skenario terburuk. Jika kolom tidak berukuran dengan benar (misalnya, VARCHAR(255) untuk string pendek), ini memengaruhi ukuran tabel dalam memori dan dapat menyebabkannya masuk ke disk lebih awal dari yang seharusnya. Selain itu, tabel sementara dengan blob dan kolom teks akan langsung masuk ke disk, karena mesin penyimpanan memori tidak mendukungnya.
Keduanya saat ini disetel ke 64 juta secara default.
10. Tingkat Log Peringatan
Sebaiknya setel level log peringatan ini ke log_warnings =2. Dengan melakukan itu, log informasi tentang koneksi yang dibatalkan dan kesalahan akses yang ditolak.
11. Koneksi Maks
Jika Anda sering menghadapi kesalahan “Terlalu banyak koneksi”, max_connections terlalu rendah. Sering kali, karena aplikasi tidak menutup koneksi ke database dengan benar, Anda memerlukan lebih dari koneksi default 151. Kelemahan utama dari nilai tinggi untuk max_connections (misalnya, 1.000 atau lebih) adalah server akan menjadi tidak responsif jika harus menjalankan banyak transaksi aktif. Menggunakan kumpulan koneksi di tingkat aplikasi atau kumpulan utas di tingkat MariaDB dapat membantu di sini.
12. Isolasi Transaksi
Selidiki tingkat isolasi transaksi yang tersedia, dan tentukan isolasi transaksi terbaik untuk kasus penggunaan server Anda.
13. Format Log Biner
Sebaiknya gunakan format log biner ROW untuk replikasi master-master.
14. Offset Peningkatan Otomatis
Untuk membantu mengurangi kemungkinan tabrakan antara dua master yang ditulis ke secara bersamaan, nilai peningkatan otomatis dan offset peningkatan otomatis perlu disesuaikan.
15. Sinkronkan Binlog
Secara default, OS menangani flushing binlog ke disk. Jika terjadi error server, transaksi dari log biner dapat hilang, yang menyebabkan replikasi menjadi tidak sinkron. Menyetel sync_binlog =1 menyebabkan file binlog di-flush pada setiap komit.
Ini lebih lambat, tetapi opsi paling aman.
16. Budak Crash Safe(r)
Untuk membantu menghindari kesalahan replikasi setelah crash slave, aktifkan pemulihan log relai dan sinkronisasi log relai dan file info log relai ke disk.
17. Log Pembaruan Budak
Agar replikasi berantai (master -> slave -> slave), log_slave_updates perlu diaktifkan. Tindakan ini memberi tahu slave untuk menulis transaksi yang direplikasi ke log binernya sendiri sehingga transaksi tersebut dapat direplikasi ke slave dari log tersebut.
18. Budak Hanya-Baca
Slave harus read-only untuk menghindari data yang tidak sengaja ditulis kepada mereka.
Catatan :Pengguna dengan hak istimewa super masih dapat menulis saat server hanya-baca.
19. Batas Waktu Bersih Budak
Variabel slave_net_timeout adalah jumlah detik slave akan menunggu paket dari master sebelum mencoba menyambung kembali. Standarnya adalah 3600 (1 jam). Artinya, jika link mati dan tidak terdeteksi, mungkin diperlukan waktu hingga satu jam sebelum slave terhubung kembali. Ini bisa menyebabkan budak tiba-tiba tertinggal satu jam di belakang tuannya.
Sebaiknya setel slave_net_timeout ke nilai yang lebih masuk akal, seperti 30 atau 60.
20. Tonton Webinar Kami tentang Mempersiapkan Black Friday &Cyber Monday
Tonton webinar sesuai permintaan kami – Mempersiapkan Black Friday &Cyber Monday – untuk mempelajari empat prinsip penting dari kesiapan database: langkah-langkah keamanan untuk melindungi database Anda dari serangan berbahaya, penyesuaian kinerja untuk memastikan Anda memberikan pengalaman pengguna yang lancar, strategi ketersediaan tinggi untuk memastikan Anda tidak melewatkan satu obral dan skalabilitas untuk mempersiapkan pertumbuhan yang diantisipasi dan lonjakan yang tidak terduga.
