1.
© 2018 NHN FORWARD. All rights reserved.
MySQL 이중화 진화기
박노을
데이터운영팀

2.
CONTENTS
1. DB 이중화 필요성
2. 이중화 방안
 HW 이중화
 MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교

3.
DB 이중화 필요성

4.
4 / 73
DB Single 구성
192.168.10.1
URL= jdbc:mysql://192.168.10.1:3306
MySQL

5.
5 / 73
URL= jdbc:mysql://192.168.10.1:3306
MySQL
DB Single 구성
192.168.10.1
DB 서버 복구 시간 = 장애 시간

6.
6 / 73
DB 복제 구성
192.168.10.1
Master
URL= jdbc:mysql://192.168.10.1:3306
Slave
192.168.10.2

7.
7 / 73
Master
URL= jdbc:mysql://192.168.10.1:3306
Slave
DB 복제 구성
192.168.10.1 192.168.10.2

8.
8 / 73
Master
URL= jdbc:mysql://192.168.10.1:3306
Slave
192.168.10.2
DB 복제 구성
192.168.10.1 192.168.10.2

9.
9 / 73
DB 복제 구성
장애 대응:
 장애 인지 및 현상 파악: SE/DBA
 장애 개발팀에 공유: SE/DBA
 DB 커넥션 변경: 개발팀
배포 시간 소요 및 여러 팀 협업 필요
SE DBA DEV

10.
10 / 73
VIP: 192.168.10.100
Master
URL= jdbc:mysql://192.168.10.100:3306
Slave
DB 복제 구성 + VIP

11.
11 / 73
VIP: 192.168.10.100
Master
URL= jdbc:mysql://192.168.10.100:3306
Slave
DB 복제 구성 + VIP

12.
12 / 73
VIP: 192.168.10.100
URL= jdbc:mysql://192.168.10.100:3306
DB 복제 구성 + VIP
Master Slave

13.
13 / 73
DB 복제 구성 + VIP + 자동화
요구 사항:
 MySQL DBA 5명 / 관리 MySQL DB 대수는 500대
 업무시간 외에도 장애 대응 필요
 주기적으로 DB서버의 Health Check
 문제시 자동으로 FAILOVER(커넥션 관리 및 VIP 변경 )

14.
DB 이중화 방안
> HW 이중화

15.
15 / 73
HW 이중화
SHARED DISK 방식
 예: OS Cluster( RHCS )
특징
 Master(Active) 서버 장애 시 Master(Standby) 서버로 FAILOVER
Master(Active) Master(Standby)
MySQL
Master(Active) Master(Standby)
MySQL
VIP VIP

16.
16 / 73
HW 이중화
SHARED DISK 방식
 예: OS Cluster( RHCS )
문제점
 RHCS 솔루션 구매 필요
 고비용의 SHARED DISK 필요
Master(Active) Master(Standby)
MySQL

17.
17 / 73
HW 이중화
DISK 복제 방식
 DRBD + Corosync + Pacemaker
특징
 네트워크 RAID 1 ( 네트워크를 통한 디스크 복제 )
 SHARED-DISK 방식에 비해 license, 고성능의 DISK 없이 사용 가능
Master(Active) Master(Standby)
MySQL
SYNC
Master(Active) Master(Standby)
MySQL
SYNC
VIP VIP

18.
18 / 73
HW 이중화
DISK 복제 방식
 DRBD + Corosync + Pacemaker
문제점
 Network Latency 에 의해 성능 영향을 받음
Master(Active) Master(Standby)
MySQL
SYNC

19.
19 / 73
공통 사항
 Stand by 서버의 경우 FAILOVER시 에만 사용 가능
 백업을 위한 추가 서버 필요.
 유지보수 및 장애대응 어려움
( OS 및 하드웨어에 대한 지식 필요 )
HW 이중화 한계

20.
DB 이중화 방안
> MySQL Replication 이중화

21.
21 / 73
복제 구성 로그
Binary Log : Master에 실행되는 모든 DML/DDL 를 기록
Relay Log: Binary Log에 내용을 Slave 에 기록
MySQL Replication
INSERT
INTOMySQL
INSERT
INTO
Relay log
INSERT INTO
SQL> INSERT INTO
Binary log
Master Slave
MySQL

22.
22 / 73
복제 구성 로그
Binary Log : Master에 실행되는 모든 DML/DDL 를 기록
Relay Log: Binary Log에 내용을 Slave 에 기록
MySQL Replication
INSERT
INTOMySQL
INSERT
INTO
Binary log Relay log
MySQL
INSERT INTO
SQL> INSERT INTO
Master Slave

