24시간 365일 서비스를 위한 MySQL DB 이중화.
MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다.
목차
1. DB 이중화 필요성
2. 이중화 방안
- HW 이중화
- MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교
대상
- MySQL을 서비스하고 있는 인프라 담당자
- MySQL 이중화에 관심 있는 개발자
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 변경 )
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 이중화 한계
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 이중화
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)
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
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
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
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 도입
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 이중화 비교