it-swarm.com.de

Ist data = journal für Ext4 sicherer als data = ordered?

Der Standardjournalmodus für Ext4 ist data=ordered, was laut Dokumentation bedeutet, dass

"Alle Daten werden direkt in das Hauptdateisystem übertragen, bevor ihre Metadaten in das Journal übernommen werden."

Es gibt jedoch auch die data=journal Option, was bedeutet

"Alle Daten werden in das Journal übernommen, bevor sie in das Hauptdateisystem geschrieben werden. Wenn Sie diesen Modus aktivieren, werden die verzögerte Zuordnung und die O_DIRECT-Unterstützung deaktiviert."

Mein Verständnis davon ist, dass die data=journal Im Modus werden alle Daten sowie Metadaten aufgezeichnet, was auf den ersten Blick zu bedeuten scheint, dass dies die sicherste Option in Bezug auf Datenintegrität und Zuverlässigkeit ist, wenn auch möglicherweise nicht so sehr für die Leistung.

Sollte ich mich für diese Option entscheiden, wenn die Zuverlässigkeit von größter Bedeutung ist, die Leistung jedoch viel weniger? Gibt es irgendwelche Einschränkungen bei der Verwendung dieser Option?

Im Hintergrund befindet sich das betreffende System auf einer USV und das Schreib-Caching auf den Laufwerken ist deaktiviert.

37
Tim

Ja, data=journal ist die sicherste Methode zum Schreiben von Daten auf die Festplatte. Da alle Daten und Metadaten vor dem Schreiben auf die Festplatte in das Journal geschrieben werden, können Sie unterbrochene E/A-Jobs im Falle eines Absturzes jederzeit wiedergeben. Außerdem wird die Funktion für die verzögerte Zuweisung deaktiviert, die kann zu Datenverlust führen kann .

Die 3 Modi werden in der Reihenfolge der Sicherheit im Handbuch dargestellt:

  1. daten = Journal
  2. daten = bestellt
  3. daten = Rückschreiben

Es gibt noch eine andere Option, die Sie interessieren könnte:

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

Die einzige bekannte Einschränkung ist, dass es furchtbar langsam werden kann. Sie können die Auswirkungen auf die Leistung verringern, indem Sie die Aktualisierung der Zugriffszeit mit der Option noatime deaktivieren.

31
Coren

Dieser Thread ist super alt, aber immer noch relevant.

Wir wollten viele kleine Schreibvorgänge in einer MySQL-Datenbank zusammenführen, die als VM unter KVM mit Ceph RBD-Images) ausgeführt werden.

Gast: CentOS 6 VMs/etc/fstab:

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

Das '/ dev/sda'-Gerät (1 TiB) befindet sich in einem komprimierten löschcodierten NVMe-Pool mit einem relativ kleinen (128 MiB) dedizierten Journalgerät in einem dreifach replizierten NVMe-Pool.

Hiermit die Befehle, die wir in einer Rettungsumgebung verwendet haben:

Nehmen Sie das Tagebuch ab:

tune2fs -O ^has_journal /dev/sda1;

Überprüfen Sie das Dateisystem auf Inkonsistenzen:

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

Blockgröße ermitteln:

tune2fs -l /dev/sda1;

Formatieren Sie ein dediziertes Journalgerät (WARNUNG):

Die minimale Journalgröße sollte 1024 * Blockgröße betragen (wir verwenden 128 MiB, um sicher zu gehen).

Stellen Sie die Blockgröße so ein, dass sie der von/dev/sda1 entspricht

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

Schließen Sie das dedizierte Journalgerät an das Dateisystem an:

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

MySQL-Einstellungen:

[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
4
David Herselman