[MySQL][Master-Slave] 복제 필터링 - 복제평가방법

■ 서버가 복제 필터링 규칙을 평가하는 방법

복제를 구성할때 전체 데이터베이스를 대상으로 하는 방법도 있지만 원하는 데이터베이스만을 선택해서 복제할 수도 있습니다. 반대로 원하는 데이터베이스만을 복제해서 사용할 수 있습니다. 특정 데이터베이스의 특정 테이블만 복제도 가능합니다. 이렇게 원하는 조건을 만들어 복제하는 방법을 복제 필터링이라고 합니다.

복제 필터링을 구성하기 위해선 바이너리 로그 포멧 형식 선택과 복제레벨(데이터베이스 레벨 혹은 테이블 레벨) 그리고 범위등 몇가지 전략을 세워야 할 내용들이 있습니다. 여기에서는 복제필터링을 걸기위헤 사전에 확인해봐야 할 내용들을 확인해 보겠습니다. 다음으로 복제필터링을 하기 위한 환경설정, 혹은 명령문을 알아보도록 하겠습니다.

 

마스터 서버가 바이너리 로그에 명령문을 쓰지 않으면 명령문이 복제되지 않습니다. 서버가 명령문을 기록하면 명령문이 모든 슬레이브로 전송되고 각 슬레이브는 명령문을 실행할지 또는 무시하고 넘어갈지 결정합니다.

 

마스터에서 --binlog-do-db 및 --binlog-ignore-db 옵션을 통하여 바이너리 로깅을 제어하는 방법으로 변경 내용을 기록할 데이터베이스를 제어 할 수 있습니다. 이 옵션을 사용하여 복제 할 데이터베이스 및 테이블을 제어해서는 안됩니다. 대신 슬레이브에서 필터링을 사용하여 슬레이브에서 실행되는 이벤트를 제어합니다.

 

슬레이브 측에서는 마스터에서 가져온 명령문을 실행할지 또는 무시할지에 대한 결정이 슬레이브가 시작된 --replicate- * 옵션에 따라 결정됩니다.(--replicate- 로 시작되는 몇가지 옵션들)

 

가장 간단한 경우 --replicate-* 로 시작하는 옵션이 없는 경우 슬레이브는 마스터로부터 받은 모든 명령문을 실행합니다. 그렇지 않으면 결과는 주어진 특정 옵션에 따라 다릅니다.

 

데이터베이스 레벨 옵션 (--replicate-do-db, --replicate-ignore-db)이 먼저 확인됩니다. 데이터베이스 레벨 옵션이 사용되지 않는 경우, 옵션 점검은 사용중인 테이블 레벨 옵션으로 진행됩니다. 하나 이상의 데이터베이스 레벨 옵션이 사용되었지만 일치하는 것이 없으면 명령문이 복제되지 않습니다.

 

데이터베이스에만 영향을주는 명령문 (즉, CREATE DATABASE, DROP DATABASE 및 ALTER DATABASE)의 경우 데이터베이스 수준 옵션은 항상 --replicate-wild-do-table 옵션보다 우선합니다. 즉, 이러한 명령문의 경우 --replicate-wild-do-table 옵션은 적용되는 데이터베이스 레벨 옵션이 없는 경우에만 점검됩니다. 슬레이브가 --replicate-do-db=dbx --replicate-wild-do-table = db%.t1.로 시작된 경우 CREATE DATABASE dbx 문이 복제되지 않은 이전 버전의 MySQL에서 변경된 동작입니다.

 

옵션 세트가 어떤 영향을 미치는지 쉽게 결정할 수 있도록 "do"및 "ignore"옵션 또는 와일드 카드 및 비 와일드 카드 옵션의 혼합을 피하는 것이 좋습니다.

 

--replicate-rewrite-db 옵션이 지정된 경우 --replicate- * 필터링 규칙을 테스트하기 전에 적용됩니다.

 

MySQL 5.6에서 모든 복제 필터링 옵션은 lower_case_table_names 시스템 변수의 영향을 포함하여 MySQL 서버의 다른 곳에서 데이터베이스 및 테이블 이름에 적용되는 대소 문자 구분 규칙과 동일한 규칙을 따릅니다.

 

■ 데이터베이스 레벨 복제와 바이너리 로깅 옵션의 평가

복제 옵션을 평가할때 슬레이브는 --replicate-do-db 또는 --replicate-ignore-db 옵션이 적용되는지 확인하여 시작합니다. --binlog-do-db 또는 --binlog-ignore-db를 사용하는 경우 프로세스는 비슷하지만 마스터에서 옵션을 확인합니다.

 

