Ext4 için varsayılan günlük modu data=ordered, belgelere göre

"Tüm veriler, meta verileri dergiye kaydedilmeden önce doğrudan ana dosya sistemine zorlanır."

Ancak, bir data=journalseçenek de var , bu demektir ki

"Tüm veriler ana dosya sistemine yazılmadan önce günlüğe kaydedilmektedir. Bu modun etkinleştirilmesi gecikmiş tahsisi ve O_DIRECT desteğini devre dışı bırakacaktır."

Bunu anlıyorum, data=journalkipin tüm verileri ve meta veriyi günlüğe kaydedeceği, bunun karşısında, bunun performans için çok fazla olmasa da veri bütünlüğü ve güvenilirliği açısından en güvenli seçenek olduğu anlamına geldiği anlaşılıyor.

Güvenilirlik en üst düzeyde endişe duyuyorsa bu performansı kullanmalı mıyım, ancak performans daha az mı? Bu seçeneği kullanmak için herhangi bir uyarı var mı?

Arka plan için, söz konusu sistem bir UPS üzerindedir ve yazma önbelleği sürücülerde devre dışı bırakılmıştır.

Evet, data=journaldiske veri yazmanın en güvenli yoludur. Tüm veriler ve meta veriler diske yazılmadan önce günlüğe yazıldığından, kilitlenme durumunda her zaman kesilen G / Ç işlerini tekrarlayabilirsiniz. Ayrıca , veri kaybına neden olabilecek gecikmeli tahsisat özelliğini de devre dışı bırakır .

3 mod, kılavuzdaki güvenlik sırasına göre sunulmuştur :

1. data = dergi
2. Sıralı veri =
3. Veri = Writeback

İlginizi çekebilecek başka bir seçenek daha var:

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

Bilinen tek uyarı, korkunç derecede yavaşlayabileceğidir. Seçenekle erişim zaman güncellemesini devre dışı bırakarak performans etkisini azaltabilirsiniz noatime.

Bu konu süper eski ama yine de alakalı.

MySQL veritabanında birçok küçük yazıyı birleştirmek istedik, Ceph RBD görüntüleri kullanarak KVM altında VM olarak çalışıyorduk.

Konuk: CentOS 6 VM'nin / etc / fstab:

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

'/ Dev / sda' cihazı (1 TiB), sıkıştırılmış bir silme kodlu NVMe havuzunda, üçlü kopyalanmış bir NVMe havuzunda nispeten küçük (128 MiB) özel bir dergi cihazı ile.

Kurtarma ortamında kullandığımız komutlarla:

Günlüğü çıkarın:

tune2fs -O ^has_journal /dev/sda1;

Dosya sisteminde tutarsızlık olup olmadığını kontrol edin:

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

Blok boyutunu al:

tune2fs -l /dev/sda1;

Özel günlük cihazını biçimlendir (UYARI):

Minimum dergi büyüklüğü 1024 * blok büyüklüğü olmalıdır (güvenli olması için 128 MiB kullanırız)

Blok boyutunu / dev / sda1 ile eşleşecek şekilde ayarlayın

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

Özel günlük cihazını dosya sistemine bağlayın:

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

MySQL ayarları:

[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