9.5 Distributed Recovery

1. Group Replication Basics 

Group Replication의 분산 복구 프로세스는 그룹안에서 현재 발생중인 이벤트를 모니터링 하면서 그룹안의 온라인 서버에서 맞춰야 하는 데이터를 가져와서 구성하는 절차로 요약해서 이야기 할 수 있다. 즉, 복구 프로세스를 진행하는 중에 서버는 해당 구성원들이 실행하는 이벤트들에 대한 정보를 수신하여 대기시킨다. 그 다음 어떻게 진행되는지는 좀 더 자세히 다음 내용에서 설명하도록 한다. 

1.1 Phase 1

가장 먼저 Joiner 는 가입하려는 그룹안에서 온라인 상태에 있는 서버 한대를 선택하여 Donor로 설정한다. Donor는 Joiner가 가입한 순간부터 가지고 있지 않은 데이터를 전달하는 역할을 수행한다. 이 작업은 두 서버간에 표준 비동기 Replication channel을 이용하여 작업한다. Joiner는 Donor로 부터 바이너리 로그를 받아서 해당 작업을 진행한다. 

바이너리 로그 전송이 되는 동안 Joiner는 그룹 내에서 실행되는 모든 트랜잭션을 수집하여 저장한다. 즉, 그룹에 가입한 후 Donor로 부터 데이터를 받아 적용하는 동안에 발생한 이벤트를 저장한다는 것이다. 그래서 Donor로 부터 데이터를 받아서 적용하는 작업이 끝나게 되면 다음 작업으로 넘어가게 된다. 

1.2 Phase 2

Donor로 부터 받은 데이터를 전부 적용하고 나면 그 작업 동안에 저장해 둔 이벤트들을 순서대로 적용한다. 그래서 대기중인 트랜잭션 갯수가 0이 되면 그룹내에서 온라인 상태로 변경된다. 

1.3 Resilience

첫번째 작업에서 Donor로 선택된 서버에서 데이터를 가져오는 것을 실패할 수 있다. 이런 경우 Joiner는 다른 서버를 선택하여 Donor를 변경할 수 있다. 이와 같은 작업은 자동으로 이루어 진다. 

2. Recovering From a Point-in-time

Donor의 특정 시점까지 Joiner를 동기화 하기 위해서는 GTID 기능을 사용해야만 한다. 하지만, GTID 만으로는 부족하다. 특정 시점에 맞추기 위해서는 추가적으로 제공되는 Binary Log View Marker 가 필요하다.  Binary Log View Marker는 바이너리 로그 스트림 안에 변경 View 정보를 넣어놓는다. 그리고, 추가적인 메타 정보도 포함시킨다. 

View Change Maker에 대해 제대로 이해하려면, View와 View Change에 대해 제대로 이해하고 있어야 한다. 

-- VIEW

뷰는 현재 구성에 적극적으로 참여하는 멤버 그룹, 즉 특정 시점에 해당합니다. 이 정보는 시스템의 현재 정확한 상태를 의미한다. 

-- VIEW CHANGE

View Change는 구성원이 추가되거나 제거되는 것과 같은 그룹의 구성 변경을 의미한다. 어떤 구성원의 상태가 변경되더라도 Group 안의 모든 구성원은 동일하게 변경되어 항상 논리적으로 동일한 정보를 가지고 있다. 

-- VIEW IDENTIFIER 

View 정보를 유일하게 식별하는 값이다. View가 변경될 때마다 값이 부여된다. 

Group Communication Layer에서 연관된 View ID를 가진 View Change는 구성원이  투입되기 전후에 교환 된 데이터 사이의 경계가 된다. 이 개념은 새로운 바이너리 로그 이벤트 인 View Change Log Event를 통해 구현됩니다. 따라서 VIEW ID는 그룹 구성원이 변경되기 전후에 전송 된 트랜잭션에 대한 마커가 된다. 

VIEW IDENTIFIER는 (i) 무작위로 생성 된 것과 (ii) 단조롭게 증가하는 정수의 두 부분으로 구성됩니다. 첫 번째 부분은 그룹이 생성 될 때 생성되며 그룹에 구성원이 하나 이상있는 동안 변경되지 않습니다. 두 번째 부분은 View가 변경 될 때마다 증가합니다.

VIEW IDENTIFIER는 구성원의 일부분만 빠졌거나 추가되었을 경우, 그리고 전체 그룹이 모두 빠져나갔을 경우 이 두 가지 상황을 구분하기 위해 2부분으로 구성된다.  증가분 값만으로 VIEW IDENTIFIER를 구성하게 되는 경우, 전체 그룹이 빠져나가고 새롭게 다시 구성하는 경우의 VIEW IDENTIFIER가 이전의 값과 같은 값이 되어 혼돈을 줄 수 있기 때문이다. 즉, 첫번째 부분은 MySQL Group Replication이 처음 시작할때에만 값이 생성되고, 그 이후에는 두번째 부분만 계속 변하게 된다. 

