[MySQL] 복제환경에서 Binary 로그 관리 명령어

■ RESET MASTER 명령어

 

사용방법 : 

mysql> RESET MASTER

 

바이너리 로깅이 활성화된(my.cnf에서 log_bin이 ON인) 서버의 경우 RESET MASTER는 기존의 모든 바이너리 로그 파일을 삭제하고 바이너리 로그 인덱스 파일을 재설정하여 서버를 바이너리 로깅이 시작되기 전의 상태로 재설정합니다. 바이너리 로깅을 다시 시작할 수 있도록 새로운 바이너리 로그 파일이 생성됩니다.

 

GTID가 사용 중인 서버의 경우(gtid_mode가 ON임) RESET MASTER를 실행하면 GTID 실행 기록이 재설정됩니다. gtid_purged 시스템 변수의 값은 빈 문자열('')로 설정되고, gtid_executed 시스템 변수의 글로벌 값(세션 값은 아님)은 빈 문자열로 설정되며, mysql.gtid_executed 테이블은 지워집니다. GTID 지원 서버에 바이너리 로깅이 활성화된 경우 RESET MASTER는 위에서 설명한 대로 바이너리 로그도 재설정합니다. RESET MASTER는 GTID 지원 서버가 바이너리 로깅이 비활성화된 복제본인 경우에도 GTID 실행 기록을 재설정하는 방법입니다. RESET SLAVE는 GTID 실행 이력에 영향을 미치지 않습니다.

 

RESET MASTER는 마스터와 슬레이브를 처음 설정할때 유용하므로 다음과 같이 설정을 확인할 수 있습니다.

1. 마스터와 슬레이브를 시작하고 복제를 시작합니다

2. 마스터에서 몇 가지 테스트 쿼리를 실행합니다.

3. 쿼리가 슬레이브에 복제되었는지 확인합니다.

4. 슬레이브가 올바르게 실행중이면 복제본에서 STOP SLAVE를 실행후 RESET SLAVE를 실행한 다음 원하지 않는 데이터가 복제본에 더 이상 존재하지 않는지 확인합니다.

5. 테스트 쿼리를 정리하려면 소스에서 RESET MASTER를 실행합니다.

 

복제 환경 및 서버 설정을 확인하고 마스터 및 슬레이브를 재설정하고 테스트를 하면서 생성된 더미 및 테스트 데이터 또는 바이너리 로그 파일이 소스 또는 복제본에 남아 있지 않은지 확인한 후 슬레이브를 시작하고 복제를 시작할 수 있습니다.

 

•중요사항

1. 원하는 바이너리 로그 파일 데이터와 GTID 실행 기록이 손실되지 않도록 이 명령문을 주의해서 사용해야 합니다.

데이터가 유실될 수 있으니 프로덕션으로 운영되는 환경에서는 가능하면 실행하지 않도록 해야 합니다.

 

2. RESET MASTER의 효과는 PURGE BINARY LOGS의 효과와 2가지 주요 면에서 다릅니다.

RESET MASTER는 인덱스 파일에 나열된 모든 이진 로그 파일을 제거하고 .000001의 숫자 접미사를 가진 빈 단일 이진 로그 파일만 남깁니다.

PURGE BINARY LOGS는 번호지정을 재설정하지 않습니다.

 

RESET MASTER는 슬레이브가 실행되는 동안 사용되지 않습니다. 슬레이브가 실행되는 동안 사용되는 RESET MASTER의 동작은 정의되지 않습니다.(즉 지원되지 않습니다.)

 

 

 

PURGE BINARY LOGS는 복제본이 실행되는 동안 안전하게 사용할 수 있습니다.

 

아래 PURGE BINARY LOGS명령어와 비교해서 정확하게 이해해야 합니다.

 

■ PURGE BINARY LOGS 명령

PURGE { BINARY | MASTER } LOGS {
    TO 'log_name'
  | BEFORE datetime_expr
}

 

바이너리 로그는 MySQL 서버에 의해 만들어진 데이터 수정(DDL, DML 수행)에 대한 정보를 포함하는 파일 세트입니다. 로그는 바이너리 로그 파일 세트와 인덱스 파일로 구성됩니다.

 

