MySql에서 바이너리 로그를 작성하는 과정을 완전히 마스터하세요.

이 기사는 "sync_binlog", "binlog_cache_size" 및 "max_binlog_cache_size"와 관련된 문제를 포함하여 mysql에서 바이너리 로그를 작성하는 과정에 대한 관련 지식을 제공합니다.

바이너리 로그 작성 과정

먼저 공식 문서의 sync_binlog 구성에 대한 설명을 살펴보겠습니다.

sync_binlog

명령줄 형식	--sync-binlog=#
시스템 변수	로그
영향 범위	글로벌
Dynamic	예
SET_VAR 프롬프트 적용	No
Type	Integer
기본값	1
최소값	0
최대값	2^32=4294967295

MySQL 서버가 바이너리 로그를 디스크에 동기화하는 빈도를 제어합니다.

• sync_binlog=0: MySQL 서버가 바이너리 로그를 디스크에 동기화하지 못하도록 비활성화합니다. 대신, MySQL 서버는 다른 파일과 마찬가지로 운영 체제를 사용하여 때때로 바이너리 로그를 디스크에 플러시합니다. 이 설정은 최상의 성능을 제공하지만 정전이나 운영 체제 충돌이 발생하는 경우 서버에 아직 플러시되지 않은 커밋된 트랜잭션이 있을 수 있습니다.

• sync_binlog=1: 트랜잭션을 커밋하기 전에 디스크 동기화에 대한 바이너리 로그를 활성화합니다. 이는 가장 안전한 설정이지만 디스크 쓰기 증가로 인해 성능에 부정적인 영향을 미칠 수 있습니다. 정전이나 운영 체제 충돌이 발생하는 경우 바이너리 로그에서 손실된 트랜잭션은 준비된 상태에만 있습니다. 이를 통해 정기적인 자동 복구를 통해 트랜잭션을 롤백할 수 있으므로 바이너리 로그에서 트랜잭션이 손실되지 않도록 보장됩니다.

• sync_binlog=N(0 또는 1 이외의 값): N개의 바이너리 로그 제출 그룹이 수집된 후 바이너리 로그가 디스크에 동기화됩니다. 정전이나 운영 체제 충돌이 발생하는 경우 서버에는 아직 바이너리 로그에 기록되지 않은 커밋된 트랜잭션이 있을 수 있습니다. 이 설정은 디스크 쓰기 증가로 인해 성능에 부정적인 영향을 미칠 수 있습니다. 값이 높을수록 성능은 향상되지만 데이터 손실 위험이 높아집니다.

InnoDB트랜잭션에 사용되는 복제 설정에서 최대한의 내구성과 일관성을 얻으려면 다음 설정을 사용하십시오. InnoDB为了在与事务一起使用 的复制设置中获得最大可能的持久性和一致性，请使用以下设置：

• sync_binlog=1.
• innodb_flush_log_at_trx_commit=1.

警告

许多操作系统和一些磁盘硬件欺骗了刷新到磁盘操作。他们可能会告诉 mysqld已经发生了刷新，即使它还没有发生。在这种情况下，即使使用推荐的设置也无法保证事务的持久性，在最坏的情况下，断电可能会损坏InnoDB

sync_binlog=1.

innodb_flush_log_at_trx_commit=1

경고
• 많은 운영 체제와 일부 디스크 하드웨어는 디스크 플러시 작업을 속이고 있습니다. 새로 고침이 아직 발생하지 않았음에도 불구하고 새로 고침이 발생했음을 mysqld에 알릴 수 있습니다. 이 경우 권장 설정으로도 트랜잭션 내구성이 보장되지 않으며, 최악의 경우 정전으로 인해 InnoDB 데이터가 손상될 수 있습니다. SCSI 디스크 컨트롤러 또는 디스크 자체에서 배터리 지원 디스크 캐시를 사용하면 파일 새로 고침 속도가 빨라지고 작업이 더욱 안전해집니다. 하드웨어 캐시에서 디스크 쓰기 캐싱을 비활성화해 볼 수도 있습니다.
• 요약

sync_binlog 설정 유형은 unsigned Integer입니다.

