9. 17_InnoDB 클러스터 (17.1 ~ 17.4)

[DaehunGwak]

진도

17. InnoDB 클러스터 (17.1 ~ 17.4)

일시

2022.09.18.(일) 21:00

[minkukjo]

InnoDB 클러스터

• 드디어! 드디어! MySQL의 핵심이자 심장이자 MySQL의 가장 중요한 스토리지 엔진인 InnoDB의 클러스터 모드에 대해 알아보자.

기존 MySQL의 Failover의 한계점

• MySQL의 복제 기능을 이용하더라도 소스 서버에서 장애가 발생하면 레플리카 서버가 자동적으로 기존 소스 서버를 대체하지 않기 때문이다.
• 레플리카 서버에 설정된 읽기 모드를 해제해야하고, 스플릿 브레인(Split-Brain) 현상을 방지하기 위해 더 이상 소스 서버에서 데이터 변경을 실행해서는 안된다

split brain 현상이란?
스플릿 브레인 (Split Brain)은 클러스터로 구성된 두 시스템간의 네트워크가 일시적으로 동시에 단절되거나 기타 시스템상의 이유로, 클러스터 상의 모든 노드들이 각자 자신이 Primary라고 인식하게 되는 상황을 뜻한다

• 이 작업들은 모두 수동으로 일어나게 되며 매우 많은 시간이 소요된다.
• 이러한 Fail-over를 위해 서드파티 HA 솔루션을 사용하거나 직접 개발하곤 한다.
• 그런데 5.7.17 버전부터 MySQL 내장 InnoDB 클러스터가 도입되면서 이러한 문제를 해결할 수 있게 되었다.

InnoDB 클러스터 아키텍처

• MySQL의 HA 실현을 위해 만들어진 여러 구성 요소들의 집합체
• Group Replication : 소스 서버의 데이터를 레플리카 서버로 동기화하는 복제 역할 + 복제에 참여하는 서버들에 대한 자동화된 멤버십 관리(그룹에 새로운 멤버 추가 및 제거 등)
• MySQL Router : 애플리케이션이 실행한 쿼리를 적절한 MySQL로 전달하는 Proxy ( 일종의 GA 내지는 LB같은 역할인 듯 )
• MySQL Shell : SQL 실행 뿐만 아니라 자바스크립트나 파이썬 기반의 스크립트 작성 기능과 MySQL 서버에 대한 클러스터 구성 등의 어드민 작업을 위해 API를 제공
• 그룹 복제에서는 InnoDB 스토리지 엔진만 제공하는데, 그래서 InnoDB 클러스터라 부른다고 한다.
• InnoDB 클러스터는 최소 3대로 구성해야함 ( 그래야제대로 복제 그룹이 동작함 )
• InnoDB 클러스터를 사용하는 클라이언트는 MySQL Router를 연결해 쿼리르 실행한다.

Group Replication

• 그룹 복제에서는 Row 포맷의 바이너리 로그와 릴레이 로그, GTID를 사용한다.
• 그룹 복제는 복제에 참여하는 MySQL 서버들이 하나의 복제 그룹으로 묶인 클러스터 형태를 가지며 그룹 내 서버들은 서로 통신하면서 양방향으로 복제를 처리할 수 있다.
• 그래서 그룹 복제에서는 프라이머리와 세컨더리라는 용어를 쓴다.
• 쓰기를 처리하는 서버를 프라이머리, 읽기 전용으로 동작하는 서버를 세컨더리라 부른다.
• 그룹 복제에서는 한 서버에서 트랜잭션이 커밋될 준비가 되면 트랜잭션 정보를 그룹 내의 다른 멤버들에게 전파하고 과반수 이상의 멤버로 부터 응답을 받으면 그때 해당 트랜잭션을 Certify하고 최종적으로 커밋한다.
• 여기서 중요한 부분은 과반수 이상의 멤버로부터 응답을 못받으면 해당 트랜잭션은 그룹 내에서 처리되지 않는다.
• 그룹 복제는 트랜잭션을 실제로 처리했는지 까지는 확인하지 않는다는 점에서 반동기로 분류할 수 있으나, 기존의 반동기 방식과는 전혀 다르게 동작한다.
• 이러한 과정을 Consensus(합의)라고 부른다.
• TMI : 이 합의 알고리즘은 컴퓨터 사이언스 분야에서 굉장히 많이 쓰이는 알고리즘이며 대표적으로 주키퍼에서 사용하는 Raft 알고리즘이 대표적인 합의 알고리즘이다. (라고 썼는데 책 뒤편에 Raft랑 Paxos가 나오네... ㅋ)

Group Replication Mode

• 프라이머리 서버 수에 따라 싱글 프라이머리 모드, 멀티 프라이머리 모드 두 가지가 존재.
• 8.0.13 버전부터는 그룹에 참여하고 있는 구성원들이 모드를 변경이 가능하다.
• 단, 그룹 내의 구성원들이 반드시 그룹 복제에 설정된 모드값과 MySQL 서버의 시스템 변수가 동일한 모드 값으로 설정되어있어야 동작한다.