PURGE BINARY LOGS 명령문은 지정된 로그 파일 이름 또는 날짜 이전에 로그 인덱스 파일에 나열된 모든 바이너리 로그 파일을 삭제합니다. BINARY와 MASTER는 동의어입니다. 삭제된 로그 파일도 인덱스 파일에 기록된 목록에서 제거되어 주어진 로그 파일이 목록의 첫 번째 파일이 됩니다.

 

이 명령문은 바이너리 로그를 사용하는 환경이 아니면 효과가 없습니다.(--log-bin 옵션.)

 

사용예제

PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2019-04-02 22:46:26';

 

BEFORE 변형의 datetime_expr 인수는 DATETIME 값('YYYY-MM-DD hh:mm:ss' 형식의 값)으로 평가되어야 합니다.

 

이 명령문은 복제본이 복제되는 동안 실행해도 안전합니다. 현재 삭제하려는 로그 파일 중 하나를 읽고 있는 활성 복제본이 있는 경우 이 명령문은 사용 중인 로그 파일이나 그 이후의 로그 파일을 삭제하지 않지만 이전 로그 파일은 삭제합니다. 이 상황에서 경고 메시지가 발행됩니다. 그러나 복제본이 연결되지 않은 상태에서 아직 읽지 않은 로그 파일 중 하나를 제거하는 경우 다시 연결한 후 복제본을 복제할 수 없습니다.

 

바이너리 로그 파일을 안전하게 제거하려면 다음과 같은 내용을 확인합니다.

1. 각 복제본에서 SHOW SLAVE STATUS를 사용하여 읽고 있는 로그 파일을 확인합니다.

2. SHOW BINARY LOGS를 사용하여 복제 마스터 서버의 바이너리 로그 파일 목록을 가져옵니다.

3. 모든 복제본 중에서 가장 빠른 로그 파일을 확인합니다. 복제 대상 파일입니다. 모든 복제본이 최신 상태이면 이것이 목록의 마지막 로그 파일입니다.

4. 삭제하려는 모든 로그 파일을 백업합니다. (이 단계는 선택 사항이지만 항상 권장됩니다.)

5. 대상 파일을 제외한 모든 로그 파일을 제거합니다.

 

expirate_logs_days 시스템 변수가 지정된 일수가 지나면 바이너리 로그 파일이 자동으로 만료되도록 설정할 수도 있습니다. 복제를 사용하는 경우, 슬레이브가 마스터보다 지연될 수 있는 최대 일수보다 적을 수 없도록 변수를 설정해야 합니다.

 

.index 파일에 나열된 이진 로그 파일을 Linux에서 rm 사용과 같은 다른 방법으로 시스템에서 제거했을 때 두 가지 모두 실패하고 오류가 발생합니다. 이러한 오류를 처리하려면 .index 파일(단순 텍스트 파일)을 수동으로 편집하여 실제로 존재하는 바이너리 로그 파일만 나열되도록 한 다음 실패한 PURGE BINARY LOGS 문을 다시 실행합니다.

 

■ RESET SLAVE 명령어

RESET SLAVE는 슬레이브가 마스터의 바이너리 로그에서 복제 위치를 제거합니다. 이 명령문은 복제를 새로 시작하는 데 사용됩니다. 복제 메타데이터 저장소를 지우고 모든 릴레이 로그 파일을 삭제하고 새 릴레이 로그 파일을 시작합니다. 또한 MASTER_DELAY 옵션에서 CHANGE MASTER TO로 지정된 복제 지연을 0으로 재설정합니다.

 

그리고 복제 SQL 스레드에 의해 완전히 실행되지 않은 경우에도 모든 릴레이 로그 파일은 삭제됩니다. (이는 STOP SLAVE 문을 실행했거나 복제본이 많이 로드된 경우 복제본에 존재할 가능성이 있는 조건입니다.)

 

GTID가 사용 중인 서버(gtid_mode가 ON)의 경우 RESET SLAVE를 실행해도 GTID 실행 이력에는 영향을 미치지 않습니다. 이 명령문은 gtid_executed 또는 gtid_purged 또는 mysql.gtid_executed 테이블의 값을 변경하지 않습니다. GTID 실행 기록을 재설정해야 하는 경우 GTID 지원 서버가 바이너리 로깅이 비활성화된 복제본이더라도 RESET MASTER를 사용해야 합니다.

 