일반적으로 0으로 설정되지 않습니다. 0은 시스템 작동 및 불규칙한 fsync에 따라 다릅니다. 정전이나 시스템 충돌이 발생할 때 더 위험합니다. 트랜잭션이 제출되었지만 바이너리 로그가 누락되었습니다.

1로 설정하고, 최대한의 내구성과 일관성을 얻고, 후속 마스터-슬레이브 복제 및 복구를 보장하는 것이 더 안전합니다. 그러나 이는 성능에 해로우며 비즈니스에서 요구하는 IOPS가 높지 않은 경우 설정할 수 있습니다.

1보다 큰 값을 설정하는 목적은 성능을 향상시키기 위한 것입니다. 단순히 트랜잭션을 커밋하는 것이 아니라 일괄 플러싱에 해당하는 현명한 방법이지만 정전이나 시스템 충돌이 발생하면 바이너리 로그에는 더 많은 내용이 누락됩니다. 디스크 자체가 배터리 지원 디스크 캐시를 사용하는 것이 더 안전할 것입니다. 따라서 비즈니스에서 요구하는 IOPS가 상대적으로 높을 때 설정할 수 있으나, 일반적으로 너무 크게 설정하지 않고 [100, 1000] 범위 내에서 설정하면 됩니다. 트랜잭션이 실행될 때 바이너리 로그의 캐시 관련 구성을 계속 살펴보겠습니다. 명령 형식--binlog-cache-size=#시스템 변수binlog_cache_sizerangeGolbalDynamic예SET_VAR 프롬프트 적용NoTypeInteger기본값 32768최소값4096최대값( 64- 비트 플랫폼)2^64=18446744073709547520max(32비트 플랫폼)2^32=4294967295

또한 sync_binlog=0이라는 설명을 통해 트랜잭션이 제출되면 즉시 fsync하지는 않지만 실제로 파일 시스템의 페이지 캐시에 기록되었음을 대략적으로 느낄 수 있습니다. mysql이 트랜잭션에 있습니다. 실행 시 트랜잭션에서 생성된 바이너리 로그를 캐시하는 캐시도 있습니다.	binlog_cache_size

🎜🎜🎜블록 크기🎜🎜4096🎜 🎜 🎜🎜

트랜잭션 중 바이너리 로그 변경 사항을 보관할 메모리 버퍼의 크기입니다. 값은 4096의 배수여야 합니다.

서버에서 바이너리 로깅이 활성화되면(log_bin 시스템 변수가 ON으로 설정됨) 서버가 트랜잭션 저장 엔진을 지원하는 경우 각 클라이언트에 바이너리 로그 캐시가 할당됩니다. 트랜잭션 데이터가 메모리 버퍼의 공간을 초과하는 경우 초과 데이터는 임시 파일에 저장됩니다. 서버에서 바이너리 로그 암호화가 활성화되면 메모리 버퍼는 암호화되지 않지만 (MySQL 8.0.17부터) 바이너리 로그 캐시를 보관하는 데 사용되는 모든 임시 파일은 암호화됩니다. 각 트랜잭션이 커밋된 후 메모리 버퍼를 지우고 임시 파일(사용된 경우)을 자르면 바이너리 로그 캐시가 재설정됩니다.

대규모 트랜잭션을 자주 사용하는 경우 임시 파일을 작성할 필요성을 줄이거나 제거하여 성능 향상을 위해 이 캐시 크기를 늘릴 수 있습니다. Binlog_cache_use(서비스 상태 변수 - 바이너리 로그 캐시를 사용한 트랜잭션 수) 및 Binlog_cache_disk_use(서비스 상태 변수 - 임시 바이너리 로그 캐시를 사용하지만 binlog_cache_size 값을 초과하고 임시 파일을 사용하여 트랜잭션 문을 저장하는 트랜잭션 수) 상태 변수 이 변수 크기를 조정하는 데 사용할 수 있습니다. 5.4.4절. “바이너리 로그”를 참조하십시오.

binlog_cache_size트랜잭션 캐시의 크기만 설정합니다. 명령문 캐시의 크기는 binlog_stmt_cache_size 시스템 변수에 의해 제어됩니다.

Summary

