하드 디스크의 내부 작동에 대해 무지하다는 것을 인정하면서 시작하겠습니다. 그래서 innodb_flush_method 변수에 대한 매뉴얼을 읽으면 혼란 스럽습니다. O_DSYNC와 O_DIRECT의 차이점과 데이터베이스 서버에서 성능 문제인지 확인하는 방법에 대한 일반인의 용어로 설명을 얻을 수 있습니까?

내 설정에 대한 몇 가지 통계 : Mac OSX 10.6 (아키텍처가 오래되었으므로 32 비트 커널) 메모리를 사용할 수있는 MySQL 5.1.49-64bit를 실행합니다. 8GB RAM, ~ 6GB의 innodb 데이터 / 인덱스

여기에 방법에 대한 설명입니다 fdatasync()방법에 대 작품 fsync()작품

fdatasync()시스템 호출이 리턴되기 전에 파일의 모든 데이터 버퍼를 디스크로 플러시합니다. fsync()액세스 시간과 같은 메타 데이터를 업데이트 할 필요는 없지만 비슷 합니다. 데이터베이스 또는 로그 파일에 액세스하는 응용 프로그램은 종종 작은 데이터 조각 (예 : 로그 파일의 한 줄)을 fsync()쓴 다음 기록 된 데이터가 실제로 하드 디스크에 저장되도록하기 위해 즉시 호출 합니다. 불행히도, fsync()항상 두 번의 쓰기 작업을 시작합니다

• 새로 작성된 데이터에 대한 한 번의 쓰기 조작
• inode에 저장된 수정 시간을 업데이트하기위한 한 번의 쓰기 작업

수정 시간이 트랜잭션 개념의 일부가 아닌 경우 fdatasync()불필요한 inode 디스크 쓰기 작업을 피하기 위해 사용할 수 있습니다.

영어로, O_DSYNC빠르게보다 O_DIRECT이후 O_DIRECT전화 fsync()두 번 (데이터 로그에 대한 하나 하나)와 fsync()두 개의 쓰기 작업을 통해 검증하고 데이터 쓰기. O_DSYNC통화 사용 fdatsync()및 fsync(). 데이터를 검증하지 않는 fdatasync()비동기식으로 생각할 수 있습니다 fsync().

숫자를 살펴보면 O_DSYNC4 개의 쓰기 작업이 수행되고 그 중 2 개는 확인되며 fsync()4 개의 쓰기 작업은 나중에 확인됩니다.

결론

• O_DSYNC
  • 보다 빠른 O_DIRECT
  • 대기 시간 또는 명백한 충돌로 인해 데이터가 일관적일 수 있습니다.
• O_DIRECT
  • 더 안정적인
  • 데이터 일관성
  • 당연히 느리다

이 답변이 도움이 되었기를 바랍니다. 더 나쁘게 만들지 않기를 바랍니다.