23.
23 / 73
MySQL Replication 일관성 보장
INSERT
INTO
Binary log
1
SQL> INSERT INTO
ACK
OK
MySQL
INSERT
INTO
Relay log
Master Slave
Master의 변경사항이 Slave의 Relay log 에 작성됨을 보장
 5.5 이후 Semi-replication
 5.7.2 이후 Loss-less replication
MySQL

24.
24 / 73
Master의 변경사항이 Slave의 Relay log에 작성됨을 보장
 5.5 이후 Semi-replication
 5.7.2 이후 Loss-less replication
MySQL Replication 일관성 보장
INSERT
INTO
Binary log
SQL> INSERT INTO
2
ACK
OK
MySQL
INSERT
INTO
Relay log
Master Slave
MySQL

25.
25 / 73
MySQL Replication 일관성 보장
Master의 변경사항이 Slave의 Relay log 에 작성됨을 보장
 5.5 이후 Semi-replication
 5.7.2 이후 Loss-less replication
INSERT
INTO
Binary log
SQL> INSERT INTO
3
5 ACK
6 OK
MySQL
INSERT
INTO
Relay log
MySQL
Requests
a packet
Master Slave

26.
26 / 73
MySQL Replication 일관성 보장
Master의 변경사항이 Slave의 Relay log 에 작성됨을 보장
 5.5 이후 Semi-replication
 5.7.2이후 Loss-less replication
INSERT
INTO
Binary log
SQL> INSERT INTO
5 ACK
6 OK
MySQL
INSERT
INTO
Relay log
Master Slave
4
Sends the packet
Wait ACK
MySQL

27.
27 / 73
MySQL Replication 일관성 보장
Master의 변경사항이 Slave의 Relay log 에 작성됨을 보장
 5.5 이후 Semi-replication
 5.7.2 이후 Loss-less replication
INSERT
INTO
Binary log
SQL> INSERT INTO
5 ACK
6 OK
MySQL
INSERT
INTO
Relay log
Master Slave
MySQL

28.
28 / 73
MySQL Replication 일관성 보장
Master의 변경사항이 Slave의 Relay log 에 작성됨을 보장
 5.5 이후 Semi-replication
 5.7.2 이후 Loss-less replication
INSERT
INTO
Binary log
SQL> INSERT INTO
6 OK
MySQL
INSERT
INTO
Relay log
Master Slave
MySQL

29.
29 / 73
MySQL Replication 일관성 보장
Multi-Slave 환경
 모든 slave의 relay log 파일에 전달
INSERT
INTO INSERT
INTO
Binary log
Relay log
SQL> INSERT INTO Relay log
Master
Slave-1
INSERT
INTO
Slave-2
MySQL Wait ACK
Wait ACK
MySQL
MySQL

30.
30 / 73
MySQL Replication 일관성 보장
Multi-Slave 환경
 하나의 Relay log 파일에 작성되면 완료
INSERT
INTO INSERT
INTO
Binary log
Relay log
SQL> INSERT INTO
OK
Relay log
Master
Slave-1
INSERT
INTO
Slave-2
MySQL
MySQL
MySQL
ACK

31.
31 / 73
MMM(Multi-Master Replication Manager)
 Perl 기반의 Auto Failover Open Source
 MMM Monitor에서 DB서버 health check와 FAILOVER를 수행
 Monitor <-> Agent 통신방식
 NHN에서 대부분 운영중인 이중화 방안
250개의 HA ( MySQL DB 서버 560 대 )
MySQL Replication 이중화

32.
32 / 73
MMM 구조(기본 구성)
 Master(Active) 와 Master(Standby) 양방향 복제
MySQL Replication 이중화
Master
(Active)
Master
(Standby)
읽기모드
MMM Monitor

33.
33 / 73
MMM 구조(slave 추가)
 Master(Active) 와 Master(Standby) 양방향 복제 + Slave
MySQL Replication 이중화
Slave
MMM Monitor
읽기모드
읽기모드
Master
(Active)
Master
(Standby)

34.
34 / 73
MMM FAILOVER 과정
MySQL Replication 이중화
Slave
MMM Monitor
Master
(Active)
VIP
Master
(Standby)

35.
35 / 73
MMM FAILOVER 과정
 장애가 발생한 DB 에 데이터 변경이 되지 않도록 읽기 모드 활성화한다.
MySQL Replication 이중화
Slave
MMM Monitor
Master
(Active)
Master
(Standby)
VIP
읽기 모드로 변경
SESSION KILL
VIP 회수

36.
36 / 73
MMM FAILOVER 과정
 장애가 발생한 DB에 접속 세션을 kill 한다.
MySQL Replication 이중화
Slave
MMM Monitor
Master
(Active)
VIP
읽기 모드로 변경
SESSION KILL
Master
(Standby)
VIP 회수

37.
37 / 73
MMM FAILOVER 과정
 장애가 발생한 DB에 접속이 되지 않도록 VIP 회수