일치를 점검하는 데이터베이스는 처리중인 명령문의 바이너리 로그 형식에 따라 다릅니다. 명령문이 Row 형식을 사용하여 로그된 경우 데이터가 변경될 데이터베이스가 점검되는 데이터베이스입니다. 명령문이 명령문 형식을 사용하여 로그 된 경우, 기본 데이터베이스 (USE 문으로 지정됨)는 점검되는 데이터베이스입니다.

 

Row 형식을 사용하여 DML 문만 기록 할 수 있습니다. binlog_format=ROW인 경우에도 DDL 문은 항상 명령문으로 기록됩니다. 따라서 모든 DDL 문은 항상 Statement 기반 복제 규칙에 따라 필터링됩니다. 즉, DDL 문을 적용하려면 USE 명령문을 이용해 명시적으로 기본 데이터베이스를 선택해야합니다.

 

복제를 위해 관련된 단계는 다음과 같습니다. 다음단계를 따르면 어떤 방식으로 설정을 해야 할지 결정이 됩니다.

 

1. 어떤 로깅 형식이 사용됩니까?

+ Statement. 기본 데이터베이스를 테스트해야 합니다.

+ ROW. 변경 사항의 영향을받는 데이터베이스를 테스트해야 합니다.

 

2. --replicate-do-db 옵션이 있습니까?(슬레이브에서)

+ YES. 데이터베이스가 데이터베이스와 일치하나요?

  - YES. 4 단계로 진행합니다.

  - NO. 업데이트를 무시하고 종료합니다.

+ NO. 3 단계를 계속합니다.

 

3. --replicate-ignore-db 옵션이 있습니까?

+ YES. 데이터베이스가 데이터베이스와 일치합니까?

  - YES. 업데이트를 무시하고 종료합니다.

  - NO. 4 단계를 계속합니다.

+ NO. 4 단계를 계속합니다.

 

4. 테이블 레벨 복제 옵션이 있는지 확인합니다. (있는 경우) : 아래에서 테이블 레벨 복제에 대해 설명합니다.

 

위에 이 단계에서 여전히 허용되는 명령문은 아직 실제로 실행되지 않습니다. 모든 테이블 레벨 옵션 (있는 경우)도 점검이 완료될 때까지 명령문이 실행되지 않으며, 해당 프로세스의 결과(점검이 완료된 경우)로 명령문을 실행할 수 있습니다.

 

이진 로깅의 경우 관련된 단계는 다음과 같습니다.

1. --binlog-do-db 또는 --binlog-ignore-db 옵션이 있습니까?(Master에서)

+ YES. 2 단계로 진행합니다.

+ NO. 명령문을 기록하고 종료합니다.

 

2. 기본 데이터베이스가 있습니까 (USE에서 데이터베이스를 선택 했습니까)?

+ YES. 3 단계로 진행합니다.

+ NO. 명령문을 무시하고 종료합니다.

 

3. 기본 데이터베이스가 있습니다. --binlog-do-db 옵션이 있습니까?

+ YES. 데이터베이스와 일치하는 것이 있습니까?

  - YES. 명령문을 기록하고 종료합니다.

  - NO. 명령문을 무시하고 종료합니다.

+ NO. 4 단계를 계속 진행합니다.

 

4. --binlog-ignore-db 옵션 중 데이터베이스와 일치하는 옵션이 있습니까?

+ YES. 명령문을 무시하고 종료합니다.

+ NO. 명령문를 기록하고 종료합니다.

 

Statement 기반 로깅의 경우 CREATE DATABASE, ALTER DATABASE 및 DROP DATABASE 문에 대해 제공된 규칙에서 예외가 발생합니다. 이러한 경우, 업데이트를 기록 또는 무시할지 여부를 결정할 때 생성, 변경 또는 삭제되는 데이터베이스가 기본 데이터베이스를 대체합니다.

 

--binlog-do-db는 때때로 "다른 데이터베이스 무시"를 의미 할 수 있습니다. 예를 들어, Statement 기반 로깅을 사용할 때 --binlog-do-db=sales로만 실행되는 서버는 기본 데이터베이스가 sales와 다른 바이너리 로그 명령문에 기록하지 않습니다. 동일한 옵션으로 Row 기반 로깅을 사용하는 경우 서버는 sales 데이터를 변경하는 업데이트만 기록합니다.

 

 

 

■ 테이블 레벨 복제 옵션 평가

슬레이브는 다음 두 조건 중 하나에 해당하는 경우에만 테이블 옵션을 확인하고 평가합니다.

