Percona XtraBackup 8.4 Pro: Reduce Server Locking by up to 4300X
Backup 을 수행할 때 서버가 잠기는 시간을 줄이면 성능이 크게 향상되고 중단을 최소화될 수 있습니다.
Percona XtraBackup 8.4 Pro 는 DDL(Data Definition Language) 잠금(Backup Locks) 관리 방식을 개선하여 backup 중에 잠금을 줄일 수 있도록 합니다.
이번 글에서는 이러한 개선 사항이 미치는 영향을 살펴보겠습니다.
TL;DR (Summary)
Percona XtraBackup 8.4 Pro 는 backup 중에 서버가 잠기는 시간을 획기적으로 줄입니다.
새로운 –lock-ddl=reduced 옵션을 사용하면 기존의 전체 잠금(–lock-ddl=on)과 비교해 backup 잠금 시간이 200배에서 최대 4300배까지 짧아져, backup 으로 인한 방해를 크게 줄일 수 있습니다.
ALTER TABLE, TRUNCATE TABLE, CREATE USER, RENAME TABLE 과 같은 중요한 DDL 작업이 최소한의 간섭으로 진행될 수 있으며, Replica 에서의 복제 지연도 크게 감소합니다.
Percona XtraBackup 8.4 Pro 의 reduced lock 기능 주요 이점
- 잠금 시간 단축 : backup 중에 서버가 잠기는 시간을 획기적으로 줄임
- 운영 방해 최소화 : 중요한 DDL 작업을 최소한의 간섭으로 진행 가능
- 복제 지연 감소 : Replica 의 가용성과 데이터 정확성 향상
- 빠른 복구 : Primary 서버 장애 발생 시 Replica 의 빠른 장애 조치(failover) 지원
- 확장성과 유연성 향상 : 최소한의 다운타임으로 대규모 데이터베이스 운영에 최적화
Lock-reduction improvements
기존 방식에서는 DDL 잠금을 활성화한 상태(–lock-ddl=on)로 bakcup 을 수행하면 특정 DDL 작업이 실행되지 못해 운영에 병목이 발생할 수 있었습니다.
Percona XtraBackup 은 backup 을 시작할때 backup lock (LOCK INSTANCE FOR BACKUP 또는 LOCK TABLES FOR BACKUP)을 설정하여 backup 의 일관성을 보장하지만, 이로 인해 중요한 DDL 작업이 차단될 수 있었습니다.
이 개선 사항은 서버가 주로 InnoDB 엔진 테이블을 포함하는 경우 적용됩니다.
해당 기능은 full backup 과 incremental backup 모두에 적용되며, Percona Server for MySQL 8.4.x 및 Oracle MySQL 8.4.x 버전과 호환됩니다.
Examples of DDL blocking problems:
- Blocked CREATE USER statements : 사용자 생성은 데이터베이스 접근 권한을 부여하는 데 필수적이며, 특히 동적 환경의 온보딩 과정에서 중요합니다.
- Delayed Instant ALTER statements : 즉시 스키마 변경은 영향을 최소화하도록 설계되었지만, backup lock 에 의해 차단되면 배포가 지연될 수 있습니다.
- Halted ALTER TABLE operations : 애플리케이션 업데이트나 최적화를 위한 스키마 수정이 지연될 수 있습니다.
- Loss of disk space due to blocked TRUNCATE TABLE : 대용량 테이블의 잘림(truncation)이 차단되면 디스크 공간을 회수할 수 없습니다.
- Blocked RENAME TABLE statements : 테이블 이름 변경 작업은 즉시 수행되지만, backup lock 으로 인해 차단될 수 있습니다.
Percona XtraBackup 8.4 Pro 의 –lock-ddl=reduced 옵션을 사용하면 backup 잠금 유지 시간이 줄어들어(자세한 내용은 Design 섹션 참조), 중요한 DDL 작업과 backup 이 동시에 진행되면서도 데이터 일관성을 유지할 수 있습니다.
이 개선 사항은 100% InnoDB 테이블로 구성된 서버에 적용됩니다.
backup 소요 시간은 대체로 동일하지만, 일부 경우에는 추가 테이블이 포함되어 약간 길어질 수 있습니다.
그러나 이는 incremental backup 크기를 줄여 전체적인 효율성을 높이는 효과를 가져올 수 있습니다.
Design
1단계: 잠금 없이 수행되는 작업
- Checkpoint 부터 현재 LSN 까지 redo log 를 분석하고 복사한 후, 새로운 파일 작업을 추적 시작
- redo log thread 를 시작하여 redo log 를 복사합니다. 이 background thread 는 backup 이 끝날 때까지 redo log 를 계속 복사합니다.
- redo log 에서 MLOG_FILE_* 레코드를 분석하여 파일 작업을 추적합니다. 이 레코드는 backup 중인 파일에서 변경 사항을 추적하여 일관성을 보장하는 데 도움을 줍니다.
- .ibd 파일을 복사합니다. 이 단계는 가장 시간이 많이 걸리며, 이제 서버에서 back lock 을 획득하지 않고 수행됩니다.
2단계: 잠금 상태에서 수행되는 작업
- 서버에서 back lock 을 획득하여 테이블 생성 또는 변경과 같은 새로운 DDL 작업을 방지합니다.
- InnoDB 가 아닌 파일 복사
- 추적된 파일 작업을 확인하고 tablespaces 를 다시 복사합니다.
- 복사된 파일에 대해 필요한 작업(삭제 또는 이름 변경)을 수행하기 위해 추가 metadata 파일을 생성합니다. 이 방법은 스트리밍 프로세스를 방해하지 않으면서 backup 의 일관성과 정확성을 유지하도록 보장합니다.
- 모든 엔진, binlog, GTID 에서 동기화 지점을 수집하기 위해 log_status 를 조회합니다.
- redo log thread 는 최소한 5단계의 동기화 지점까지 복사한 후 중지합니다.
- 서버에서 backup lock 를 해제합니다.
Performance benchmarks
다음 차트는 backup 디렉터리 크기에 따른 서버 잠금 시간을 두 가지 시나리오에서 비교한 것입니다. Backup 은 100% InnoDB 테이블로 구성되어 있습니다.
- –lock-ddl=on : 기본 설정으로 전체 잠금(full locking) 적용
- –lock-ddl=reduced : 새로운 설정으로 잠금 시간 감소(reduced locking) 적용
Backup to local disk
아래 표는 로컬 디스크로 백업할 때의 개선 사항을 보여줍니다.
Backup to Amazon S3
Amazon S3 로 backup 할 때의 개선 사항도 마찬가지로 인상적입니다:
Reduced replication lag
복제 지연은 Replica 서버가 업데이트를 처리하는 동안 Source 서버보다 뒤처질 때 발생합니다. Source 에서의 변경 사항이 Replica 서버에 반영되는 데 시간이 걸립니다.
Percona XtraBackup 이 Replica 서버에서 복제 지연을 일으킬 수 있는 두 가지 이유가 있습니다.
- –safe-slave-backup
–safe-slave-backup 옵션은 Replica 서버에서 SQL 스레드를 중지시켜 GTID 차이, non-GTID 서버, 임시 테이블, 세션 수준의 binlog 형식 변경을 처리하여 복제 상태의 일관성을 보장합니다. 하지만 SQL 스레드가 중지되기 때문에 복제 지연이 발생할 수 있습니다.
–lock-ddl=reduced 옵션을 추가하면 SQL 스레드가 중지되는 시간을 최소화할 수 있습니다. backup 전체 기간 동안 SQL 스레드를 중지하는 대신, 잠금 아래에서 수행된 작업 동안에만 중지되므로 복제 지연이 크게 감소합니다.
- Backup Lock acquired by XtraBackup
Replica worker thread 는 DDL 을 실행하기 위해 backup lock 이 필요합니다. 만약 XtraBackup 이 이 잠금을 획득하면, worker thread 는 실행이 차단되어 복제 지연이 발생할 수 있습니다. –lock-ddl=reduced 를 사용하면 이 문제를 최소화할 수 있으며, worker thread thread 는 매우 짧은 시간 동안만 차단됩니다.
복제 지연을 줄이면 다음과 같은 이점이 있습니다:
- Faster recovery from failures : Primary 서버가 실패할 경우, 최소한의 지연을 가진 Replica 가 빠르게 인계받아 고가용성을 보장합니다.
- Accurate reporting : 리포트 생성할 때 Replica 를 사용하는 애플리케이션은 실시간 데이터를 바탕으로 더 정확한 의사 결정이 가능합니다.
- Improved user experience : Replica 를 읽기용으로 사용하는 애플리케이션은 더 일관된 데이터를 제공할 수 있습니다.
블로그 원문 : Percona XtraBackup 8.4 Pro: Reduce Server Locking by up to 4300X
자유롭게 댓글을 달아주세요! 언제나 환영합니다.
기타 문의: info@neoclova.co.kr
네오클로바 기술블로그 홈 바로가기: https://neoclova.net
네오클로바 홈페이지: http://neoclova.co.kr
