Apakah aman menggunakan innodb_flush_log_at_trx_commit = 2

Saya berbalik innodb_flush_log_at_trx_commit = 2dan mendapatkan kecepatan menulis yang sangat cepat. Tetapi apakah aman digunakan di situs web produksi?

Anda dapat kehilangan nilai transaksi satu detik. Nilai default adalah 1, yang membantu menjaga InnoDB ACID Compliant .

Menurut Dokumentasi MySQL di innodb_flush_log_at_trx_commit

Jika nilai innodb_flush_log_at_trx_commit adalah 0, buffer log ditulis ke file log sekali per detik dan operasi flush to disk dilakukan pada file log, tetapi tidak ada yang dilakukan pada komit transaksi. Ketika nilainya 1 (default), buffer log dituliskan ke file log di setiap komit transaksi dan operasi flush to disk dilakukan pada file log. Ketika nilainya 2, buffer log dituliskan ke file di setiap commit, tetapi operasi flush to disk tidak dilakukan di sana. Namun, pembilasan pada file log terjadi sekali per detik juga ketika nilainya 2. Perhatikan bahwa pembilasan sekali per detik tidak 100% dijamin terjadi setiap detik, karena masalah penjadwalan proses.

Nilai default 1 diperlukan untuk kepatuhan ACID penuh. Anda dapat mencapai kinerja yang lebih baik dengan menetapkan nilai yang berbeda dari 1, tetapi kemudian Anda dapat kehilangan nilai transaksi hingga satu detik dalam kerusakan. Dengan nilai 0, setiap proses mysqld crash dapat menghapus detik terakhir transaksi. Dengan nilai 2, hanya sistem operasi crash atau pemadaman listrik dapat menghapus detik terakhir transaksi. Pemulihan crash InnoDB berfungsi terlepas dari nilainya.

Untuk daya tahan dan konsistensi sebesar mungkin dalam pengaturan replikasi menggunakan InnoDB dengan transaksi, gunakan innodb_flush_log_at_trx_commit = 1 dan sync_binlog = 1 di file my.cnf server master Anda.

Peringatan

Banyak sistem operasi dan beberapa perangkat keras disk mengelabui operasi flush-to-disk. Mereka mungkin memberi tahu mysqld bahwa flush telah terjadi, walaupun belum. Maka daya tahan transaksi tidak dijamin bahkan dengan pengaturan 1, dan dalam kasus terburuk pemadaman listrik bahkan dapat merusak database InnoDB. Menggunakan cache disk yang didukung baterai dalam pengontrol disk SCSI atau dalam disk itu sendiri mempercepat flush file, dan membuat operasi lebih aman. Anda juga dapat mencoba menggunakan perintah Unix hdparm untuk menonaktifkan cache tulis di cache perangkat keras, atau menggunakan perintah lain yang khusus untuk vendor perangkat keras.

Berdasarkan hal ini, nilai selain 1 membuat InnoDB berisiko kehilangan nilai transaksi 1 detik, atau nilai data komitmen transaksi.

Dokumentasi juga mengatakan penggunaan sync_binlog=1.

Menurut Dokumentasi MySQL di sync_binlog

Nilai 1 adalah pilihan paling aman karena jika terjadi crash Anda kehilangan paling banyak satu pernyataan atau transaksi dari log biner. Namun, ini juga pilihan paling lambat (kecuali disk memiliki cache yang didukung baterai, yang membuat sinkronisasi sangat cepat).

Pilihan teraman Anda adalah

