머리말
MySQL 마스터-슬레이브 복제를 구성 할 때 필요한 구성 매개 변수 외에 다음 두 매개 변수 (innodb_flush_log_at_trx_commit
및 sync_binlog) 가 종종 구성 됩니다.이 매개 변수의 역할을 살펴 보겠습니다.
innodb_flush_log_at_trx_commit
트랜잭션을 커밋 할 때 리두 로그를 디스크에 기록합니다. 소위 리두 로그는 데이터에 대한 변경 사항을 기록하는 것입니다. 예를 들어 이름 필드의 값을 "id = 10"으로 변경하면 이것은 로그입니다. 트랜잭션을 커밋하려면 특정 전략에 따라 리두 로그 버퍼에서 디스크 파일로 리두 로그를 플러시합니다. 이때이 전략은 innodb_flush_log_at_trx_commit을 통해 구성되며 몇 가지 옵션이 있습니다.
값은 0 : 트랜잭션이 커밋 될 때 리두 로그 버퍼의 데이터는 즉시 디스크 파일로 플러시되지 않지만 InnoDB의 메인 스레드는 매초마다 디스크로 플러시됩니다. 이때 트랜잭션을 커밋 할 수 있으며 결과적으로 mysql이 다운되고 메모리의 모든 데이터가 손실됩니다.
값은 1 : 트랜잭션을 커밋 할 때 메모리에서 디스크 파일로 리두 로그를 플러시해야합니다. 트랜잭션이 성공적으로 커밋되면 리두 로그가 디스크에 있어야합니다. 운영 체제의 "지연된 쓰기"기능으로 인해 현재 플래시는 운영 체제의 버퍼에만 기록되므로 동기화 작업을 통해 하드 디스크에 유지되어야합니다.
값 2 : 트랜잭션을 커밋 할 때 디스크 파일을 직접 입력하는 대신 디스크 파일에 해당하는 os 캐시 캐시에 다시 실행 로그를 작성합니다. os 캐시의 데이터를 디스크 파일에 쓰는 데 1 초가 걸릴 수 있습니다.
실제로 1 개만 트랜잭션의 내구성을 보장 할 수 있지만 새로 고침 작업 fsync ()가 차단되고 완료 될 때까지 반환되지 않기 때문에 디스크에 쓰는 속도가 매우 느리다는 것을 알 수 있습니다. MySQL의 성능은 명백히 저하 될 것입니다. 트랜잭션 손실에 신경 쓰지 않으면 0과 2가 더 높은 성능을 얻을 수 있습니다.
# 查询
select @@innodb_flush_log_at_trx_commit;
sync_binlog
이 매개 변수는 디스크에 바이너리 로그를 쓰는 프로세스를 제어합니다.
이 매개 변수의 유효한 값은 0, 1, N입니다.
0：默认值。事务提交后，将二进制日志从缓冲写入磁盘，但是不进行刷新操作（fsync()），此时只是写入了操作系统缓冲，若操作系统宕机则会丢失部分二进制日志。
1：事务提交后，将二进制文件写入磁盘并立即执行刷新操作，相当于是同步写入磁盘，不经过操作系统的缓存。
N：每写N次操作系统缓冲就执行一次刷新操作。
이 매개 변수를 1보다 큰 값으로 설정하면 데이터베이스 성능이 향상되지만 데이터 손실 위험도 동반됩니다.
바이너리 로그 파일에는 데이터 복구가 포함되며 마스터와 슬레이브 간의 최대 일관성을 얻으려면이 매개 변수를 1로 설정해야하지만 특정 성능 손실도 발생합니다.