복원력과 성능 사이에는 항상 상충 관계가 있습니다.
ext4에서 MySQL을 사용하면 barriers = 1 기본값으로 인해 속도가 느려지지만 첫 번째 조치는 저널링을 비활성화하거나 data = writeback을 켜는 것이 아닙니다.
첫째, 복원력이 매우 중요한 경우 배터리 지원 RAID가 그만한 가치가 있습니다.
내가 선택한 배터리 옵션, 특히 비 배터리 백업 RAID에서 선택한 마운트 옵션은 다음과 같습니다.
/dev/mapper/vg-mysql--data /var/lib/mysql/data ext4 defaults,noatime,nodiratime,barrier=1,data=ordered 0 0
파일 시스템이 손상되어 "크래시 및 저널 복구 후 파일에 오래된 데이터가 man mount표시됨 "(인용)에서 파일 데이터가 손상 될 위험이 없으므로 의도적으로 data = writeback을 사용하지 않습니다 .
I / O 관련 설정에 대한 완벽한 복원력을위한 my.cnf의 이상적인 구성은 다음과 같습니다.
[mysqld]
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
성능을 높이기 위해 다음과 같은 일련의 절충안을 선택했습니다.
sync_binlog = 0: 이것은 완전한 복원력에서 벗어나는 최초의 MySQL 구성입니다. 그 이유는 특히 binlog_format=row(Jira에게 불행히도 필요한 경우) 성능이 크게 향상 되었기 때문입니다 . binlog가 전원 손실 시나리오에 의해 손상되면 다른 복제본에서 이진 복사를 수행하는 클러스터에서 충분한 MySQL 복제본을 사용하고 있습니다.innodb_flush_log_at_trx_commit = 2: 완전한 ACID 준수를 위해서는 값 1이 필요하지만 값 2는 "커밋 할 때마다 파일에 로그 버퍼가 기록되지만 디스크로 플러시 작업은 수행되지 않습니다. 로그 파일은 값이 2 일 때도 초당 1 회 발생합니다. 프로세스 스케줄링 문제로 인해 초당 1 회 플러싱이 초당 100 % 보장되는 것은 아닙니다. " (MySQL 문서에서 인용)- 사용할 마운트 옵션을 업데이트하십시오
data=writeback. 이것이 루트 파일 시스템 인 경우 커널 명령 행 옵션도 전달해야합니다. coderwall 에서 몇 가지 단계를 함께 수행했습니다 .
- 의 다양한 값을 테스트하십시오
innodb_flush_method. O_DIRECT는 일부 워크로드에서 성능을 향상시키는 것으로 나타 났지만 이것이 사용자 환경에서 작동한다는 것은 아닙니다.
- 이 경우 당신은 또한 증가 할 것이다, SSD를 업그레이드
innodb_io_capacity등 및 조정 설정 innodb_adaptive_flushing, innodb_read_io_threads, innodb_write_io_threads, innodb_purge_threads, 기타 가능한 설정.