+ 일치하는 데이터베이스 옵션이 없습니다.

+ 하나 이상의 데이터베이스 옵션이 발견되었으며 이전 섹션에서 설명한 규칙에 따라 "실행"조건에 도달 한 것으로 평가되었습니다 .

 

먼저 예비 조건으로 슬레이브는 Statement 기반 복제가 사용 가능한지 확인합니다. 그렇다면, 저장된 함수 내에서 명령문이 발생하면 슬레이브는 명령문을 실행하고 종료합니다. Row기반 복제가 활성화 된 경우 슬레이브는 명령문이 마스터의 저장된 함수 내에서 발생했는지 여부를 알 수 없으므로 이 조건이 적용되지 않습니다.

 

Statement 기반 복제의 경우 복제 이벤트는 명령문을 나타냅니다(주어진 이벤트를 구성하는 모든 변경 사항은 단일 SQL문과 연관 됨). Row 기반 복제의 경우 각 이벤트는 단일 테이블 행의 변경을 나타냅니다 (따라서 UPDATE mytable SET mycol = 1과 같은 단일 명령문은 많은 Row 기반 이벤트를 생성 할 수 있습니다). 이벤트 측면에서 볼때 테이블 옵션을 검사하는 프로세스는 Row 기반 및 Statement 기반 복제 모두 동일합니다.

 

이 시점에 도달하면 테이블 옵션이 없는 경우 슬레이브는 단순히 모든 이벤트를 실행합니다. --replicate-do-table 또는 --replicate-wild-do-table 옵션이 있는 경우 이벤트를 실행하려면 이벤트 중 하나와 일치해야합니다. 그렇지 않으면 무시됩니다. --replicate-ignore-table 또는 --replicate-wild-ignore-table 옵션이 있으면 이러한 옵션과 일치하는 이벤트를 제외한 모든 이벤트가 실행됩니다.

 

다음 단계에서는 이 평가에 대해 자세히 설명합니다. 즉 데이터베이스 수준 옵션의 평가가 시작됩니다.

 

1. 테이블 복제 옵션이 있습니까?

+ YES. 2 단계로 진행합니다.

+ NO. 업데이트를 실행하고 종료합니다.

 

2. 어떤 로깅 형식이 사용됩니까?

+ Statement. 업데이트를 수행하는 각 명령문에 대해 나머지 단계를 수행합니다.

+ ROW. 테이블 행의 각 업데이트에 대해 나머지 단계를 수행합니다.

 

3. --replicate-do-table 옵션이 있습니까?

+ YES. 테이블이 그들 중 하나와 일치합니까?

  - YES. 업데이트를 실행하고 종료합니다.

  - NO. 4 단계를 계속합니다.

+ NO. 4 단계를 계속합니다.

 

4. --replicate-ignore-table 옵션이 있습니까?

+ YES. 테이블이 그들 중 하나와 일치합니까?

  - YES. 업데이트를 무시하고 종료합니다.

  - NO. 5 단계를 계속합니다.

+ NO. 5 단계를 계속합니다.

 

5. --replicate-wild-do-table 옵션이 있습니까?

+ YES. 테이블이 그들 중 하나와 일치합니까?

  - YES. 업데이트를 실행하고 종료합니다.

  - NO. 6 단계를 계속합니다.

+ NO. 6 단계를 계속합니다.

 

6. --replicate-wild-ignore-table 옵션이 있습니까?

+ YES. 테이블이 그들 중 하나와 일치합니까?

  - YES. 업데이트를 무시하고 종료합니다.

  - NO. 7 단계를 계속합니다.

+ NO. 7 단계를 계속합니다.

 

7. 테스트 할 다른 테이블이 있습니까?

+ YES. 3 단계로 돌아갑니다.

+ NO. 8 단계를 계속합니다.

 

8. --replicate-do-table 또는 --replicate-wild-do-table 옵션이 있습니까?

+ YES. 업데이트를 무시하고 종료합니다.

+ NO. 업데이트를 실행하고 종료합니다.

 

단일 SQL 명령문이 --replicate-do-table 또는 --replicate-wild-do-table 옵션에 포함된 테이블과 --replicate-ignore-table 혹은  --replicate-wild-ignore-table옵션에 의해 무시되는 다른 테이블 모두에서 작동하는 경우 Statement 기반 복제가 중지됩니다. 슬레이브는 complete 문 (복제 이벤트를 형성 함)을 실행하거나 무시해야하며 논리적으로 이를 수행 할 수 없습니다. DDL 문은 실제로 로깅 형식에 관계없이 명령문으로 기록되므로 DDL 문의 행 기반 복제에도 적용됩니다. 포함된 테이블과 무시된 테이블을 모두 업데이트하고 계속 성공적으로 복제 할 수있는 유일한 유형의 명령문은 binlog_format = ROW로 기록 된 DML 명령문입니다.

 