MySQL Replication 이중화
Slave
MMM Monitor
Master
(Active)
VIP
읽기 모드로 변경
SESSION KILL
VIP 회수
Master
(Standby)

38.
38 / 73
MMM FAILOVER 과정
 복제 지연 여부 확인 및 대기
MySQL Replication 이중화
MMM Monitor
Master
(Active) 복제지연 확인
Slave
Master
(Standby)
복제 재구성

39.
39 / 73
MMM FAILOVER 과정
 Master(Standby)를 신규 마스터로 복제 재구성
MySQL Replication 이중화
MMM Monitor
Master
(Active)
Master
(Standby)
복제 재구성
Slave
복제지연 확인

40.
40 / 73
MMM FAILOVER 과정
 신규 마스터로 승격시키기 위해 Master(Standby)를 읽기 모드 해제
MySQL Replication 이중화
MMM Monitor
읽기 모드 해제
Slave
Master
(Active)
Master
(Standby)
VIP 할당

41.
41 / 73
MMM FAILOVER 과정
 신규 마스터에 VIP 할당
MySQL Replication 이중화
MMM Monitor
VIP
Slave
Master
(Active)
읽기 모드 해제
VIP 할당
Master
(Standby)

42.
42 / 73
MMM FAILOVER 과정
 FAILOVER 완료
MySQL Replication 이중화
MMM Monitor
VIP
Slave
읽기 모드 해제
VIP 할당
FAILOVER 완료
Master
(Active)

43.
43 / 73
MMM FAILOVER 대상
 Master(Active) / Master(Standby) 양방향 복제
 Master(Active) -> Master(Standby)
MySQL Replication 이중화
Master
(Active)
Master
(Standby)
MMM Monitor
Slave

44.
44 / 73
MMM FAILOVER 후속 처리
 Master(Active) / Master(Standby) 양방향 복제
MySQL Replication 이중화
Master
(Active)
Master
(Standby)
Slave
192.168.10.1 192.168.10.2
192.168.10.3
Master
(Standby)
Master
(Active)
Slave
192.168.10.1 192.168.10.2
192.168.10.3

45.
45 / 73
MMM FAILOVER 예시
 마스터의 변경사항을 slave에 보내고, 응답을 기다림
MySQL Replication 이중화
SlaveMaster(Active)
Binary
log
Relay
Log
Master(Standby)
Relay
Log
SQL> INSERT INTO tab
Values(101,’B’);
101 B Wait ACK
Wait ACK
101 B

46.
46 / 73
MMM FAILOVER 예시
 Multi Slave 중에 하나의 서버에서 응답을 받으면 OK 반환
MySQL Replication 이중화
SlaveMaster(Active)
Binary
log
Relay
Log
Master(Standby)
Relay
Log
ACK
SQL> INSERT INTO tab
Values(101,’B’);
101 B
101 B

47.
47 / 73
MMM FAILOVER 예시
 신규 Master DB는 Relay log 전달 못 받은 상태에서 Master 장애
 MMM의 Failover 대상은 지정됨.
MySQL Replication 이중화
SlaveMaster(Active)
Binary
log
Relay
Log
Master(Standby)
Relay
Log
ACK
101 B
101 B
SQL> INSERT INTO tab
Values(101,’B’);

48.
48 / 73
MMM FAILOVER 예시
 MMM의 Failover 대상은 지정된 상태.
 이 경우 101이 전달이 되지 않은 상태에서 신규 마스터로 승격됨.
MySQL Replication 이중화
SlaveMaster(Active)
Binary
log
Relay
Log
Master
Relay
Log
seq name
100 A
101 B
seq name
100 A
101 B
SQL> INSERT INTO tab
Values(101,’B’);

49.
49 / 73
MMM FAILOVER 문제
 Multi Slave 환경에서 복제 Crash 가능성 존재
MySQL Replication 이중화

50.
50 / 73
MHA(Master High Availability)
 Perl 기반의 Auto Failover open source
 MySQL 의 GTID 등 신 버전의 기능들을 지원.
2011년 7월 0.50 버전 발표
2015년 5월 0.57 버전 발표
 MHA Monitor 에서 Master DB서버의 Health 체크와 FAILOVER 관리
 Agentless 방식
MySQL Replication 이중화

51.
51 / 73
MHA 구조
 Master + Slave 구조 / 모두 단 방향 복제
MySQL Replication 이중화
Master
MHA Monitor
Slave
Slave

52.
52 / 73
MHA FAILOVER 후속 처리
 Master / Slave 단방향 복제
MySQL Replication 이중화
Master slave
Slave
192.168.10.1 192.168.10.2
192.168.10.3
Master Master
Slave
192.168.10.1 192.168.10.2
192.168.10.3

