마스터-슬레이브 지연 튜닝 아이디어
1. 마스터-슬레이브 지연이란 무엇입니까?
핵심은 슬레이브 라이브러리의 재생이 마스터 라이브러리를 따라갈 수 없고 재생 단계가 지연된다는 것입니다.
2. 마스터-슬레이브 지연의 일반적인 원인은 무엇입니까?
1. 대규모 트랜잭션의 경우 슬레이브 라이브러리 재생 시간이 길어서 마스터-슬레이브 지연이 발생합니다.
2. 메인 라이브러리가 너무 자주 쓰기 때문에 슬레이브 라이브러리가 재생을 따라갈 수 없습니다.
3. 무리한 파라미터 설정
4. 마스터-슬레이브 하드웨어의 차이점
5. 네트워크 지연
6. 테이블에 기본 키가 없거나 인덱스가 자주 업데이트됩니다.
7. 읽기와 쓰기를 분리하는 일부 아키텍처는 슬레이브 라이브러리에 더 큰 부담을 줍니다.
3. 마스터-슬레이브 지연을 해결하는 방법은 무엇입니까?
1. 대규모 거래의 경우 작은 거래로 분할하세요.
2. 병렬 복제 활성화
3. 슬레이브 하드웨어 업그레이드
4. 기본 키를 갖도록 노력하십시오
4. 병렬 복제란 무엇이며 해당 매개변수는 무엇입니까?
MySQL 병렬 복제 과정 검토
MySQL5.6은 데이터베이스 수준 병렬 복제를 기반으로 합니다.
slave-parallel-type=DATABASE(다른 라이브러리의 트랜잭션, 잠금 충돌 없음)
MySQL5.7 그룹 커밋 기반 병렬 복제
slave-parallel-type=LOGICAL_CLOCK : Commit-Parent-Based模式(同一组的事务[last-commit相同]동일한 그룹에서는 잠금 충돌이 없어야 합니다. 그렇지 않으면 동일한 그룹이 될 수 없습니다.
위는 슬레이브 라이브러리의 구성입니다. 병렬 복제는 마스터 라이브러리의 그룹 제출에 따라 다릅니다. (그룹 복제 간의 차이점에 유의하세요.)
greatsql> show variables like '%group%delay%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.01 sec)
-
binlog_group_commit_sync_delay: 그룹 제출 전 대기 시간 -
binlog_group_commit_sync_no_delay_count: 그룹을 커밋하기 전에 기다려야 할 트랜잭션 수
위의 매개변수는 모두 주 데이터베이스의 바쁜 상황에 따라 달라집니다. 업무가 자주 발생하지 않으면 매우 당황스러울 것입니다.
binlog_group_commit_sync_no_delay_count: 이 매개변수는 2로 설정됩니다.
예를 들어, 하나의 스레드만 하나의 트랜잭션을 실행하고 두 번째 트랜잭션이 24시간 후에 실행되는 경우 이 트랜잭션은 제출되기 전에 24시간을 기다려야 하므로 매우 실망스럽습니다.
binlog_group_commit_sync_delay
200ms로 설정하고 하나의 스레드만 트랜잭션을 실행하는 경우 10ms 안에 제출할 수 있지만 200ms를 기다려야 합니다.
일반적으로 둘 다 온라인으로 설정됩니다. 예를 들어 사람들을 강 건너편으로 수송하는 작은 보트와 같습니다.
매개변수가 다음과 같이 설정되었다고 가정해 보겠습니다.
binlog_group_commit_sync_delay=200;
binlog_group_commit_sync_no_delay_count=2
200ms가 필요하면 직접 갈 수 있고, 2명이 필요하면 직접 갈 수 있습니다. 이는 훨씬 사용자 친화적이지만 비즈니스가 바쁘지 않을 때는 여전히 당황스럽습니다.
쓰기 세트 기반 MySQL8.0 병렬 복제
기본 키 기반 충돌 감지(binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION, 수정된 행의 기본 키 또는 비어 있지 않은 고유 키에 충돌이 없으면 병렬화 가능)
거래 감지 알고리즘:transaction_write_set_extraction = XXHASH64
MySQL에는 제출된 트랜잭션의 HASH 값을 저장하는 변수가 있습니다. 해싱 후 제출된 모든 트랜잭션에 의해 수정된 기본 키(또는 고유 키) 값을 해당 변수 세트와 비교하여 변경 여부를 결정합니다. 행이 충돌하고 종속성을 확인하려면
여기에 언급된 변수는 다음을 통해 크기를 설정할 수 있습니다.binlog_transaction_dependency_history_size
이러한 종류의 세분성은 행 수준에 도달했습니다. 즉, 현재 병렬 세분성이 더 정교해지며 어떤 경우에는 슬레이브의 병렬성이 더 빨라진다고 해도 과언이 아닙니다. 마스터( 마스터는 단일 스레드 쓰기이고 슬레이브는 병렬로 재생할 수도 있음 )
간단히 말해서, 이는 행을 기반으로 한 병렬 재생입니다. rc 수준의 다른 행에는 잠금 충돌이 없습니다.
그룹 제출 성과:
메인 라이브러리 binlog의 last_committed 값이 일치하는지 확인하세요. 일치하면 병렬로 재생할 수 있습니다. 일치하지 않으면 직렬로만 재생할 수 있습니다.
5. 실제 분석
5.1 온라인 마스터-슬레이브 지연 확인
Seconds_Behind_Master: 48828
지연 시간이 14시간에 육박할 정도로 매우 높다는 것을 알 수 있습니다. 이때 메인 라이브러리도 지속적으로 데이터를 쓰고 있으며, 하나의 binlog에는 약 6분, 하나는 500M에 해당합니다.
5.2 현재 복제 구성 보기
슬레이브 라이브러리 구성을 봅니다.
greatsql> show variables like '%slave%para%';
+------------------------+---------------+
| Variable_name | Value |
+------------------------+---------------+
| slave_parallel_type | LOGICAL_CLOCK |
| slave_parallel_workers | 128 |
+------------------------+---------------+
2 rows in set (0.02 sec)
지연 현상:
슬레이브 라이브러리가 쫓고 있어 큰 거래는 아니지만 Seconds_Behind_Master지연이 증가하고 있음을 나타냅니다.
Retrieved_Gtid_Set: 00000000-0000-0024-0046-41a8003b4b99:242966351-253068975,
00000000-0000-0040-0095-5fff003b4b99:91056629-110569633,
00000000-0000-005c-0ced-7bae003b4b99:150292055-160253193,
31f4399f-ade5-11ed-a544-00163ebdeb51:1-12,
Executed_Gtid_Set: 00000000-0000-0024-0046-41a8003b4b99:1-252250235,
00000000-0000-0040-0095-5fff003b4b99:1-109120315,
00000000-0000-005c-0ced-7bae003b4b99:1-159504296,
31f4399f-ade5-11ed-a544-00163ebdeb51:1-12,
Auto_Position: 1
이때 병렬 복제가 없는 것으로 의심되며, 메인 라이브러리에서 그룹 제출을 설정하지 않았을 수도 있습니다(단순 추측)
5.3 추가 확인을 위해 메인 라이브러리의 binlog를 확인하세요.
기본 라이브러리의 매개변수 구성을 확인하세요. 여전히 그룹에 제출된 규칙입니다.
greatsql> show variables like '%binlog_transac%';
+--------------------------------------------+----------+
| Variable_name | Value |
+--------------------------------------------+----------+
| binlog_transaction_compression | OFF |
| binlog_transaction_compression_level_zstd | 3 |
| binlog_transaction_dependency_history_size | 25000 |
| binlog_transaction_dependency_tracking | WRITESET |
+--------------------------------------------+----------+
4 rows in set (0.02 sec)
그룹 제출 구성을 살펴보세요. 이는 그룹 제출이 없음을 의미합니다.
greatsql> show variables like '%group%delay%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.01 sec)
추가 검증 후 binlog를 살펴보면 last_committed가 실제로 다르다는 사실을 발견했습니다. 이는 병렬 처리가 불가능함을 나타냅니다.
5.4 메인 라이브러리에 대한 매개변수 설정 및 binlog 다시 구문 분석
모드 binlog_transaction_dependency_tracking로 변경 됩니다WRITESET
greatsql> show variables like '%transaction%';
+----------------------------------------------------------+-----------------+
| Variable_name | Value |
+----------------------------------------------------------+-----------------+
| binlog_direct_non_transactional_updates | OFF |
| binlog_transaction_compression | OFF |
| binlog_transaction_compression_level_zstd | 3 |
| binlog_transaction_dependency_history_size | 25000 |
| binlog_transaction_dependency_tracking | WRITESET |
| kill_idle_transaction | 300 |
| performance_schema_events_transactions_history_long_size | 10000 |
| performance_schema_events_transactions_history_size | 10 |
| replica_transaction_retries | 10 |
| session_track_transaction_info | OFF |
| slave_transaction_retries | 10 |
| transaction_alloc_block_size | 8192 |
| transaction_allow_batching | OFF |
| transaction_isolation | REPEATABLE-READ |
| transaction_prealloc_size | 4096 |
| transaction_read_only | OFF |
| transaction_write_set_extraction | XXHASH64 |
+----------------------------------------------------------+-----------------+
17 rows in set (0.00 sec)
binlog를 다시 확인하여 그 중 다수가 병렬로 재생할 수 있는지 확인하세요.
5.5 최적화 완료
메인 라이브러리가 대규모 배치로 작성하고 있음에도 불구하고 지연이 천천히 줄어들어 오늘은 0이 됩니다.
GreatSQL을 즐겨보세요 :)
GreatSQL 소개
GreatSQL은 금융 수준의 애플리케이션에 적합한 국내 독립 오픈소스 데이터베이스로, 고성능, 높은 신뢰성, 높은 사용 편의성, 높은 보안성 등 많은 핵심 기능을 갖추고 있으며 MySQL 또는 Percona Server를 대체하여 사용할 수 있습니다. 온라인 생산 환경에서 사용되며 완전 무료이며 MySQL 또는 Percona Server와 호환됩니다.
관련 링크: GreatSQL 커뮤니티 Gitee GitHub Bilibili
GreatSQL 커뮤니티:
커뮤니티 보상 제안 및 피드백: https://greatsql.cn/thread-54-1-1.html
커뮤니티 블로그 수상작 제출 세부정보: https://greatsql.cn/thread-100-1-1.html
(기사에 대해 궁금한 점이 있거나 남다른 통찰력이 있다면 공식 커뮤니티 홈페이지에 가서 질문하거나 공유해 보세요~)
기술교류그룹:
위챗 & QQ 그룹:
QQ 그룹: 533341697
WeChat 그룹: GreatSQL 커뮤니티 도우미(WeChat ID: wanlidbc)를 친구로 추가하고 커뮤니티 도우미가 귀하를 그룹에 추가할 때까지 기다립니다.