• binlog_cache_size 설정 유형은 unsigned Integer입니다.
• 각 트랜잭션 중에 바이너리 로그를 캐시하는 데 사용되는 크기를 나타내는 데 사용됩니다. 기본값은 32k이고 4096의 배수여야 합니다. 이 값을 초과하면 임시 파일 저장소가 사용됩니다.
• 비즈니스에서는 대규모 거래를 사용하지 않도록 노력하세요. 거래 규모가 너무 큰 경우 합리적인지 여부를 고려해야 합니다. 일반적으로 binlog_cache_size를 수정할 필요는 없으며 32k이면 충분합니다.
• binlog_cache_size가 부족할 경우 임시 파일을 사용하여 저장하게 되지만, max_binlog_cache_size=binlog_cache_size로 설정하면 임시 파일을 사용하지 않게 됩니다. 이에 대해서는 아래에서 소개하겠습니다.

max_binlog_cache_size

명령 형식	--max-binlog-cache-size=#
시스템 변수	max_binlog_cache_size
range	Golbal
Dynamic	Yes
SET_VAR 프롬프트 적용	No
Type	Integer
기본값	2^64=1 8 446744073709547520
최소	4096
최대	2^64=18446744073709547520
블록 크기	4096

트랜잭션에 이 바이트 이상의 메모리가 필요한 경우 서버는 'max_binlog_cache_size' 바이트 이상의 저장 오류가 필요한 다중 문 트랜잭션을 생성합니다. 최소값은 4096입니다. 가능한 최대 값은 16EiB(엑비바이트)입니다. 최대 권장 값은 4GB입니다. 이는 MySQL이 현재 4GB보다 큰 바이너리 로그 위치를 처리할 수 없기 때문입니다. 값은 4096의 배수여야 합니다.

max_binlog_cache_size는 트랜잭션 캐시의 크기만 설정합니다. 명령문 캐시의 상한은 max_binlog_stmt_cache_size 시스템 변수에 의해 제어됩니다. max_binlog_cache_size仅设置事务缓存的大小；语句缓存的上限由 max_binlog_stmt_cache_size 系统变量控制。

会话的可见性 max_binlog_cache_size

max_binlog_cache_size 세션의 가시성은 binlog_cache_size 시스템 변수의 가시성과 일치합니다. 즉, 해당 값을 변경하면 값을 변경한 후에 시작된 새 세션에만 영향을 미칩니다.

Summary

• max_binlog_cache_size는 안전한 값으로 일반적으로 서버에서 할당할 수 있는 메모리에 따라 설정됩니다.

개요

위 구성에서 바이너리 로그의 일반적인 작성 프로세스를 그릴 수 있습니다.

1. 트랜잭션은 실행될 때 각 트랜잭션의 바이너리 로그 캐시로 변경됩니다.
2. 트랜잭션이 제출된 후 구성에 따라 수행됩니다. sync_binlog=1이면 fsync가 수행될 때마다 캐시가 해제됩니다. sync_binlog=0인 경우 운영 체제에 따라 때때로 바이너리 로그를 플러시하여 시스템 파일의 페이지 캐시에 직접 기록됩니다. sync_binlog=N(N>1)이면 일괄 플러시와 동일합니다. 물론 각 트랜잭션이 보유한 binlog 캐시가 해제됩니다.

그래서 일반적인 과정은 다음과 같습니다:

요약

지금까지 우리는 Mysql을 Binary로 작성하는 과정을 대략적으로 이해했습니다. 각 트랜잭션이 보유한 binlog 캐시 -> 파일 시스템의 페이지 캐시 -> ; 구체적인 실행 전략은 sync_binlog를 통해 제어할 수 있습니다.

사용

• sync_binlog: 최대 내구성과 일관성을 얻으려면 1로 설정하세요. 성능 문제의 경우 바이너리 로그가 손실되거나 다른 방법으로 손실되도록 허용하는 경우 하드웨어 및 기타 방법을 조정할 수 있습니다. 현재 상황에 따라 제어하고자 하는 방법은 서버 리소스가 [100,1000] 간격으로 최적화되어 설정됩니다.
• binlog_cahe_size: 앞서 언급했듯이 실제 비즈니스에서는 트랜잭션 세분성 제어에 주의를 기울여야 합니다. 대부분의 경우 기본 32k이면 충분합니다.

추천 학습: mysql 비디오 튜토리얼

🎜

위 내용은 MySql에서 바이너리 로그를 작성하는 과정을 완전히 마스터하세요.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!