Est-ce que data = journal est plus sûr pour Ext4 par opposition à data = ordonné?

36

Le mode de journal par défaut pour Ext4 est data=ordered, ce qui, selon la documentation, signifie que

"Toutes les données sont forcées directement dans le système de fichiers principal avant que ses métadonnées soient envoyées au journal."

Cependant, il y a aussi l' data=journaloption, ce qui signifie que

"Toutes les données sont validées dans le journal avant d'être écrites dans le système de fichiers principal. L'activation de ce mode désactivera l'allocation différée et la prise en charge de O_DIRECT."

D'après ce que j'ai compris, le data=journalmode journalisera toutes les données ainsi que les métadonnées, ce qui, à première vue, semble vouloir dire que c'est l'option la plus sûre en termes d'intégrité et de fiabilité des données, mais peut-être pas autant pour la performance.

Devrais-je choisir cette option si la fiabilité est une préoccupation majeure, mais les performances beaucoup moins? Y at-il des mises en garde à utiliser cette option?

Pour l’arrière-plan, le système en question est sur un onduleur et la mise en cache en écriture est désactivée sur les disques.

Tim
la source

Réponses:

30

Oui, data=journalc’est le moyen le plus sûr d’écrire des données sur le disque. Étant donné que toutes les données et métadonnées sont écrites dans le journal avant d'être écrites sur le disque, vous pouvez toujours relire les travaux d'E / S interrompus en cas de blocage. Cela désactive également la fonction d' allocation différée , ce qui peut entraîner une perte de données .

Les 3 modes sont présentés par ordre de sécurité dans le manuel :

  1. données = journal
  2. données = commandé
  3. data = writeback

Il y a aussi une autre option qui peut vous intéresser:

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

La seule mise en garde connue est qu'il peut devenir terriblement lent. Vous pouvez réduire l'impact sur les performances en désactivant la mise à jour du temps d'accès avec l' noatimeoption.

Coren
la source
2
Vous indiquez que désactiver l’allocation différée est plus sûr. Cependant, je ne trouve pas de cas où data=journalle résultat sera plus sûr que data=ordered+ nodelalloc. Avez-vous une?
Jérôme Pouiller
Ce n'est pas désactiver l'allocation retardée qui peut conduire à une perte de données.
ctrl-alt-delor
3

Ce fil est super vieux, mais toujours pertinent.

Nous voulions fusionner de nombreuses écritures minuscules sur une base de données MySQL, s'exécutant en tant que machine virtuelle sous KVM à l'aide d'images Ceph RBD.

Invité: / etc / fstab de CentOS 6 VM:

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

Le périphérique '/ dev / sda' (1 TiB) se trouve dans un pool NVMe codé par effacement compressé, avec un périphérique de journal dédié relativement petit (128 Mio) dans un pool NVMe répliqué à trois.

Voici les commandes que nous avons utilisées dans un environnement de secours:

Détachez le journal:

tune2fs -O ^has_journal /dev/sda1;

Vérifiez les incohérences dans le système de fichiers:

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

Obtenir la taille du bloc:

tune2fs -l /dev/sda1;

Formater le périphérique de journal dédié (ATTENTION):

La taille minimale du journal doit être de 1024 * taille de bloc (nous utilisons 128 Mo pour plus de sécurité)

Définissez la taille du bloc pour qu'elle corresponde à celle de / dev / sda1

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

Reliez le périphérique de journal dédié au système de fichiers:

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

Paramètres 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
David Herselman
la source
2
alors? Qu'est ce qui a changé?
Sivann le