[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Jika Anda tidak keberatan dengan kemungkinan kehilangan data (hingga nilai 1 detik) maka Anda dapat menggunakan 0 atau 2 dengan risiko Anda sendiri jika hadiah (kecepatan menulis lebih cepat) sepadan.

The innodb_flush_log_at_trx_commitdigunakan dengan tujuan sebagai ..

Jika nilai innodb_flush_log_at_trx_commit 0, buffer log ditulis ke file log sekali per detik dan operasi flush to disk dilakukan pada file log, tetapi tidak ada yang dilakukan pada komit transaksi.

Ketika nilainya 1 (default), buffer log dituliskan ke file log di setiap komit transaksi dan operasi flush to disk dilakukan pada file log.

Ketika nilainya 2, buffer log dituliskan ke file di setiap commit, tetapi operasi flush to disk tidak dilakukan di sana. Namun, pembilasan pada file log terjadi sekali per detik juga ketika nilainya 2. Perhatikan bahwa pembilasan sekali per detik tidak 100% dijamin terjadi setiap detik, karena masalah penjadwalan proses.

Nilai default 1 diperlukan untuk kepatuhan ACID penuh. Anda dapat mencapai kinerja yang lebih baik dengan menetapkan nilai yang berbeda dari 1, tetapi kemudian Anda dapat kehilangan nilai transaksi hingga satu detik dalam kerusakan. Dengan nilai 0, setiap proses mysqld crash dapat menghapus detik terakhir transaksi. Dengan nilai 2, hanya sistem operasi crash atau pemadaman listrik dapat menghapus detik terakhir transaksi. Pemulihan crash InnoDB berfungsi terlepas dari nilainya.

Menurut pendapat saya menggunakan innodb_flush_log_at_trx_commitke 2 seharusnya tidak menjadi masalah. Tapi menggunakan 1 adalah yang paling aman.

Pendapat saya berbeda dari yang lain. innodb_flush_log_at_trx_commit = 0 jika: itu adalah komputer pengembangan atau basis data mini rumah saya di mana tidak ada data sensitif.

innodb_flush_log_at_trx_commit = 2 jika: itu adalah blog / statistik / e-commerce (dengan ~ 100x toko dalam sehari), dll.

innodb_flush_log_at_trx_commit = 1 jika: Anda memiliki banyak pelanggan atau Anda perlu bekerja dengan transaksi uang seperti bank. jadi kali ini Anda harus membagi aliran data antara beberapa server untuk memiliki kecepatan & keamanan.

Saya lebih suka 2, karena memiliki kecepatan tulis ~ 75x lebih cepat dan gagal HANYA jika perangkat keras gagal.

Lagi pula Anda harus tahu apa yang Anda butuhkan lebih banyak kecepatan menulis atau hingga 1 detik informasi?

Saya mencoba menjawab, apa tujuannya innodb_flush_log_at_trx_commit?

InnoDB melakukan sebagian besar operasinya di memori ( InnoDB Buffer Pool). Al data yang dimodifikasi ditulis ke InnoDB transaction log filedan kemudian dibilas (ditulis) ke penyimpanan tahan lama (hard disk).

Untuk keamanan data ( Durability from ACID), InnoDB harus menyimpan data yang dimodifikasi dari setiap transaksi ke dalam penyimpanan permanen. Pada saat yang sama, komit ke disk untuk setiap transaksi adalah proses yang mahal.

Disk I / O adalah proses pemblokiran dan sangat lambat, ini adalah disk yang lambat, selanjutnya akan mengurangi jumlah InnoDB transaction per seconds(Disk throughput).

InnoDB menyediakan, innodb_flush_log_at_trx_commitvariabel untuk mengontrol frekuensi operasi flush ini. Berdasarkan nilai, operasi flush InnoDB berperilaku berbeda.

(Sudah dijelaskan dalam jawaban lain)

0 - Tulis ke file log dan siram ke disk setiap detik (data dalam buffer pool tidak ditulis ke file log - untuk mendapatkan kinerja). 1 - Flush to disk ketika transaksi melakukan - default (Untuk keamanan data - ACID kepatuhan) 2 - menulis ke file log untuk setiap transaksi dan flush to disk setiap detik. (Untuk perolehan kinerja)

Tergantung pada persyaratan aplikasi ( Performance Vs data safety), Anda dapat mengatur variabel ini. Perbedaan antara 0 dan 2 - keduanya akan meningkatkan kinerja, nilai 2 menyimpan data dalam file transaksi dan dapat dipulihkan, jika terjadi kerusakan atau kegagalan, tetapi tidak dalam 0.

Dalam banyak kasus, flush to disk berarti, data ditulis dari InnoDB buffer pool (memory) to Operating systems cachetidak benar-benar ditulis ke disk penyimpanan (penyimpanan permanen). Dalam hal kegagalan, dalam kasus terburuk, Anda dapat kehilangan data hingga satu detik)

Keuntungan kinerja tergantung pada lingkungan dan Anda dapat membandingkan dan mengidentifikasi. Dalam lingkungan replikasi, untuk keamanan dan konsistensi data, atur innodb_flush_log_trx_commit = 1dan sync_binlog=1.

Jika kinerja adalah tujuan utama aplikasi, InnoDB menyediakan variabel untuk mengontrol frekuensi pembilasan log - innodb_flush_log_at_timeout- yang memungkinkan Anda mengatur rentang frekuensi pembilasan log 1 to 2700 seconds, secara default adalah 1.

Ketahuilah, saat Anda meningkatkan interval pembilasan hingga N detik, peningkatan kinerja disertai dengan kompromi dalam keamanan data hingga N detik. Misalnya - jika Anda mengatur pembilasan terjadi setiap 5 detik - gain throughput sangat tinggi, tetapi jika terjadi kegagalan daya atau kerusakan sistem, Anda akan kehilangan data senilai 5 detik.

Artikel ini membahas tentang pembilasan InnoDB dan operasi komit transaksi .

Anda dapat mengubah setelah Anda melakukan mode 2 pada aws rds:

Tidak dapat dimodifikasi dalam beberapa kasus seperti jika Anda memiliki replikasi multi az:

Jika perangkat keras Anda gagal, Anda dapat kehilangan semua data Anda, jadi saya menggunakan param = 2 tanpa khawatir. Pokoknya Anda dapat membagi Anda data sensitif (pesanan, uang virtual, ...) dan reguler (statistik, kereta, ...) antara server 2 db dan menjaganya tetap aman dan cepat. Untuk transaksi antar database, Anda dapat menggunakan http://dev.mysql.com/doc/refman/5.7/id/xa.html