Commit yang Sudah Dijawab Bisa Belum di Disk
Bayangkan pembeli melihat layar berhasil setelah checkout, tetapi catatannya belum aman di disk. Panduan innodb_flush_log_at_trx_commit wordpress ini menjelaskan jeda itu: commit yang sudah dijawab PHP bisa masih menunggu flush dari memori ke disk. Kalau crash datang pada jeda itu, baris pesanan bisa hilang walau layar sudah bilang berhasil.
Variabel ini mengatur satu hal: kapan redo log dipaksa dari buffer di memori ke disk saat commit terjadi. Nilainya ada empat, yaitu 0, 1, 2, dan 3, dan masing-masing menanggung jenis kegagalan yang berbeda. Nilai defaultnya 1, yang menulis sekaligus memaksa flush pada setiap commit demi daya tahan penuh.
Artikel ini membahas keempat nilai itu, membedakan dua jenis crash, dan menunjukkan kenapa saran ubah ke 2 belum lengkap tanpa jendelanya. Kamu juga membaca cara memeriksa nilai yang berjalan dan di hosting mana ia bisa diubah.
Empat Nilai, Bukan Saklar Cepat atau Lambat
Perbandingan innodb_flush_log_at_trx_commit 1 vs 2 adalah inti artikel ini. Nilai 1 adalah default: setiap commit ditulis ke redo log dan langsung di-flush ke disk.
Nilai 2 tidak kalah hanya pada crash proses. Padam listrik masih bisa menghapus commit yang baru diakui, karena flush ke disk belum terjadi.
| Nilai | Pada commit, menurut dokumentasi MariaDB | Yang masih bisa hilang |
|---|---|---|
1 (default) | Ditulis ke redo log dan di-flush ke disk | Bukan commit yang sudah diakui, selama disknya sendiri tidak rusak |
0 | Tidak ada tindakan. Tulis dan flush menyusul, default sekali per detik | Crash proses server, transaksi pada jeda itu |
2 | Ditulis ke redo log. Flush menyusul tiap innodb_flush_log_at_timeout | Padam listrik atau matinya sistem operasi, bukan crash proses saja |
3 | Flush pada prepare dan pada commit. Lebih lambat dari 1 | Bukan jalan pintas. Flush ekstra biasanya mubazir |
Jeda flush pada nilai 0 dan 2 mengikuti innodb_flush_log_at_timeout yang defaultnya 1. Nilai 3 memaksa flush dua kali sehingga lebih lambat dari 1.
Crash Proses dan Padam Listrik Bukan Kejadian yang Sama
Pada perbandingan innodb_flush_log_at_trx_commit 1 vs 2, bedakan dulu dua kejadian ini. Crash proses berarti daemon MariaDB mati tetapi mesin dan disk tetap hidup. Padam listrik berarti mesinnya ikut mati, sehingga isi memori yang belum di-flush ikut hilang. Keduanya terdengar mirip, tetapi crash proses dan padam listrik menanggung nilai yang berbeda.
Pada nilai 0, tidak ada tindakan saat commit, sehingga crash proses saja sudah bisa menghapus transaksi pada jeda itu. Pada nilai 2, setiap commit sudah ditulis ke redo log, jadi crash proses tidak menghapusnya. Yang menghapus adalah padam listrik atau matinya sistem operasi sebelum flush susulan terjadi.
Inilah kenapa label sekitar satu detik menipu. Pada nilai 0, yang hilang adalah detik terakhir saat proses mati. Pada nilai 2, yang hilang adalah commit yang diakui tetapi belum di-flush saat listrik padam. Diagram di bawah menaruh padam listrik di antara keduanya.
Pesanan yang Sudah Tampil Berhasil
Konteks innodb_flush_log_at_trx_commit woocommerce membuat jendela itu konkret. Checkout menulis beberapa commit sekaligus: baris pesanan, item-itemnya, dan status pesanannya. PHP mengembalikan layar berhasil setelah commit-commit itu diakui, bukan setelah semuanya aman di disk.
Kalau server berjalan pada nilai 0 lalu proses MariaDB crash sebelum flush susulan, transaksi pada jeda itu bisa hilang. Pesanan yang baru saja tampil berhasil tidak ada barisnya di database. Pembeli memegang bukti layar, toko tidak memegang baris pesanan.
Pada nilai 2, skenarionya sama tetapi pemicunya berbeda: commit sudah ditulis ke redo log sehingga crash proses tidak menghapusnya. Listrik padam sebelum flush susulan itulah yang menghapus commit yang sudah diakui. Bedanya tipis di teori, tetapi jauh di akibat: satu butuh proses mati, satunya butuh mesin mati.
Karena itu, toko yang tidak boleh kehilangan pesanan yang sudah dijawab bertahan di nilai 1. Menurunkan nilai demi beban disk yang lebih ringan tanpa menyebut jendela berarti memindahkan risiko ke momen paling ramai. Bagian berikut menegaskan variabel ini bukan soal ukuran memori, melainkan soal kapan catatan dipaksa ke disk.
Bukan Buffer Pool, Bukan Slow Query
Variabel ini bukan buffer pool. Pool menyimpan halaman data agar dibaca ulang tanpa menyentuh disk, sedangkan variabel ini menentukan kapan catatan redo log dipaksa ke disk. Satu kalimat panduannya ada di artikel InnoDB Buffer Pool WordPress: halaman yang menetap di memori tidak membuat commit lebih tahan crash.
Menunggu flush juga bukan SELECT yang lambat. Query yang menatap layar loading karena commit belum di-flush tidak akan ketahuan dari daftar query lambat. Bedanya dijelaskan satu kalimat di artikel Slow Query Log WordPress: log itu menangkap pernyataan yang lama dieksekusi, bukan commit yang lama dipaksa ke disk.
Singkatnya, halaman lambat dibaca menunjuk ke pool, pernyataan lambat ke log query, dan pesanan hilang setelah crash ke nilai flush.
Binary Log adalah Fsync yang Kedua
Dokumentasi menulis daya tahan terbesar didapat dari nilai 1 bersama sync_binlog=1. Kalimat itu berhenti di situ: redo log mencatat perubahan halaman InnoDB, binary log mencatat pernyataan untuk diputar ulang. Keduanya di-flush secara terpisah dan tidak saling menggantikan.
Artinya, menaikkan daya tahan redo log tidak menutup lubang binary log, dan sebaliknya. Kalau daya tahan commit yang dibahas, knopnya tetap nilai flush ini, bukan knop log yang satunya.
Untuk toko, pegangannya sederhana dan berlaku umum: nilai 1 menjaga redo log dan binary log dijaga knopnya sendiri. Mengubah satu lalu menganggap satunya ikut aman adalah kesalahan yang mahal. Kalau ada saran yang mencampur keduanya jadi satu janji, minta kalimat dokumentasinya ditunjukkan.
Resep Ubah ke 2 Tidak Menyebutkan Jendelanya
Resep ubah ke 2 memang mengurangi flush pada setiap commit, dan di situlah letak jendelanya. Setiap commit yang diakui tetapi belum di-flush menjadi taruhan pada listrik yang tetap menyala. Selama listrik aman semuanya terlihat ringan, tetapi satu padam menghapus commit pada jeda itu. Itulah harga yang tidak disebut resep.
Menurunkan ke 0 memperlebar jendela itu ke crash proses: tidak ada tindakan pada commit, dan transaksi pada jeda bisa hilang walau mesin tetap hidup. Nilai 3 bukan penebusnya: flush pada prepare dan commit membuatnya lebih lambat dari 1, bukan lebih cepat. Tiga perpindahan ini semua soal arah risiko, bukan angka percepatan.
Kalau beban disk yang dikeluhkan, jawabannya bukan memutar nilai ini membabi buta. Baca dulu nilai yang berjalan, cocokkan dengan crash yang berani ditanggung, baru putuskan. Tanpa urutan itu, angka yang dipilih hanya tebakan berbayar.
Cara Membaca Nilai dan Jendela Kehilangannya
Urutannya tetap: baca nilai yang hidup di server, cocokkan dengan jenis crash yang berani ditanggung, baru putuskan dengan tenang tetap di 1 atau pindah dengan sadar. Jangan melompat ke angka sebelum ketiga langkah berikut selesai, karena angka di blog bukan angka di server. Tiga langkah di bawah memandu urutan itu tanpa menyuruh mengubah apa pun dulu.
Setiap langkah menjawab satu pertanyaan: berapa nilainya, crash apa risikonya, dan apa keputusannya.
Baca Nilai yang Sedang Berjalan
Baca innodb_flush_log_at_trx_commit dan innodb_flush_log_at_timeout dengan SHOW GLOBAL VARIABLES pada server yang dipakai toko. Dua angka itu yang menentukan jendela kehilanganmu, bukan angka di artikel ini. Cuplikan berikut ilustrasi bentuknya:
-- Ilustrasi: baca nilai flush dan jedanya.
SHOW GLOBAL VARIABLES LIKE 'innodb_flush_log_at%';Kolom nilai menjawab dua hal sekaligus: angka flush yang berlaku dan jeda timeout yang menyertainya. Timeout itu defaultnya 1, tetapi baca angkanya, jangan mengasumsikan satu detik. Kalau timeout diubah dari default, jendela nilai 2 ikut berubah.
Nilai global bisa berbeda dari session, jadi baca konteks yang dipakai aplikasi. Kalau tokomu di Cloud Hosting, jangan mengubah pengaturan database; cukup catat kedua nilai sebagai bahan diskusi dengan tim teknis.
Cocokkan dengan Jenis Crash
Ajukan dua pertanyaan sebelum menyentuh angka. Pertama, apakah yang ditakutkan adalah proses MariaDB yang mati mendadak, karena crash proses menghapus transaksi pada jeda nilai 0. Kedua, apakah mesinnya ikut mati saat kejadian itu.
Kalau jawabannya ya, nilai 2 adalah risikonya, karena padam listrik menghapus commit yang belum di-flush walau sudah ditulis ke redo log. Nilai 1 menutup kedua jendela itu dengan memaksa flush pada setiap commit. Jawaban jujur atas dua pertanyaan ini menentukan apakah pindah nilai layak dipertimbangkan.
Tidak ada jawaban yang salah, yang ada hanya jendela yang diterima dengan sadar atau tidak.
Putuskan Tetap 1, atau 2 dengan Jendela yang Sadar
Tiga baris berikut merangkum keputusan, tanpa mengulang isi artikel rujukan.
| Yang dihadapi | Langkah | Bukan langkah pertamanya |
|---|---|---|
| Checkout tidak boleh kehilangan pesanan yang sudah dijawab | Pertahankan 1, dan sebut sync_binlog satu kalimat | Mengubah ke 2 karena sebuah blog menjanjikan I/O lebih rendah |
| Disk sesak dan jendela padam listrik diterima | 2, dengan timeout yang dibaca, bukan diasumsikan satu detik | Langsung ke 0 |
Nilai sudah 1 tetapi pesanan tetap hilang | Cek apakah PHP benar-benar sudah commit, sebelum menyentuh pool | Menaikkan buffer pool atau berpindah ke nilai 3 supaya lebih aman |
Cabang yang benar menghemat jam kerja.
Di Hosting Mana Nilai Ini Bisa Diubah
Di Cloud Hosting Mordenhost, gejala checkout seperti ini bisa dibantu tim teknis saat kamu melaporkan layar mana yang bermasalah dan kapan terjadinya. Catat jam kejadiannya dan apakah pesanan yang hilang muncul lagi setelah refresh. Akses variabel global database tidak termasuk di sini, jadi yang dibaca dari WordPress hanyalah gejalanya.
Tim yang perlu memilih nilai 1 atau 2 setelah jendelanya dipahami butuh akses server. Managed VPS Mordenhost cocok untuk kasus ini, mulai Rp950.000 per bulan: nilainya bisa diubah setelah jendelanya disepakati. Jangan pindah sebelum jendelanya disebut, karena harga paket tidak menutup commit yang hilang. Fondasi cara server bekerja dijelaskan ringkas di artikel memahami cara kerja hosting.
Pertanyaan yang Sering Ditanya
Empat jawaban singkat soal nilai 2 saat padam, crash proses, buffer pool, dan akses di Cloud Hosting.
Apakah nilai 2 sama amannya dengan nilai 1 saat listrik padam?
Tidak. Nilai 2 sudah menulis commit ke redo log, tetapi flush ke disk baru menyusul tiap jeda yang diatur. Listrik padam pada jeda itu bisa menghapus commit. Nilai 1 memaksa flush pada setiap commit.
Apakah crash proses MariaDB menghapus commit pada nilai 2?
Bukan itu yang ditulis dokumentasi. Nilai 2 kehilangan transaksi saat sistem operasi atau listrik mati. Crash proses yang menghapus sekitar satu detik adalah perilaku nilai 0. Keduanya jangan ditukar.
Apakah menaikkan buffer pool membuat commit lebih tahan crash?
Tidak. Buffer pool menyimpan halaman data yang dibaca. Variabel flush menentukan kapan catatan redo log dipaksa ke disk. Menaikkan pool tidak menutup jendela commit, dan sebaliknya.
Apakah Cloud Hosting bisa mengubah nilai flush ini?
Tidak lewat berkas konfigurasi database. Mengubahnya butuh akses server dan keputusan soal commit mana yang boleh hilang. Itu ranah Managed VPS, bukan panel hosting bersama.
Butuh bantuan membaca nilai flush atau memilih paket yang pas? Hubungi WhatsApp Mordenhost dan tim kami membantu memetakan langkah berikutnya.
