Data = journal est-il plus sûr pour Ext4 que data = commandé?
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 vers le système de fichiers principal avant que ses métadonnées ne soient enregistrées dans le journal."
Cependant, il y a aussi le data=journal option, ce qui signifie que
"Toutes les données sont enregistré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 le support O_DIRECT."
Je crois comprendre que le data=journal mode va journaliser toutes les données ainsi que les métadonnées, ce qui, à première vue, semble signifier que c'est l'option la plus sûre en termes d'intégrité et de fiabilité des données, mais peut-être pas tant pour les performances.
Dois-je choisir cette option si la fiabilité est de la plus haute importance, mais les performances beaucoup moins? Y a-t-il des mises en garde à utiliser cette option?
Pour le fond, le système en question est sur un onduleur et la mise en cache d'écriture est désactivée sur les lecteurs.
Oui, data=journal 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 panne. Il désactive également la fonction d'allocation retardée , qui peut entraîner une perte de données .
Les 3 modes sont présentés par ordre de sécurité dans le manuel :
- data = journal
- données = commandées
- data = écriture différée
Il existe également une autre option qui pourrait 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'elle peut devenir terriblement lente. Vous pouvez réduire l'impact sur les performances en désactivant la mise à jour du temps d'accès avec l'option noatime.
Ce fil est super ancien, mais toujours d'actualité.
Nous voulions fusionner de nombreuses petites écritures sur une base de données MySQL, fonctionnant en tant que VM under KVM using des images Ceph RBD).
Invité: 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
Le périphérique '/ dev/sda' (1 TiB) se trouve dans un pool NVMe codé à effacement compressé, avec un périphérique de journal dédié relativement petit (128 MiB) dans un pool NVMe triple répliqué.
Ci-joint les commandes que nous avons utilisées dans un environnement de sauvetage:
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é (AVERTISSEMENT):
La taille minimale du journal doit être de 1024 * taille de bloc (nous utilisons 128 Mo pour être sûr)
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;
Connectez 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