MySQL HA 서버의 리플리케이션 규칙 평가 방법

1.4.7. 서버의 리플리케이션 규칙 평가 방법

마스터 서버가 명령문을 자신의 바이너리 로그에 기록하지 못한다면, 그 명령문은 리플리케이션 되지 않는다. 서버가 명령문을 기록한다면, 그 명령문은 모든 슬레이브에 전달이 되고 각 슬레이브는 그 명령문을 실행할 지 아니면 무시할 지 결정한다.

마스터 서버에서 바이너리 로깅을 제어하기 위한 --binlog-do-db 및 --binlog-ignore-db 옵션을 사용하면 데이터베이스가 이벤트를 바이너리 로그에 기록하는 것을 통제할 수 있다. 이 옵션을 리플리케이션되는 데이터베이스 및 테이블 제어용으로는 사용하지 말도록 한다. 대신에, 슬레이브에서 실행되는 이벤트를 필터링하는 목적으로 사용하도록 한다.

슬레이브 서버 입장에서 보면, 명령문을 실행할 것인지 아니면 무시할 것인지는 슬레이브와 함께 시작된 --replicate-* 옵션에 따라서 결정된다. 슬레이브는 아래의 과정을 통해 이 옵션을 평가하는데, 데이터베이스-레벨 옵션을 먼저 검사한 후에 테이블-레벨 옵션을 검사한다.

Stage 1. 데이터베이스 옵션 검사.

슬레이브는 데이터베이스-관련 조건을 지정하는 --replicate-do-db 또는 --replicate-ignore-db 옵션이 존재하는지 검사한다:

No: 명령문을 수용하고 테이블-검사 단계를 진행한다.
Yes: 명령문을 실행할지 아니면 무시할지 결정하기 위한 --binlog-do-db 및 --binlog-ignore-db 옵션과 동일한 규칙으로 옵션을 테스트한다. 테스트 결과는 어떠한가?

Permit: 명령문을 실행하지 않는다. 결정을 유보한 채 테이블-검사 단계로 이동한다.
Ignore: 명령문을 무시하고 종료한다.

Stage 2. 테이블 옵션 검사

슬레이브는 명령문-기반 리플리케이션이 활성화 되어 있는지를 먼저 검사한다. 활성화가 되어 있고 스토어드 프로시저 내부에 명령문이 존재한다면, 그 명령문을 실행한 후에 종료한다. (열-기반 리플리케이션이 활성화 되어 있다면, 슬레이브는 마스터 상의 스토어드 프로시저 내부에 명령문이 존재하는지에 대해서는 알 수 없기 때문에, 이 조건은 적용되지 않는다.)

그 다음에, 슬레이브는 테이블 옵션을 검사하고 그 값을 알아 본다. 서버는 이 시점에서 테이블 옵션이 없는 명령문을 모두 실행한다. “do” 테이블 옵션이 존재한다면, 명령문은 그러한 옵션 중에 하나와 반드시 매치가 되어야 한다; 매치가 되지 않으면, 무시가 된다.“ignore” 옵션이 존재한다면, “ignore” 옵션과 매치가 되는 것을 제외한 모든 명령문이 실행된다. 이러한 처리 과정을 아래에서 보다 자세하게 설명하고 있다.

1. --replicate-*-table 옵션이 존재하는가?

· No: 테이블에 대한 제약이 존재하지 않기 때문에, 모든 명령문이 매치된다. 명령문을 실행한 후에 종료한다.

· Yes: 테이블 제약이 존재한다. 업데이트해야 할 테이블을 검사한다. 여러 개의 테이블을 업데이트해야 할 수 있기 때문에, 각 테이블 별로 옵션 매칭을 검사할 때 아래의 단계를 루프 형식으로 실행한다. 실행 방식은 명령문-기반 리플리케이션 또는 열-기반 리플리케이션에 따라서 달라진다:

o 명령문-기반 리플리케이션: 다음 단계로 이동해서, 보여진 순서대로 테이블 옵션을 평가한다 (논-와일드 (non-wild) 옵션을 먼저 평가한 후에 와일드 옵션을 평가한다). 업데이트를 해야 하는 테이블에 대해서만 옵션을 비교한다. 예를 들면, 명령문이 INSERT INTO sales SELECT * FROM prices라면, sales만을 옵션과 비교한다. 여러 개의 테이블을 업데이트 해야 한다면, “do” 또는 “ignore” 옵션과 매치되는 테이블이 먼저 평가된다. 나머지 테이블에 대해서도 동일한 절차를 반복적으로 실행한다.

