Mode jurnal default untuk Ext4 adalah data=ordered, yang, menurut dokumentasi, artinya

"Semua data dipaksa langsung ke sistem file utama sebelum metadata-nya diberikan ke jurnal."

Namun, ada juga data=journalopsi yang artinya

"Semua data dimasukkan ke dalam jurnal sebelum ditulis ke dalam sistem file utama. Mengaktifkan mode ini akan menonaktifkan alokasi yang tertunda dan dukungan O_DIRECT."

Pemahaman saya tentang hal ini adalah bahwa data=journalmode ini akan membuat jurnal semua data dan juga metadata, yang, tampaknya, berarti bahwa ini adalah opsi paling aman dalam hal integritas dan keandalan data, meskipun mungkin tidak terlalu banyak untuk kinerja.

Haruskah saya menggunakan opsi ini jika keandalan merupakan masalah utama, tetapi kinerjanya jauh lebih buruk? Apakah ada peringatan untuk menggunakan opsi ini?

Untuk latar belakang, sistem yang dimaksud adalah pada UPS dan caching tulis dinonaktifkan pada drive.

Ya, data=journaladalah cara paling aman untuk menulis data ke disk. Karena semua data dan metadata ditulis ke jurnal sebelum ditulis ke disk, Anda selalu dapat memutar ulang pekerjaan I / O yang terputus jika terjadi kerusakan. Ini juga menonaktifkan fitur alokasi tertunda , yang dapat menyebabkan hilangnya data .

3 mode disajikan dalam urutan keamanan dalam manual :

1. data = jurnal
2. data = dipesan
3. data = writeback

Ada juga opsi lain yang mungkin menarik bagi Anda:

commit=nrsec    (*) Ext4 can be told to sync all its data and metadata
                    every 'nrsec' seconds. The default value is 5 seconds.

Satu-satunya peringatan yang diketahui adalah dapat menjadi sangat lambat. Anda dapat mengurangi dampak kinerja dengan menonaktifkan pembaruan waktu akses dengan noatimeopsi.

Utas ini sangat tua, tetapi masih relevan.

Kami ingin menggabungkan banyak tulisan kecil di database MySQL, berjalan sebagai VM di bawah KVM menggunakan gambar Ceph RBD.

Tamu: CentOS 6 VM / etc / fstab:

/dev/sda1               /                       ext4    defaults,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,noatime,nodiratime,commit=60,data=journal,discard 1 1

Perangkat '/ dev / sda' (1 TiB) berada dalam kolam NVMe yang dikode kode penghapusan, dengan perangkat jurnal khusus yang relatif kecil (128 MiB) dalam kolam NVMe yang direplikasi tiga kali.

Dengan ini perintah yang kami gunakan di lingkungan penyelamatan:

Lepaskan jurnal:

tune2fs -O ^has_journal /dev/sda1;

Periksa sistem file untuk inkonsistensi:

fsck.ext4 -f -C 0 /dev/sda1;

Mendapatkan ukuran blok:

tune2fs -l /dev/sda1;

Memformat perangkat jurnal khusus (PERINGATAN):

Ukuran jurnal minimum harus 1024 * ukuran blok (kami menggunakan 128 MiB agar aman)

Setel ukuran blok agar sesuai dengan / dev / sda1

mke2fs -O journal_dev -L root_journal /dev/sdb1 -b 4096;

Lampirkan perangkat jurnal khusus ke sistem file:

tune2fs -j -J device=LABEL=root_journal /dev/sda1;

Pengaturan MySQL:

[mysqld]
innodb_old_blocks_time = 1000           # Prevent buffer pool pollution. Default as of MySQL 5.6
innodb_buffer_pool_size = 24576M        # MySQL Cache
innodb_log_buffer_size = 128M           # 25% of log_file_size
innodb_log_file_size = 512M             # 25% of the buffer_pool (no, not really)
query_cache_size = 128M                 # Query Cache
table_cache = 512                       # Make it large enough for: show global status like 'open%';
#mysqltuner.pl:
innodb_flush_method = O_DSYNC           # Don't validate writes. MySQL 5.6+ should use O_DIRECT
innodb_flush_log_at_trx_commit = 2      # Flush MySQL transactions to operating system cache
join_buffer_size = 256K
thread_cache_size = 4
innodb_buffer_pool_instances = 16
skip-innodb_doublewrite