O data = journal é mais seguro para o Ext4 do que para data = ordered?

Question

O modo de diário padrão para Ext4 é data=ordered , que, de acordo com a documentação, significa que

"All data are forced directly out to the main file system prior to its metadata being committed to the journal."

No entanto, há também a opção data=journal , o que significa que

"All data are committed into the journal prior to being written into the main file system. Enabling this mode will disable delayed allocation and O_DIRECT support."

Meu entendimento é que o modo data=journal registrará todos os dados, bem como os metadados, o que, aparentemente, significa que essa é a opção mais segura em termos de integridade e confiabilidade dos dados, embora talvez não tanto pelo desempenho.

Devo ir com essa opção se a confiabilidade é a maior preocupação, mas o desempenho é muito menor? Há alguma limitação em usar essa opção?

Em segundo plano, o sistema em questão está em um no-break e o cache de gravação está desabilitado nas unidades.

    

Answer 1

Sim, data=journal é a maneira mais segura de gravar dados em disco. Como todos os dados e metadados são gravados no diário antes de serem gravados no disco, você sempre pode repetir os trabalhos de E / S interrompidos no caso de uma falha. Também desativa o recurso alocação atrasada , que pode levar à perda de dados .

Os 3 modos são apresentados por ordem de segurança no manual :

1. data = journal
2. data = ordered
3. data = writeback

Há também outra opção que pode lhe interessar:

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

A única ressalva conhecida é que pode se tornar terrivelmente lenta. Você pode reduzir o impacto no desempenho desativando a atualização do tempo de acesso com a opção noatime .

    

Answer 2

Este tópico é super antigo, mas ainda é relevante.

Queríamos mesclar muitas gravações minúsculas em um banco de dados MySQL, executado como uma VM em KVM usando imagens Ceph RBD.

Convidado: 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

O dispositivo '/ dev / sda' (1 TiB) está em um conjunto NVMe codificado para eliminação de compressão, com um dispositivo de diário dedicado relativamente pequeno (128 MiB) em um conjunto NVMe triplo replicado.

Com isto, os comandos que usamos em um ambiente de resgate:

Separe o diário:

tune2fs -O ^has_journal /dev/sda1;

Verifique se há inconsistências no sistema de arquivos:

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

Obter o tamanho do bloco:

tune2fs -l /dev/sda1;

Formate o dispositivo de diário dedicado (AVISO):

O tamanho mínimo do diário deve ser 1024 * tamanho do bloco (usamos 128 MiB para ser seguro)

Defina o tamanho do bloco para corresponder ao de / dev / sda1

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

Anexe o dispositivo de diário dedicado ao sistema de arquivos:

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

Configurações do 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