■ 복제 규칙 적용

여기에서는 다양한 복제 필터링 옵션 조합에 대한 추가 설명과 사용 예를 제공합니다.

다음 표에는 복제 필터 규칙 유형의 몇 가지 일반적인 조합이 나와 있습니다.

상태 (옵션타입)	결과
--replicate-* 옵션이 없습니다.	슬레이브는 마스터로부터받은 모든 이벤트를 실행합니다.
--replicate-*-db 옵션이지만 테이블 옵션은 없습니다.	슬레이브는 데이터베이스 옵션을 사용하여 이벤트를 승인하거나 무시합니다. 테이블 제한이 없으므로 해당 옵션에서 허용하는 모든 이벤트를 실행합니다.
--replicate-*-table 옵션이지만 데이터베이스 옵션은 없습니다.	데이터베이스 조건이 없으므로 모든 이벤트는 데이터베이스 검사 단계에서 승인됩니다. 슬레이브는 테이블 옵션만을 기준으로 이벤트를 실행하거나 무시합니다.
데이터베이스 및 테이블 옵션의 조합 :	슬레이브는 데이터베이스 옵션을 사용하여 이벤트를 승인하거나 무시합니다. 그런 다음 테이블 옵션에 따라 해당 옵션이 허용하는 모든 이벤트를 평가합니다. 이로 인해 때로는 직관적이지 않은 결과가 나올 수 있으며 명령문 기반 복제를 사용하는지 또는 Row 기반 복제를 사용하는지에 따라 달라질 수 있습니다

 

 

Statement 기반 및 Row 기반 설정 모두에 대한 결과를 검사하는, 보다 복잡한 예가 나옵니다.

 

마스터의 데이터베이스 db1에 mytbl1 테이블 1개와 데이터베이스 db2에 mytbl2 테이블1개, 즉 각각의 데이터베이스에 한개씩의 테이블이 있습니다. 슬레이브가 다음 옵션으로 실행 중이고 다른 복제 필터링 옵션은 없다고 가정합니다.

replicate-ignore-db = db1

replicate-do-table = db2.tbl2

 

이제 마스터에서 다음 명령문을 실행합니다.

USE db1;

INSERT INTO db2.tbl2 VALUES (1);

슬레이브의 결과는 바이너리 로그 형식에 따라 크게 다르며 두 경우 모두 초기 예상과 일치하지 않을 수 있습니다.

 

▶ Statement 기반 복제.

USE 문은 db1이 기본 데이터베이스가 되도록합니다. 따라서 --replicate-ignore-db 옵션이 일치하고 INSERT 문은 무시됩니다. 테이블 옵션이 확인되지 않았습니다.

 

▶ Row 기반 복제.

기본 데이터베이스는 Row 기반 복제를 사용할때 슬레이브가 데이터베이스 옵션을 읽는 방법에 영향을 미치지 않습니다. 따라서 USE 문은 --replicate-ignore-db 옵션 처리 방식에 차이가 없습니다. 이 옵션으로 지정된 데이터베이스가 INSERT 문이 데이터를 변경하는 데이터베이스와 일치하지 않으므로 슬레이브가 테이블 옵션을 점검합니다. --replicate-do-table로 지정된 테이블은 업데이트 할 테이블과 일치하고 행이 삽입됩니다.

 

■ Master-Slave 복제 환경 관련 참고글

[Master-Slave] 복제소개 및 사용방법

[MySQL][Master-Slave] 복제소개 및 사용방법

[Master-Slave] 복제환경에서의 바이너리 로그 특징

[MySQL][Master-Slave] 복제 환경에서 Binary Log 특징

[Master-Slave] 복제환경 모니터링

[MySQL][Master-Slave] 복제 환경 모니터링

[Master-Slave] 복제 필터링 - 명령문 및 적용방법

[MySQL][Master-Slave] 복제 필터링 - 명령문 및 적용방법

[Master-Slave] GTID를 이용한 복제 - 이론

[MySQL][Master-Slave] GTID를 이용한 복제 - 이론

[Master-Slave] GTID를 이용한 복제 - 구성방법

[MySQL][Master-Slave] GTID를 이용한 복제 - 구성방법

 

 

 

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