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

"Todos os dados são forçados diretamente para o sistema de arquivos principal antes de seus metadados serem confirmados no diário".

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

"Todos os dados são confirmados no diário antes de serem gravados no sistema de arquivos principal. A ativação desse modo desabilitará a alocação atrasada e o suporte ao O_DIRECT."

Meu entendimento disso é que o data=journalmodo registrará no diário todos os dados e metadados, o que, aparentemente, significa que essa é a opção mais segura em termos de integridade e confiabilidade dos dados, embora talvez não seja tanto para desempenho.

Devo escolher esta opção se a confiabilidade é uma das principais preocupações, mas o desempenho é muito menor? Existem advertências para usar esta opção?

Como pano de fundo, o sistema em questão está em um no-break e o cache de gravação está desabilitado nas unidades.

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

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

1. data = diário
2. data = pedido
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 ela pode se tornar terrivelmente lenta. Você pode reduzir o impacto no desempenho desativando a atualização do tempo de acesso com a noatimeopção

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

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

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

O dispositivo '/ dev / sda' (1 TiB) está em um pool NVMe com código de apagamento compactado, com um dispositivo de diário dedicado relativamente pequeno (128 MiB) em um pool NVMe com replicação tripla.

A seguir, os comandos que usamos em um ambiente de resgate:

Desanexe o diário:

tune2fs -O ^has_journal /dev/sda1;

Verifique o sistema de arquivos quanto a inconsistências:

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

Obter tamanho do bloco:

tune2fs -l /dev/sda1;

Formatar dispositivo de diário dedicado (AVISO):

O tamanho mínimo do diário deve ter o tamanho de bloco de 1024 * (usamos 128 MiB para garantir)

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