53.
53 / 73
MySQL Replication 이중화
MHA Failover 대상
 가장 최신의 동기화 상태의 Slave 선택
Master
Position
: 300
Position
: 200
Position
: 300
Slave-1
Slave-2
seq name
100 A
101 B
seq name
100 A
101 B
seq name
100 A

54.
54 / 73
MySQL Replication 이중화
MHA Failover 시 복제 일관성 해결
 Binary log와 Relay log를 비교해서 차이 나는 이벤트를 추출
Master
Slave-2
MHA Monitor
Slave-1
Relay
Log
Binary
log
Relay
Log

55.
55 / 73
MySQL Replication 이중화
MHA Failover 시 복제 일관성 해결
 DB간 차이 나는 이벤트를 DB에 반영
Slave-2
MHA Monitor
Slave-1
seq name
100 A
seq name
100 A
101 B
seq name
100 A
101 B
101 BRelay
Log
Binary
log
Relay
Log
Master

56.
56 / 73
MySQL Replication 이중화
MHA Failover 시 복제 일관성 해결
 DB간 일관성 보장
Slave-2
MHA Monitor
Slave-1
seq name
100 A
101 B
seq name
100 A
101 B
seq name
100 A
101 B
Master

57.
이중화 운영 장애

58.
58 / 73
MMM Monitor 에서 Master 서버 접속 불가
MMM - 네트워크 전면 장애
Master
(Active)
Master
(Standby)
MMM Monitor
Master
(Active)
Master
(Standby)
Master
(Active)
Master
(Standby)

59.
59 / 73
FAILOVER 실패
MMM - 네트워크 장애로 인한 VIP 이슈
Master 읽기 모드 설정
Master connection kill
Master VIP 제거
New Master 로 slave 복제 재구성
New Master 읽기 모드 해제
New Master VIP 할당
VIP 유실

60.
60 / 73
FAILOVER 실패
MMM - 네트워크 장애로 인한 VIP 이슈
Master 읽기 모드 설정
Master connection kill
Master VIP 제거
New Master 로 slave 복제 재구성
New Master 읽기 모드 해제
New Master VIP 할당
 VIP 유실 / 중복 할당
 읽기 모드 해제 X
 복제 crash

61.
61 / 73
MHA – secondary check
MHA Monitor
MasterSlave
Secondary
Host
Health
Check
A
B

62.
62 / 73
MHA – secondary check
MHA Monitor
Secondary
Host
Health
Check
Slave Master
A
B

63.
63 / 73
MHA – secondary check
MHA Monitor
Secondary
Host
Health
Check
OK
Slave Master
B
A

64.
64 / 73
MHA – secondary check
MHA Monitor
Secondary
Host
Health
Check
Slave Master
A

65.
VIP vs DNS

66.
66 / 73
Broad Cast 도메인 내에서만(L2영역) 구성 가능
 판교 IDC와 평촌 IDC와의 이중화
VIP 이중화 제약 사항
VIP 이중화
Master(Active) Master(Standby)

67.
67 / 73
VIP 이슈 해결
 DNS의 도메인 IP를 변경함으로써 다른 네트워크 간에 이중화 가능
 판교 IDC와 평촌 IDC HA 구성 가능
 Cloud 환경에 Zone 간의 HA 구성 가능
 Toast RDS에 DNS + MHA 적용
 DNS는 UPDATE 방식으로 중복 할당 / 유실 가능성 없음.
DNS 도입
MMM + VIP MHA + DNS

68.
68 / 73
개발팀의 변경 사항 ?
DNS 도입
URL= jdbc:mysql://10.161.10.2:13306
URL= jdbc:mysql://service.toastmaker.net:13306
 TTL : 0 ( java인 경우 )

69.
69 / 73
DNS 이슈
 DNS 변경 API 호출 시간만( 4~ 6초 소요 )
 DNS Caching으로 인해 지연 가능성 있음.
 VIP의 경우 arp 갱신 0.01초
DNS 도입

70.
© 2018 NHN FORWARD. All rights reserved.
MySQL 이중화 비교

71.
71 / 73
항목 MMM MHA
DRBD
(디스크 복제)
RHCS
(shared-disk)
VIP / DNS VIP DNS VIP VIP
데이터 정합성 보장 △ O △ O
네트워크 장애 시
FAILOVER 방지
X O X X
비용 open-source open-source open-source 고비용
재구성 작업 X O X X
서비스 성격 서비스 운영 > 데이터 정합성 > 서비스 운영 > 데이터 정합성 >
 VIP/DNS 지원 여부: 회사 표준을 기반으로 작성되었습니다.
MySQL 이중화 비교

72.
© 2018 NHN FORWARD. All rights reserved.
Q&A

73.
© 2018 NHN FORWARD. All rights reserved.
THANK YOU