o 열-기반 리플리케이션: 모든 테이블 열 변경 내용은 개별적으로 필터링 된다. 다중-테이블 업데이트의 경우, 각각의 테이블은 옵션에 따라서 개별적으로 필터링된다. 옵션 및 실행된 변경 내용에 따라서 업데이트가 되는 것도 있고 되지 않는 것도 있다. 명령문-기반 리플리케이션에서 올바르게 처리되지 못하는 것도 열-기반 리플리케이션은 정확하게 처리한다:

mysql> USE ber;

mysql> INSERT INTO foo.sometable VALUES (1);

2. --replicate-do-table 옵션이 존재하는가?

· No: 다음 단계로 이동한다.

· Yes: 테이블이 옵션과 매치되는가?

o No: 다음 단계로 이동.

o Yes: 명령문을 실행한 후에 종료.

3. --replicate-ignore-table 옵션이 존재하는가?

· No: 다음 단계로 이동.

· Yes: 테이블이 옵션과 매치되는가?

o No: 다음 단계로 이동.

o Yes: 명령문을 무시한 채 종료.

4. --replicate-wild-do-table 옵션이 존재하는가?

· No: 다음 단계로 이동.

· Yes: 테이블이 옵션과 매치되는가?

o No: 다음 단계로 이동.

o Yes: 명령문을 실행한 후에 종료.

5. --replicate-wild-ignore-table 옵션이 존재하는가?

· No: 다음 단계로 이동.

· Yes: 테이블이 옵션과 매치되는가?

o No: 다음 단계로 이동.

o Yes: 명령문을 무시한 채로 종료.

6. --replicate-*-table 옵션과 매치되는 것이 없다. 이 옵션을 테스트할 테이블이 아직 남아 있는가?

· No: 업데이트를 해야 할 테이블을 모두 검사하였고 매치되는 옵션을 찾지 못하였다. --replicate-do-table 또는 --replicate-wild-do-table 옵션이 존재하는가?

o No: “do” 테이블 옵션이 존재하지 않기 때문에, 명령문을 실행한 후에 종료한다.

o Yes: “do” 테이블 옵션이 존재하기 때문에, 이 옵션과 매치되는 테이블에 대해서만 명령문을 실행한다.

· Yes: 루프 실행.

예문:

--replicate-* 옵션이 없음

슬레이브는 마스터에서 전달받은 모든 명령문을 실행한다.

--replicate-*-db 옵션은 존재하지만, 테이블 옵션은 없음

슬레이브는 데이터베이스 옵션을 기반으로 명령문을 허용 또는 무시한다. 그런 다음에, 테이블 제약이 없기 때문에 이 옵션이 허용하는 모든 명령문을 실행한다.

--replicate-*-table 옵션은 존재하지만, 데이터베이스 옵션은 없음

데이터베이스 조건이 없기 때문에 데이터베이스-감사 단계에서 모든 명령문이 허용된다. 슬레이브는 테이블 옵션을 기반으로 명령문을 실행할 지 또는 무시할 지 결정한다.

데이터베이스 옵션과 테이블 옵션이 모두 존재

슬레이브는 데이터베이스 옵션을 기반으로 명령문 허용 또는 무시를 결정한다. 그런 다음에, 테이블 옵션을 기반으로 허용된 명령문을 평가한다. 다음과 같은 옵션 셋을 가정해 본다:

[mysqld]

replicate-do-db = db1

replicate-do-table = db2.mytbl2

db1가 디폴트 데이터베이스이고 슬레이브가 다음과 같은 명령문을 전달 받았다고 가정하면:

INSERT INTO mytbl1 VALUES(1,2,3);

데이터베이스 db1은 데이터베이스-검사 단계에서 --replicate-do-db 옵션과 매치된다. 이 다음에 테이블-검사 단계가 진행된다. 테이블 옵션이 존재하지 않는다면, 명령문이 실행된다. 하지만, 옵션 안에 “do” 테이블 옵션이 들어 있기 때문에, 실행될 명령문은 반드시 그것과 매치가 되어야 한다. 명령문은 매치가 되지 않기 때문에 무시된다. (db1에 들어 있는 모든 테이블에 대해서도 동일한 일이 발생한다.)