3. View Changes

3.1 Begin Stable Group 

모든 서버는 온라인 상태이며 그룹의 들어오는 트랜잭션을 처리한다. 일부 서버는 복제 된 트랜잭션 측면에서 약간 뒤떨어 질 수 있지만 결국에는 수렴한다. 그룹은 하나의 분산 및 복제 데이터베이스 역할을 한다.

3.2 View Change : a member Join 

새 구성원이 그룹에 가입 할 때 View Change가 수행 될 때마다 모든 온라인 서버는 실행을 위해 View Change Log Event를 큐에 대기시킨다. View Change하기 전에 적용 할 서버에 여러 트랜잭션을 대기시킬 수 있으므로 이 큐는 이전 뷰에 속하기 때문에 이 큐에 대기한다. 이러한 변경이 발생한 시점의 올바른 표시를 보장 한 후에 View Change Event를 큐에 넣는다.

한편, Joiner는 뷰 추상화를 통해 멤버쉽 서비스에 명시된 대로 온라인 서버 목록에서 Donor를 선택한다. 멤버는 View 4에 가입하고 온라인 멤버는 View Change Event를 바이너리 로그에 기록한다.

3.3 State Transfer : Catching Up

그룹의 어떤 서버가 Donor가 될지를 선택하면, 새로운 비동기식 복제 연결이 두 서버간에 설정되고 상태 전송이 시작된다 (1 단계). 이 Donor와의 상호 작용은 Joiner가 그룹에 들어 왔을 때 트리거 된 보기 변경 사항에 해당하는 View Change Log Event를 Joiner의 applier 스레드가 처리 할 때까지 계속된다. 즉, 이미 존재하는 View Maker와 일치하는 View Identifier로 Maker에 도달 할 때까지 Joiner가 Donor에서 복제한다.

동일한 논리적 시간에 그룹의 모든 구성원에게 View Identifier가 전송되므로 Joiner는Replication을 중지해야 하는 View Identifier를 알고 있다. 이렇게하면 View ID가 각 그룹 View에 속하는 데이터를 명확하게 표시하기 때문에 복잡한 GTID-set 계산을 피할 수 있다.

Joiner가 Donor로부터 Replication하는 동안 그룹에서 들어오는 트랜잭션을 캐싱한다. 결국 Donor로부터 복제를 중지하고 캐시 된 것을 적용한다.

3.4 Finish : Caught Up

Joiner가 view change log event 의 View Identifier가 완료하기를 예상한 값이라고 판단하면, Doner에 대한 연결을 종료하고캐시 된 트랜잭션의 적용이 시작된다. 이해해야 할 중요한 점은 최종 복구 절차이다. 뷰 변경 사항을 구분하고, 바이너리 로그 안에 Maker로서 역할 함에도 불구하고, View Change Log Event는  또 다른 역할도 수행한다. 바로, Joiner가 그룹에 들어올 때, 모든 서버가 인식하는 인증 정보로서 이 정보를 사용하는 것이다.  이 기능이 없으면 후속 트랜잭션을 인증 (충돌 감지) 할 수있는 데 필요한 정보가 없습니다.

Catch up 작업동안에 (2 단계)는 작업량과 그룹에 들어오는 트랜잭션 비율에 따라 달라 지므로 결정적이지 않다. 이 프로세스는 완전히 온라인 상태이며 추격하는 동안 그룹의 다른 서버를 차단하지 않는다. 따라서 단계 2로 이동할 때 Joiner가 수행하는 트랜잭션 수는 이러한 이유로 작업 부하에 따라 달라 지므로 증가하거나 감소 할 수 있다.

Joiner가 대기중인 트랜잭션이 0에 도달하고 저장된 데이터가 다른 멤버와 같으면 해당 공용 상태가 온라인으로 변경됩니다.

4. Usage Advice and Limitations of Distributed Recovery 

분산 복구에는 몇 가지 제한 사항이 있다. 이는 클래식 비동기 복제를 기반으로하므로 Joiner가 전혀 준비되지 않았거나 매우 오래된 백업 이미지가 제공된 경우 속도가 느려질 수 있다. 즉, 전송할 데이터가 1 단계에서 너무 큰 경우 서버가 복구하는 데 매우 오랜 시간이 걸릴 수 있다. 따라서 그룹에 서버를 추가하기 전에 그룹에 이미있는 서버의 스냅 샷을 제공해야 한다. 이는 단계 1의 길이를 최소화하고 더 적은 바이너리 로그를 저장하고 전송해야하기 때문에 Donor 서버에 미치는 영향을 줄인다.