카테고리 없음

Previous_gtids_log_event in MySQL Replication

suhwanc 2023. 9. 29. 11:52

1. 소개

Previous_gtids_log_event 는 MySQL DB 에서 발생하는 binlog event 중 하나로 직전 binlog 파일에 기록된 gtid_executed 를 담고 있는 이벤트이다.

 

gtid_executed 는 특정 DB 에 지금까지 발생한 모든 GTID 들을 간소화된 형태로 저장하고 있는 값인데, 아래와 같은 형태를 띄고 있다.

 

하나의 GTID 묶음 형태 일수도 있고

3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5

복제에 의해 여러 개의 DB 에서 파생되어 진 경우, 각각의 DB 마다 id 값이 달라 여러 개의 GTID 묶음이 될 수 있다.

2174B383-5441-11E8-B90A-C80AA9429562:1-3, 24DA167-0C0C-11E8-8442-00059A3C7B00:1-19

gtid_executed 는 다음 명령어를 통해 확인 가능하다.

SELECT @@GLOBAL.gtid_executed;

 

이벤트의 발생 시점

Previous_gtids_log_event 는 binlog 파일이 새로 생길 때 발생하는데, 보통 이런 상황이다.

  • 현재 저장 중인 binlog 파일이 지정된 용량을 초과했을 경우, 다음 binlog 파일을 생성하고 시작 부분에 기록
  • MySQL 서버가 죽었다 살아나는 경우(고의이던 아니던), binlog 파일을 저장해두고 살아날 때 다음 binlog 파일을 생성

 

이벤트 발생 시나리오

기본적으로 Previous_gtids_log_event 는 GTID 를 생성하는 옵션을 켜야만 발생되며 다음 명령어를 통해 켤 수 있다.

set global enforce_gtid_consistency  = ON;

이후 DB 에 테이블 생성 및 컬럼 추가, 변경 등 binlog 에 GTID 가 쌓일 만한 일들을 작업한 후 gtid_executed 값을 확인해보면 이런 식으로 지금까지 발생한 GTID 들을 볼 수 있다.

만약 이 상태에서 binlog 파일이 하나 더 생성된다면, 해당 binlog 파일의 맨 앞에는 이 gtid_executed 값이 들어가게 되는 것이다.

 

따라서 다시 요약하자면, Previous_gtids_log_event 는 현재 DB 에 발생했던 모든 GTID 에 대한 함축된 정보라고 볼 수 있다.

 

 

2. 사용 사례

Previous_gtids_log_event 는 MySQL 8.0 부터 도입되었기 때문에, 꼭 필요한 이벤트라고 보기는 어렵다.

하지만 다음 작업에서는 효율성을 높일 수 있을 것으로 기대된다.

GTID A 와 여러 개의 binlog 파일이 순서대로 주어졌을 때, 어떤 binlog 파일에 GTID A 가 존재하는가?

 

기존에는 만약 GTID '3E11FA47-71CA-11E1-9E33-C80AA9429562:23'  이 있는 binlog 파일을 찾기 위해선 아래 명령어를 통해 각 binlog 파일마다 내가 찾고자하는 GTID 가 위치하는지 순회하여 찾는 방법이 있었다.

$ mysqlbinlog --base64-output=DECODE-ROWS -v -v --start-gtid=3E11FA47-71CA-11E1-9E33-C80AA9429562:23 mysql-bin.000001

이 경우 시간복잡도는 binlog 파일에 저장된 이벤트만큼 늘어나므로, 상당히 부담되는 작업이다.

 

하지만 Previous_gtids_log_event 가 있다면, 각 binlog 파일마다 맨 앞에서 지금까지 발생한 GTID 목록을 확인 후 이전 binlog 들을 모두 건너뛸 수 있다. 이 경우 시간 복잡도는 거의 binlog 파일의 개수와 비례한다.

 

따라서 이 작업이 효율적으로 개선된다면, 특정 GTID 위치를 알아내야 할 다음과 같은 상황들에 사용될 수 있다.

  • 장애 발생 시 데이터베이스 복구
    • 장애가 나기전에 읽은 마지막 GTID 값의 위치를 찾고, 그 이후부터 다시 수행하도록 만들 수 있다.
  • master - slave 간 복제 확인
    • slave DB 는 master DB 의 binlog 를 그대로 가져오므로, 둘 사이의 GTID 값이 일치하는 지(복제가 잘 되고 있는 지) 확인하기 위해 특정 GTID 의 위치를 파악해야 할 수 있다.
  • 복제 셋업 (CDC)
    • DB 간 복제 작업 시, 항상 두 DB 를 연결한 후 GTID 만을 이용해 복제 대상 DB 에 적용하는 것은 아니다.
    • 복제 시 최초에 한 번은 mysqldump 를 통해 덤프 본으로 DB 구성 후, GTID 를 활용 할 수도 있다. 이때는 덤프 본의 맨 마지막 GTID 를 찾는 작업이 필요하다.