RESET SLAVE를 사용하려면 복제 스레드를 중지해야 하므로 실행 중인 복제본에서는 RESET SLAVE를 실행하기 전에 STOP SLAVE를 실행하여 슬레이브를 중지시킵니다. 그룹 복제 그룹 구성원에서 RESET SLAVE를 사용하려면 구성원 상태가 OFFLINE이어야 합니다. 즉, 플러그인이 로드되었지만 멤버가 현재 그룹에 속해 있지 않습니다. 그룹 구성원은 STOP GROUP REPLICATION 문을 사용하여 오프라인 상태가 될 수 있습니다.

 

선택적 FOR CHANNEL 채널 절을 사용하면 명령문이 적용되는 복제 채널의 이름을 지정할 수 있습니다. FOR CHANNEL 채널 절을 제공하면 RESET SLAVE 문을 특정 복제 채널에 적용합니다. FOR CHANNEL 채널 절을 ALL 옵션과 결합하면 지정된 채널이 삭제됩니다. 이름이 지정된 채널이 없고 추가 채널이 없으면 명령문이 기본 채널에 적용됩니다. 여러 복제 채널이 존재할 때 FOR CHANNEL 채널 절 없이 RESET SLAVE ALL 문을 실행하면 모든 복제 채널이 삭제되고 기본 채널만 다시 생성됩니다.

 

RESET SLAVE는 소스의 호스트 이름 및 포트, 복제 사용자 계정 이름 및 암호와 같은 복제 연결 매개변수를 변경하지 않습니다.

- MySQL 5.7.24부터 master_info_repository=TABLE이 서버에 설정되면 복제 연결 매개변수가 RESET SLAVE 작업의 일부로 충돌 안전 InnoDB 테이블 mysql.slave_master_info에 보존됩니다. 그들은 또한 메모리에 유지됩니다. RESET SLAVE를 실행한 후 START SLAVE를 실행하기 전에 예기치 않은 서버 종료 또는 의도적인 재시작이 발생하는 경우 복제 연결 매개변수가 테이블에서 검색되고 새 연결에 재사용됩니다.

- master_info_repository=FILE이 서버에서 설정되면(MySQL 5.7의 기본값), 복제 연결 매개변수는 메모리에만 유지됩니다. RESET SLAVE를 실행한 후 예기치 않은 서버 종료 또는 의도적인 재시작으로 인해 복제본 mysqld가 즉시 재시작되면 연결 매개변수가 손실됩니다. 이 경우 START SLAVE를 발행하기 전에 연결 매개변수를 다시 지정하기 위해 서버가 시작된 후 CHANGE MASTER TO 문을 발행해야 합니다.

 

연결 매개변수를 의도적으로 재설정하려면 연결 매개변수를 지우는 RESET SLAVE ALL을 사용해야 합니다. 이 경우 서버 시작 후 CHANGE MASTER TO 문을 실행하여 새 연결 매개변수를 지정해야 합니다.

 

RESET SLAVE는 진행 중인 트랜잭션의 암시적 커밋을 유발합니다.

복제 SQL 쓰레드가 임시 테이블을 복제하는 도중에 중지되어 RESET SLAVE가 발행된 경우, 이러한 복제된 임시 테이블은 복제본에서 삭제된다.

MySQL 5.7.5 이전에는 RESET SLAVE가 하트비트 기간(Slave_heartbeat_period)과 SSL_VERIFY_SERVER_CERT를 모두 재설정하는 효과도 있었습니다. 이 문제는 MySQL 5.7.5 이상에서 수정되었습니다.

MySQL 5.7.5 이전에는 RESET SLAVE ALL이 CHANGE MASTER TO에 의해 설정된 IGNORE_SERVER_IDS 목록을 지우지 않았습니다. MySQL 5.7.5 이상에서 이 명령문은 목록을 지웁니다.

 

※도움이 되셨다면 광고클릭 한번 부탁드립니다.※