Deixe-me começar por admitir que sou muito ignorante do funcionamento interno dos discos rígidos. Então, quando li o manual da variável innodb_flush_method , isso me confundiu. Posso obter uma explicação nos termos do leigo sobre a diferença em O_DSYNC e O_DIRECT e como saber se é um problema de desempenho em um servidor de banco de dados.

Algumas estatísticas na minha configuração: Mac OSX 10.6 (kernel de 32 bits, já que a arquitetura está desatualizada) executando o MySQL 5.1.49-64bit (esperando que isso me permita usar a memória). 8 GB de RAM, ~ 6 GB de dados / índices innodb.

mysql innodb

— Derek Downey
fonte

Não sei se o Mac OS X suporta uma opção de E / S direta adequada - eu não achava que sim. Você é a segunda pessoa que vi hoje ficar confusa com essa página de manual. Eu tenho um bug aberto aqui: bugs.mysql.com/bug.php?id=54306

— Morgan Tocker

Aqui está uma explicação sobre como fdatasync()funciona vs como fsync()funciona

fdatasync()libera todos os buffers de dados de um arquivo no disco (antes que a chamada do sistema retorne). É semelhante, fsync()mas não é necessário, para atualizar os metadados, como o tempo de acesso. Os aplicativos que acessam bancos de dados ou arquivos de log geralmente escrevem um pequeno fragmento de dados (por exemplo, uma linha em um arquivo de log) e depois chamam fsync()imediatamente para garantir que os dados gravados sejam fisicamente armazenados no disco rígido. Infelizmente, fsync()sempre iniciará duas operações de gravação

uma operação de gravação para os dados recém-gravados
uma operação de gravação para atualizar o tempo de modificação armazenado no inode

Se o tempo de modificação não fizer parte do conceito de transação, fdatasync()poderá ser usado para evitar operações desnecessárias de gravação no disco do inode.

Em inglês, O_DSYNCé mais rápido do que O_DIRECTdesde que O_DIRECTchama fsync()duas vezes (uma para logs e outra para dados) e fsync()verifica a gravação de dados por meio de duas operações de gravação. Usando O_DSYNCchamadas fdatsync()e fsync(). Você pode pensar fdatasync()em fazer um assíncrono fsync()(não verificando dados).

Observando os números, há O_DSYNCquatro operações de gravação, duas das quais são verificadas, enquanto fsync()quatro operações de gravação, sendo todas verificadas posteriormente.

CONCLUSÃO

O_DSYNC
- mais rápido que O_DIRECT
- Os dados podem ou não ser consistentes devido à latência ou a uma falha total
O_DIRECT
- mais estável
- dados consistentes
- naturalmente mais lento

Espero que essa resposta ajude e espero que não tenha piorado as coisas para você.

— RolandoMySQLDBA
fonte

Vale ressaltar: O_DIRECT é usado apenas nos arquivos de espaço de tabela, não nos logs. Além disso - se o O_DIRECT será útil ou não, depende do hardware. Vinculei a um bug de documentação aberta como um comentário à pergunta do autor.

— Morgan Tocker 21/03

Obrigado por esclarecer isso, Morgan. Eu vou corrigir isso.

— RolandoMySQLDBA 21/03

O_DSYNC é gravação síncrona, como você pode concluir que é mais rápido que assíncrono + fsync?

— noonex 8/09/14

@noonex fdatasync () é síncrono para seus dados, não para seus metadados. De acordo com informit.com/articles/article.aspx?p=23618&seqNum=5 ,

This means that in principal, fdatasync can execute faster than fsync because it needs to force only one disk write instead of two. However, in current versions of Linux, these two system calls actually do the same thing, both updating the file's modification time.

na época em que escrevi meu post há 3,5 anos, isso era verdade, especialmente nas versões mais antigas do Linux.

— RolandoMySQLDBA

@noonex De acordo com en.wikipedia.org/wiki/Sync_(Unix) ,

The related system call fsync() commits just the buffered data relating to a specified file descriptor. fdatasync() is also available to write out just the changes made to the data in the file, and not necessarily the file's related metadata.

(esse wiki foi atualizado pela última vez em 28 de julho de 2014).

— RolandoMySQLDBA

Esclarecimento sobre a variável innodb_flush_method do MySQL

CONCLUSÃO