싱글 프라이머리 모드

• 쓰기를 담당하는 서버가 하나인 경우.
• 프라이머리 서버가 그룹을 탈퇴하거나, 특정 멤버를 새로운 프라이머리로 지정하는 경우 그룹 내 프라이머리가 바뀔 수 있다.
• 위와 같은 경우가 아닌 경우, 정해진 기준에 따라 프라이머리를 선출하게 된다.
• 첫 번째는, MySQL 서버 버전, 각 멤버의 가중치 값, 그리고 UUID 사전식 순서이다.

멀티 프라이머리 모드

• 그룹 복제에서 그룹 멤버들이 전부 프라이머리로 동작하는 형태이다.
• 멀티 프라이머리 모드에서는 각각의 MySQL 서버들 간의 데이터 동기화를 위한 복제 작업이 필요할텐데 이게 어째 비효율적 인 것 처럼 느껴지는건 나만 그런건가..?
• 싱글 프라이머리 모드에서는 사실, 쓰기를 담당하는 프라이머리 MySQL 서버를 다른 세컨더리 서버들이 바라보기만 하면 되는 구조인데, 멀티 프라이머리에서는 서로 서로 계속 확인하는 작업이 필요하다보니, 이게 좀 비효율적이지 않나? 라는 생각이 든다.
• 아무래도 비교적 최근에 나온 ES의 샤드, 레플리카 모델을 생각해봤을 때 비효율적이라는 느낌을 지울 수 없다. (그런 내용은 언급이 안된 점이 아쉽다.)

그룹 멤버 관리

• 그룹 복제에서는 어떤 서버들이 그룹에 참여 중인지 목록과 상태 정보를 내부적으로 관리하고 있다.
• performance_schema의 replication_group_members 테이블을 통해 그 목록을 확인할 수 있다.
• 특히 여기서 View ID가 중요한데, 이는 일종에 Git의 커밋로그처럼 그룹 멤버가 변경될 때 마다 새로운 View ID값이 일괄적으로 부여된다.
• 그룹 복제는 이 View ID를 통해 뷰의 변경을 추적하고 뷰가 변경된 시점을 구분할 수 있다.

그룹 복제에서의 트랜잭션 관리

• 그룹 복제에서의 트랜잭션은 다음의 두 단계를 거쳐 최종적으로 그룹의 각 서버들에게 적용된다.
• 합의(Consensus)
• 인증(Certification)

합의 과정

• 한 클라이언트가 커밋 요청을 보내면, 그룹 내의 다른 멤버들이 해당 트랜잭션을 커밋할지에 대한 합의 과정을 거침.
• 이 때 Paxos 기반 프로토콜을 사용하며, 최종적으로 합의가 완료되어 트랜잭션이 실행된 멤버에서 과반수 이상의 멤버들로부터 응답을 받으면 해당 멤버는 그 다음 프로세스를 진행한다.
• 만약 과반수 이상의 응답을 못받으면 해당 트랜잭션은 실패되고 클라이언트는 에러를 받는다.

인증 과정

• 트랜잭션 충돌 여부를 검증하기 위한 과정이다.
• 아무래도 멀티 프라이머리 모드에서 발생하는 상황이며(역시...) 트랜잭션 충돌이 감지되면 롤백된다.
• 따라서 트랜잭션 충돌이 빈번한 상황이라면 싱글 프라이머리 모드를 쓰는게 더 낫다.

그룹 복제의 자동 장애 감지 및 대응

• 그룹 복제에서는 일부 멤버가 장애가 발생해 응답 불능에 빠지면 그룹이 정상적으로 복구될 수 있게 하는 장애 감지 매커니즘이 존재함.
• 그룹 복제에서 멤버들은 주기적으로 통신 메시지를 서로 주고받으며 상태를 확인하는데, 5초 내로 메시지를 못받으면 문제가 생긴 것으로 의심함.
• 장애가 의심되는 멤버가 있다고 의심되는 경우 과반수 이상의 멤버가 동의하면 추방된다.
• 추방된 멤버는 다시 그룹에 가입될 때 자신의 View ID가 다른 것으로 자신이 추방되었음을 인지할 수 있지만, 다른 그룹 멤버들과 통신이 계속 안되면 끝까지 모른다.

그룹 복제의 분산 복구

• 멤버가 그룹에 새로 가입하거나 탈퇴 후 다시 가입할 때, 잠시 그룹을 떠나있는 동안 그룹에 적용된 트랜잭션이 있을 수 있다.
• 멤버는 이러한 트랜잭션들을 모두 적용해야 다른 그룹 멤버들이 가진 데이터와 동일한 데이터를 갖게 된다.
• 그래서 가입 멤버에서 누락된 트랜잭션을 다른 그룹 멤버에서 가져와 적용하는 복구 프로세스를 자동으로 수행하는데 이를 분산 복구라 한다.
• 분산 복구는 크게 바이너리 로그 복제 방식과 원격 클론 방식이 있다.
• 바이너리 로그는 잘 알거고, 원격 클론 방식은 클론 플러그인을 사용하는 형태로 다른 그룹 멤버의 InnoDB 스토리지 엔진에 저장된 모든 데이터와 메타데이터를 일관된 스냅숏으로 가져와 가입 멤버를 재구축하는 방식이다.

