Domyślnym trybem dziennika dla Ext4 jest data=ordered, co zgodnie z dokumentacją oznacza

„Wszystkie dane są wymuszane bezpośrednio do głównego systemu plików, zanim metadane zostaną przesłane do dziennika”.

Istnieje jednak również data=journalopcja, co oznacza, że

„Wszystkie dane są zapisywane w dzienniku przed zapisaniem w głównym systemie plików. Włączenie tego trybu spowoduje wyłączenie opóźnionego przydzielania i obsługi O_DIRECT.”

Rozumiem to, że data=journaltryb rejestruje wszystkie dane, a także metadane, co na pierwszy rzut oka wydaje się oznaczać, że jest to najbezpieczniejsza opcja pod względem integralności i niezawodności danych, choć może nie tak bardzo pod względem wydajności.

Czy powinienem wybrać tę opcję, jeśli niezawodność jest sprawą najwyższej wagi, ale wydajność jest znacznie mniejsza? Czy są jakieś zastrzeżenia dotyczące korzystania z tej opcji?

W tle omawiany system znajduje się na zasilaczu UPS, a buforowanie zapisu jest wyłączone na dyskach.

Tak, data=journalto najbezpieczniejszy sposób zapisywania danych na dysku. Ponieważ wszystkie dane i metadane są zapisywane w dzienniku przed zapisaniem na dysk, w przypadku awarii zawsze można odtworzyć przerwane zadania we / wy. Wyłącza również funkcję opóźnionego przydzielania , co może prowadzić do utraty danych .

3 tryby są przedstawione w instrukcji bezpieczeństwa w kolejności :

1. data = dziennik
2. dane = zamówione
3. data = zapis

Istnieje również inna opcja, która może Cię zainteresować:

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

Jedynym znanym zastrzeżeniem jest to, że może stać się strasznie wolne. Możesz zmniejszyć wpływ na wydajność, wyłączając aktualizację czasu dostępu za pomocą tej noatimeopcji.

Ten wątek jest bardzo stary, ale nadal aktualny.

Chcieliśmy scalić wiele drobnych zapisów w bazie danych MySQL, działającej jako maszyna wirtualna pod KVM przy użyciu obrazów Ceph RBD.

Gość: VM CentOS 6 / etc / fstab:

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

Urządzenie „/ dev / sda” (1 TiB) znajduje się w skompresowanej puli NVMe z kodem wymazania, z relatywnie małym (128 MiB) dedykowanym urządzeniem dziennika w potrójnej replikowanej puli NVMe.

Oto polecenia, których użyliśmy w środowisku ratunkowym:

Odłącz dziennik:

tune2fs -O ^has_journal /dev/sda1;

Sprawdź system plików pod kątem niespójności:

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

Uzyskaj rozmiar bloku:

tune2fs -l /dev/sda1;

Sformatuj dedykowane urządzenie dziennika (OSTRZEŻENIE):

Minimalny rozmiar dziennika powinien wynosić 1024 * rozmiar bloku (dla bezpieczeństwa używamy 128 MiB)

Ustaw rozmiar bloku tak, aby pasował do rozmiaru / dev / sda1

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

Podłącz dedykowane urządzenie dziennika do systemu plików:

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

Ustawienia 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