MySQL 셸

• 자바스크립트, 파이썬 제공.

MySQL Router

• 클라이언트와 MySQL 서버 중간에 위치한 프록시 역할을 수행하는 계층.
• 쿼리 부하분산, 자동 페일오버, MySQL 구성 변경 자동 감지등의 역할을 수행한다. ( LB + 서비스 디스커버리 )

[DaehunGwak]

공유 포인트

• InnoDB 클러스터 그룹 복제

  • 기존 복제와 비교했을 때 차이

  • 그룹 복제는 복제에 참여하는 서버들이 묶여 서로 통신하며 양방향으로 복제 처리 가능

  • 복제 처리 시 한 서버에서 트랜잭션을 수행 → 커밋하기 전에 멤버 서버들에게 합의 과정 (기존 복제와 가장 큰 차이) → 과반수 이상 통과되면 별도로 각 서버들이 인증 과정을 진행 → 충돌이 없을 시 트랜잭션을 반영함

  • 그룹 복제를 안정적으로 운용하기 위한 권장 서버 수: n = 2f + 1

  • n: 전체 서버 수

  • f: 허용 하고자 하는 장애 서버 수

  • 합의가 적절히 수행되기 위해서는 과반수 이상이 정상적으로 참여해야 하므로 2f + 1

    • f 수만큼을 잃어도 f + 1 이기 때문에 과반수가 됨

  • 싱글 프라이머리 모드 시 사용되는 group_replication_member_weight 의 역할은 프라이머리 선출에서만 사용

    https://dev.mysql.com/blog-archive/group-replication-prioritise-member-for-the-primary-member-election/ 에 따르면

    With the MySQL Server 8.0.2, a new system variable  group_replication_member_weight   is introduced, having integer value between 0 and 100, to influence the primary member election in Single-Primary mode.

    위 의미로 보아 싱글 프라이머리 모드의 새로운 프라이머리 선출에서만 사용되는 값으로 보인다. 각 서버마다 들어가 값을 부여하여 사용하는 방식이다.

  • 흐름 제어를 통해 그룹에서 가장 뒤처진 멤버가 처리할 수 있는 수준으로 처리량을 조절해서 부하 조절 자동으로 수행

  • 그룹 복제 요구 사항에 ROW 형태 바이너리 로그 포맷 사용 이 존재 → 결국 Query 모드나 Mixed 모드는 현재 그룹 복제에서 사용 불가 → 바이너리 로그 포맷 최적화는 압축에 신경 써야할 듯

요약 노트

정리하다보니 요약이 아니게 된 것 같기도...

• https://first-diadem-378.notion.site/17-InnoDB-17-1-17-4-e71fe34d13cf4c31adda9d2d767c380e

[Edwin222]

Inno DB 클러스터 아키텍처

• 셸/클라이언트가 바깥, 중간에 라우터가 있고 라우터를 통해 그룹 복제 구성된 서버에 접근.

그룹 복제

• 원형 복제 토폴로지라고 첫 머리와 그림에서부터 언급하고 있다. 전에 민국님이 언급한 MySQL의 기본 복제 토폴로직이란 이걸 지칭하는 듯.

• 인증에서의 오버헤드가 성능에 영향이 있을까?

  • 대부분의 CS 문제들은 다항 시간 안에 "검산"하기는 쉬우므로 별 영향 없을 것 같다

• 복제 모드

  • 프라이머리 갯수에 따라 싱글/멀티

• 트랜잭션 처리

  • 과반수 이상의 멤버가 트랜잭션을 인증하면 커밋 처리를 완료
  • 잡설: 이걸 프라이빗 머신 내에서 하는게 아니라, 누구나 참여할 수 있게 만들면 블록체인이 된다

• 일관성

  • EVENTUAL: 언젠가는 같아질 것이다

  • BEFORE ON PRIMARY FAILOVER: 싱글 프라이머리에서 페일오버로 새 프라이머리가 선정되면, 새 프라이머리가 이전 프라이머리에서 했었던 모든 트랜잭션을 끝낼때까지 연산 정지

  • 프라이머리의 일관성을 보장

  • BEFORE: 모든 트랜잭션은 선행 트랜잭션 끝나기 전까지 대기.

  • AFTER: 트랜잭셩 적용 후 시점에 모두 같은 데이터를 갖게 보장.

  • BEFORE AND AFTER: BEFORE + AFTER.

• 장애처리

  • 주기적 하트비트 후 응답없으면 그룹에서 추방시킴

MY SQL 셸

• 확장된 MySQL 클라. 별로 설명할 게 없다.

MY SQL 라우터

• 클라 요청을 서버에 전달하는 프록시. 상세 내용은 나중에 다루는가보다