KEMBAR78
[2018] MySQL 이중화 진화기 | PDF
NHN FORWARD, profile picture
Uploaded byNHN FORWARD
PDF, PPTX11,954 views

[2018] MySQL 이중화 진화기

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

Download as PDF, PPTX
© 2018 NHN FORWARD. All rights reserved. MySQL 이중화 진화기 박노을 데이터운영팀
CONTENTS 1. DB 이중화 필요성 2. 이중화 방안  HW 이중화  MySQL Replication 이중화 3. 이중화 운영 장애 4. DNS와 VIP 5. MySQL 이중화 솔루션 비교
DB 이중화 필요성
4 / 73 DB Single 구성 192.168.10.1 URL= jdbc:mysql://192.168.10.1:3306 MySQL
5 / 73 URL= jdbc:mysql://192.168.10.1:3306 MySQL DB Single 구성 192.168.10.1 DB 서버 복구 시간 = 장애 시간
6 / 73 DB 복제 구성 192.168.10.1 Master URL= jdbc:mysql://192.168.10.1:3306 Slave 192.168.10.2
7 / 73 Master URL= jdbc:mysql://192.168.10.1:3306 Slave DB 복제 구성 192.168.10.1 192.168.10.2
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 / 73 DB 복제 구성 장애 대응:  장애 인지 및 현상 파악: SE/DBA  장애 개발팀에 공유: SE/DBA  DB 커넥션 변경: 개발팀 배포 시간 소요 및 여러 팀 협업 필요 SE DBA DEV
10 / 73 VIP: 192.168.10.100 Master URL= jdbc:mysql://192.168.10.100:3306 Slave DB 복제 구성 + VIP
11 / 73 VIP: 192.168.10.100 Master URL= jdbc:mysql://192.168.10.100:3306 Slave DB 복제 구성 + VIP
12 / 73 VIP: 192.168.10.100 URL= jdbc:mysql://192.168.10.100:3306 DB 복제 구성 + VIP Master Slave
13 / 73 DB 복제 구성 + VIP + 자동화 요구 사항:  MySQL DBA 5명 / 관리 MySQL DB 대수는 500대  업무시간 외에도 장애 대응 필요  주기적으로 DB서버의 Health Check  문제시 자동으로 FAILOVER(커넥션 관리 및 VIP 변경 )
DB 이중화 방안 > HW 이중화
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 / 73 HW 이중화 SHARED DISK 방식  예: OS Cluster( RHCS ) 문제점  RHCS 솔루션 구매 필요  고비용의 SHARED DISK 필요 Master(Active) Master(Standby) MySQL
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 / 73 HW 이중화 DISK 복제 방식  DRBD + Corosync + Pacemaker 문제점  Network Latency 에 의해 성능 영향을 받음 Master(Active) Master(Standby) MySQL SYNC
19 / 73 공통 사항  Stand by 서버의 경우 FAILOVER시 에만 사용 가능  백업을 위한 추가 서버 필요.  유지보수 및 장애대응 어려움 ( OS 및 하드웨어에 대한 지식 필요 ) HW 이중화 한계
DB 이중화 방안 > MySQL Replication 이중화
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 / 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 / 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 / 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 / 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 / 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 / 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 / 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 / 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 / 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 / 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 / 73 MMM 구조(기본 구성)  Master(Active) 와 Master(Standby) 양방향 복제 MySQL Replication 이중화 Master (Active) Master (Standby) 읽기모드 MMM Monitor
33 / 73 MMM 구조(slave 추가)  Master(Active) 와 Master(Standby) 양방향 복제 + Slave MySQL Replication 이중화 Slave MMM Monitor 읽기모드 읽기모드 Master (Active) Master (Standby)
34 / 73 MMM FAILOVER 과정 MySQL Replication 이중화 Slave MMM Monitor Master (Active) VIP Master (Standby)
35 / 73 MMM FAILOVER 과정  장애가 발생한 DB 에 데이터 변경이 되지 않도록 읽기 모드 활성화한다. MySQL Replication 이중화 Slave MMM Monitor Master (Active) Master (Standby) VIP 읽기 모드로 변경 SESSION KILL VIP 회수
36 / 73 MMM FAILOVER 과정  장애가 발생한 DB에 접속 세션을 kill 한다. MySQL Replication 이중화 Slave MMM Monitor Master (Active) VIP 읽기 모드로 변경 SESSION KILL Master (Standby) VIP 회수
37 / 73 MMM FAILOVER 과정  장애가 발생한 DB에 접속이 되지 않도록 VIP 회수 MySQL Replication 이중화 Slave MMM Monitor Master (Active) VIP 읽기 모드로 변경 SESSION KILL VIP 회수 Master (Standby)
38 / 73 MMM FAILOVER 과정  복제 지연 여부 확인 및 대기 MySQL Replication 이중화 MMM Monitor Master (Active) 복제지연 확인 Slave Master (Standby) 복제 재구성
39 / 73 MMM FAILOVER 과정  Master(Standby)를 신규 마스터로 복제 재구성 MySQL Replication 이중화 MMM Monitor Master (Active) Master (Standby) 복제 재구성 Slave 복제지연 확인
40 / 73 MMM FAILOVER 과정  신규 마스터로 승격시키기 위해 Master(Standby)를 읽기 모드 해제 MySQL Replication 이중화 MMM Monitor 읽기 모드 해제 Slave Master (Active) Master (Standby) VIP 할당
41 / 73 MMM FAILOVER 과정  신규 마스터에 VIP 할당 MySQL Replication 이중화 MMM Monitor VIP Slave Master (Active) 읽기 모드 해제 VIP 할당 Master (Standby)
42 / 73 MMM FAILOVER 과정  FAILOVER 완료 MySQL Replication 이중화 MMM Monitor VIP Slave 읽기 모드 해제 VIP 할당 FAILOVER 완료 Master (Active)
43 / 73 MMM FAILOVER 대상  Master(Active) / Master(Standby) 양방향 복제  Master(Active) -> Master(Standby) MySQL Replication 이중화 Master (Active) Master (Standby) MMM Monitor Slave
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 / 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 / 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 / 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 / 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 / 73 MMM FAILOVER 문제  Multi Slave 환경에서 복제 Crash 가능성 존재 MySQL Replication 이중화
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 / 73 MHA 구조  Master + Slave 구조 / 모두 단 방향 복제 MySQL Replication 이중화 Master MHA Monitor Slave Slave
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 / 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 / 73 MySQL Replication 이중화 MHA Failover 시 복제 일관성 해결  Binary log와 Relay log를 비교해서 차이 나는 이벤트를 추출 Master Slave-2 MHA Monitor Slave-1 Relay Log Binary log Relay Log
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 / 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 / 73 MMM Monitor 에서 Master 서버 접속 불가 MMM - 네트워크 전면 장애 Master (Active) Master (Standby) MMM Monitor Master (Active) Master (Standby) Master (Active) Master (Standby)
59 / 73 FAILOVER 실패 MMM - 네트워크 장애로 인한 VIP 이슈 Master 읽기 모드 설정 Master connection kill Master VIP 제거 New Master 로 slave 복제 재구성 New Master 읽기 모드 해제 New Master VIP 할당 VIP 유실
60 / 73 FAILOVER 실패 MMM - 네트워크 장애로 인한 VIP 이슈 Master 읽기 모드 설정 Master connection kill Master VIP 제거 New Master 로 slave 복제 재구성 New Master 읽기 모드 해제 New Master VIP 할당  VIP 유실 / 중복 할당  읽기 모드 해제 X  복제 crash
61 / 73 MHA – secondary check MHA Monitor MasterSlave Secondary Host Health Check A B
62 / 73 MHA – secondary check MHA Monitor Secondary Host Health Check Slave Master A B
63 / 73 MHA – secondary check MHA Monitor Secondary Host Health Check OK Slave Master B A
64 / 73 MHA – secondary check MHA Monitor Secondary Host Health Check Slave Master A
VIP vs DNS
66 / 73 Broad Cast 도메인 내에서만(L2영역) 구성 가능  판교 IDC와 평촌 IDC와의 이중화 VIP 이중화 제약 사항 VIP 이중화 Master(Active) Master(Standby)
67 / 73 VIP 이슈 해결  DNS의 도메인 IP를 변경함으로써 다른 네트워크 간에 이중화 가능  판교 IDC와 평촌 IDC HA 구성 가능  Cloud 환경에 Zone 간의 HA 구성 가능  Toast RDS에 DNS + MHA 적용  DNS는 UPDATE 방식으로 중복 할당 / 유실 가능성 없음. DNS 도입 MMM + VIP MHA + DNS
68 / 73 개발팀의 변경 사항 ? DNS 도입 URL= jdbc:mysql://10.161.10.2:13306 URL= jdbc:mysql://service.toastmaker.net:13306  TTL : 0 ( java인 경우 )
69 / 73 DNS 이슈  DNS 변경 API 호출 시간만( 4~ 6초 소요 )  DNS Caching으로 인해 지연 가능성 있음.  VIP의 경우 arp 갱신 0.01초 DNS 도입
© 2018 NHN FORWARD. All rights reserved. MySQL 이중화 비교
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 이중화 비교
© 2018 NHN FORWARD. All rights reserved. Q&A
© 2018 NHN FORWARD. All rights reserved. THANK YOU

More Related Content

PDF
MySQL Administrator 2021 - 네오클로바
byNeoClova
 
DOCX
MySQL_SQL_Tunning_v0.1.3.docx
byNeoClova
 
PDF
MariaDB 제품 소개
byNeoClova
 
PDF
MariaDB 10.5 binary install (바이너리 설치)
byNeoClova
 
PDF
MariaDB Administrator 교육
bySangmo Kim
 
PDF
MySQL Advanced Administrator 2021 - 네오클로바
byNeoClova
 
PDF
MariaDB 마이그레이션 - 네오클로바
byNeoClova
 
PPTX
MySQL_MariaDB로의_전환_기술요소-202212.pptx
byNeoClova
 
MySQL Administrator 2021 - 네오클로바
byNeoClova
 
MySQL_SQL_Tunning_v0.1.3.docx
byNeoClova
 
MariaDB 제품 소개
byNeoClova
 
MariaDB 10.5 binary install (바이너리 설치)
byNeoClova
 
MariaDB Administrator 교육
bySangmo Kim
 
MySQL Advanced Administrator 2021 - 네오클로바
byNeoClova
 
MariaDB 마이그레이션 - 네오클로바
byNeoClova
 
MySQL_MariaDB로의_전환_기술요소-202212.pptx
byNeoClova
 

What's hot

PPTX
MySQL8.0_performance_schema.pptx
byNeoClova
 
PDF
MySQL GTID 시작하기
byI Goo Lee
 
PDF
MySQL 상태 메시지 분석 및 활용
byI Goo Lee
 
PDF
MySQL/MariaDB Proxy Software Test
byI Goo Lee
 
PDF
Automated master failover
byYoshinori Matsunobu
 
PDF
ProxySQL High Avalability and Configuration Management Overview
byRené Cannaò
 
PPTX
MySQL_MariaDB-성능개선-202201.pptx
byNeoClova
 
PPTX
Maria db 이중화구성_고민하기
byNeoClova
 
PDF
Best Practice for Achieving High Availability in MariaDB
byMariaDB plc
 
PDF
ProxySQL High Availability (Clustering)
byMydbops
 
PDF
Maxscale_메뉴얼
byNeoClova
 
PDF
MySQL Database Architectures - InnoDB ReplicaSet & Cluster
byKenny Gryp
 
PDF
Wars of MySQL Cluster ( InnoDB Cluster VS Galera )
byMydbops
 
PDF
How to set up orchestrator to manage thousands of MySQL servers
bySimon J Mudd
 
PPTX
[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.
byNAVER D2
 
PDF
MariaDB MaxScale monitor 매뉴얼
byNeoClova
 
PDF
ProxySQL and the Tricks Up Its Sleeve - Percona Live 2022.pdf
byJesmar Cannao'
 
ODP
MySQL Group Replication
byUlf Wendel
 
DOCX
Keepalived+MaxScale+MariaDB_운영매뉴얼_1.0.docx
byNeoClova
 
PPTX
Maxscale 소개 1.1.1
byNeoClova
 
MySQL8.0_performance_schema.pptx
byNeoClova
 
MySQL GTID 시작하기
byI Goo Lee
 
MySQL 상태 메시지 분석 및 활용
byI Goo Lee
 
MySQL/MariaDB Proxy Software Test
byI Goo Lee
 
Automated master failover
byYoshinori Matsunobu
 
ProxySQL High Avalability and Configuration Management Overview
byRené Cannaò
 
MySQL_MariaDB-성능개선-202201.pptx
byNeoClova
 
Maria db 이중화구성_고민하기
byNeoClova
 
Best Practice for Achieving High Availability in MariaDB
byMariaDB plc
 
ProxySQL High Availability (Clustering)
byMydbops
 
Maxscale_메뉴얼
byNeoClova
 
MySQL Database Architectures - InnoDB ReplicaSet & Cluster
byKenny Gryp
 
Wars of MySQL Cluster ( InnoDB Cluster VS Galera )
byMydbops
 
How to set up orchestrator to manage thousands of MySQL servers
bySimon J Mudd
 
[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.
byNAVER D2
 
MariaDB MaxScale monitor 매뉴얼
byNeoClova
 
ProxySQL and the Tricks Up Its Sleeve - Percona Live 2022.pdf
byJesmar Cannao'
 
MySQL Group Replication
byUlf Wendel
 
Keepalived+MaxScale+MariaDB_운영매뉴얼_1.0.docx
byNeoClova
 
Maxscale 소개 1.1.1
byNeoClova
 

Similar to [2018] MySQL 이중화 진화기

PPTX
My sql 장애복구
bykidoki
 
PDF
Binlog Servers 구축사례
byI Goo Lee
 
PPTX
Mysql replication
byThreeSnakes
 
PDF
Pgday bdr 천정대
byPgDay.Seoul
 
PPTX
Pgday bdr gt1000
by정대 천
 
PDF
2014.4.30 프라이머 개발자 모임 - 서버 장애 예방 및 대응 방법 공유
byKyoungchan Lee
 
PDF
데이터야 안전하게 놀아보자.V.1
byDongchan Sung
 
PDF
Let's Play with Data Safely
byDataya Nolja
 
PDF
MySQL InnoDB Cluster 소개
byrockplace
 
PDF
[오픈소스컨설팅]Day #1 MySQL 엔진소개, 튜닝, 백업 및 복구, 업그레이드방법
byJi-Woong Choi
 
PDF
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
byAmazon Web Services Korea
 
PDF
Intro KaKao ADT (Almighty Data Transmitter)
byI Goo Lee
 
PDF
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
bySeok-joon Yun
 
PDF
Tungsten 을활용한 MySQL / Hadoop 동기화
byI Goo Lee
 
PPTX
Db optimal solution
byPark SooHyun
 
PDF
[오픈소스컨설팅]Day #3 MySQL Monitoring, Trouble Shooting
byJi-Woong Choi
 
PPT
서버/인프라를 지탱하는 기술
by재훈 정
 
PDF
MySQL Performance Tuning (In Korean)
byOracleMySQL
 
PPT
GoldenGate for MySQL 설치 시 필요한 사항
by정명훈 Jerry Jeong
 
PDF
[ORA클라우드 지식먹방] - #11 개발자 X 오라클 MySQL 클라우드 서비스를 만나다!
byOracle Korea
 
My sql 장애복구
bykidoki
 
Binlog Servers 구축사례
byI Goo Lee
 
Mysql replication
byThreeSnakes
 
Pgday bdr 천정대
byPgDay.Seoul
 
Pgday bdr gt1000
by정대 천
 
2014.4.30 프라이머 개발자 모임 - 서버 장애 예방 및 대응 방법 공유
byKyoungchan Lee
 
데이터야 안전하게 놀아보자.V.1
byDongchan Sung
 
Let's Play with Data Safely
byDataya Nolja
 
MySQL InnoDB Cluster 소개
byrockplace
 
[오픈소스컨설팅]Day #1 MySQL 엔진소개, 튜닝, 백업 및 복구, 업그레이드방법
byJi-Woong Choi
 
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
byAmazon Web Services Korea
 
Intro KaKao ADT (Almighty Data Transmitter)
byI Goo Lee
 
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
bySeok-joon Yun
 
Tungsten 을활용한 MySQL / Hadoop 동기화
byI Goo Lee
 
Db optimal solution
byPark SooHyun
 
[오픈소스컨설팅]Day #3 MySQL Monitoring, Trouble Shooting
byJi-Woong Choi
 
서버/인프라를 지탱하는 기술
by재훈 정
 
MySQL Performance Tuning (In Korean)
byOracleMySQL
 
GoldenGate for MySQL 설치 시 필요한 사항
by정명훈 Jerry Jeong
 
[ORA클라우드 지식먹방] - #11 개발자 X 오라클 MySQL 클라우드 서비스를 만나다!
byOracle Korea
 

More from NHN FORWARD

PDF
[2019] 패션 시소러스 기반 상품 특징 분석 시스템
byNHN FORWARD
 
PDF
[2019] 스몰 스텝: Android 렛츠기릿!
byNHN FORWARD
 
PDF
딥러닝, 야 너도 할 수 있어(feat. PyTorch)
byNHN FORWARD
 
PDF
NHN 베이스캠프: 신입사원들은 무엇을 배우나요?
byNHN FORWARD
 
PDF
[2019] GIF 스티커 만들기: 스파인 2D를 이용한 움직이는 스티커 만들기
byNHN FORWARD
 
PDF
[2019] 전기 먹는 하마의 다이어트 성공기 클라우드 데이터 센터의 에너지 절감 노력과 사례
byNHN FORWARD
 
PDF
[2019] 스몰 스텝: Dooray!를 이용한 업무 효율화/자동화(고객문의 시스템 구축)
byNHN FORWARD
 
PDF
[2019] 아직도 돈 주고 DB 쓰나요? for Developer
byNHN FORWARD
 
PDF
[2019] 아직도 돈 주고 DB 쓰나요 for DBA
byNHN FORWARD
 
PDF
[2019] 비주얼 브랜딩: Basic system
byNHN FORWARD
 
PDF
[2019] PAYCO 매거진 서버 Kotlin 적용기
byNHN FORWARD
 
PDF
[2019] 벅스 5.0 (feat. Kotlin, Jetpack)
byNHN FORWARD
 
PDF
[2019] Java에서 Fiber를 이용하여 동시성concurrency 프로그래밍 쉽게 하기
byNHN FORWARD
 
PDF
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
byNHN FORWARD
 
PDF
[2019] 비식별 데이터로부터의 가치 창출과 수익화 사례
byNHN FORWARD
 
PDF
[2019] 게임 서버 대규모 부하 테스트와 모니터링 이렇게 해보자
byNHN FORWARD
 
PDF
[2019] 200만 동접 게임을 위한 MySQL 샤딩
byNHN FORWARD
 
PDF
[2019] 언리얼 엔진을 통해 살펴보는 리플렉션과 가비지 컬렉션
byNHN FORWARD
 
PDF
[2019] 글로벌 게임 서비스 노하우
byNHN FORWARD
 
PDF
[2019] 배틀로얄 전장(map) 제작으로 알아보는 슈팅 게임 레벨 디자인
byNHN FORWARD
 
[2019] 패션 시소러스 기반 상품 특징 분석 시스템
byNHN FORWARD
 
[2019] 스몰 스텝: Android 렛츠기릿!
byNHN FORWARD
 
딥러닝, 야 너도 할 수 있어(feat. PyTorch)
byNHN FORWARD
 
NHN 베이스캠프: 신입사원들은 무엇을 배우나요?
byNHN FORWARD
 
[2019] GIF 스티커 만들기: 스파인 2D를 이용한 움직이는 스티커 만들기
byNHN FORWARD
 
[2019] 전기 먹는 하마의 다이어트 성공기 클라우드 데이터 센터의 에너지 절감 노력과 사례
byNHN FORWARD
 
[2019] 스몰 스텝: Dooray!를 이용한 업무 효율화/자동화(고객문의 시스템 구축)
byNHN FORWARD
 
[2019] 아직도 돈 주고 DB 쓰나요? for Developer
byNHN FORWARD
 
[2019] 아직도 돈 주고 DB 쓰나요 for DBA
byNHN FORWARD
 
[2019] 비주얼 브랜딩: Basic system
byNHN FORWARD
 
[2019] PAYCO 매거진 서버 Kotlin 적용기
byNHN FORWARD
 
[2019] 벅스 5.0 (feat. Kotlin, Jetpack)
byNHN FORWARD
 
[2019] Java에서 Fiber를 이용하여 동시성concurrency 프로그래밍 쉽게 하기
byNHN FORWARD
 
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
byNHN FORWARD
 
[2019] 비식별 데이터로부터의 가치 창출과 수익화 사례
byNHN FORWARD
 
[2019] 게임 서버 대규모 부하 테스트와 모니터링 이렇게 해보자
byNHN FORWARD
 
[2019] 200만 동접 게임을 위한 MySQL 샤딩
byNHN FORWARD
 
[2019] 언리얼 엔진을 통해 살펴보는 리플렉션과 가비지 컬렉션
byNHN FORWARD
 
[2019] 글로벌 게임 서비스 노하우
byNHN FORWARD
 
[2019] 배틀로얄 전장(map) 제작으로 알아보는 슈팅 게임 레벨 디자인
byNHN FORWARD
 

[2018] MySQL 이중화 진화기

  • 1.
    © 2018 NHNFORWARD. All rights reserved. MySQL 이중화 진화기 박노을 데이터운영팀
  • 2.
    CONTENTS 1. DB 이중화필요성 2. 이중화 방안  HW 이중화  MySQL Replication 이중화 3. 이중화 운영 장애 4. DNS와 VIP 5. MySQL 이중화 솔루션 비교
  • 3.
  • 4.
    4 / 73 DBSingle 구성 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.
  • 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 MySQLReplication 일관성 보장 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 MySQLReplication 일관성 보장 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 MySQLReplication 일관성 보장 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 MySQLReplication 일관성 보장 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 MySQLReplication 일관성 보장 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 MySQLReplication 일관성 보장 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 MySQLReplication 일관성 보장 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-MasterReplication 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 MMMFAILOVER 과정 MySQL Replication 이중화 Slave MMM Monitor Master (Active) VIP Master (Standby)
  • 35.
    35 / 73 MMMFAILOVER 과정  장애가 발생한 DB 에 데이터 변경이 되지 않도록 읽기 모드 활성화한다. MySQL Replication 이중화 Slave MMM Monitor Master (Active) Master (Standby) VIP 읽기 모드로 변경 SESSION KILL VIP 회수
  • 36.
    36 / 73 MMMFAILOVER 과정  장애가 발생한 DB에 접속 세션을 kill 한다. MySQL Replication 이중화 Slave MMM Monitor Master (Active) VIP 읽기 모드로 변경 SESSION KILL Master (Standby) VIP 회수
  • 37.
    37 / 73 MMMFAILOVER 과정  장애가 발생한 DB에 접속이 되지 않도록 VIP 회수 MySQL Replication 이중화 Slave MMM Monitor Master (Active) VIP 읽기 모드로 변경 SESSION KILL VIP 회수 Master (Standby)
  • 38.
    38 / 73 MMMFAILOVER 과정  복제 지연 여부 확인 및 대기 MySQL Replication 이중화 MMM Monitor Master (Active) 복제지연 확인 Slave Master (Standby) 복제 재구성
  • 39.
    39 / 73 MMMFAILOVER 과정  Master(Standby)를 신규 마스터로 복제 재구성 MySQL Replication 이중화 MMM Monitor Master (Active) Master (Standby) 복제 재구성 Slave 복제지연 확인
  • 40.
    40 / 73 MMMFAILOVER 과정  신규 마스터로 승격시키기 위해 Master(Standby)를 읽기 모드 해제 MySQL Replication 이중화 MMM Monitor 읽기 모드 해제 Slave Master (Active) Master (Standby) VIP 할당
  • 41.
    41 / 73 MMMFAILOVER 과정  신규 마스터에 VIP 할당 MySQL Replication 이중화 MMM Monitor VIP Slave Master (Active) 읽기 모드 해제 VIP 할당 Master (Standby)
  • 42.
    42 / 73 MMMFAILOVER 과정  FAILOVER 완료 MySQL Replication 이중화 MMM Monitor VIP Slave 읽기 모드 해제 VIP 할당 FAILOVER 완료 Master (Active)
  • 43.
    43 / 73 MMMFAILOVER 대상  Master(Active) / Master(Standby) 양방향 복제  Master(Active) -> Master(Standby) MySQL Replication 이중화 Master (Active) Master (Standby) MMM Monitor Slave
  • 44.
    44 / 73 MMMFAILOVER 후속 처리  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 MMMFAILOVER 예시  마스터의 변경사항을 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 MMMFAILOVER 예시  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 MMMFAILOVER 예시  신규 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 MMMFAILOVER 예시  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 MMMFAILOVER 문제  Multi Slave 환경에서 복제 Crash 가능성 존재 MySQL Replication 이중화
  • 50.
    50 / 73 MHA(MasterHigh 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 MHAFAILOVER 후속 처리  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 MySQLReplication 이중화 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 MySQLReplication 이중화 MHA Failover 시 복제 일관성 해결  Binary log와 Relay log를 비교해서 차이 나는 이벤트를 추출 Master Slave-2 MHA Monitor Slave-1 Relay Log Binary log Relay Log
  • 55.
    55 / 73 MySQLReplication 이중화 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 MySQLReplication 이중화 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 MMMMonitor 에서 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.
  • 66.
    66 / 73 BroadCast 도메인 내에서만(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 NHNFORWARD. 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 NHNFORWARD. All rights reserved. Q&A
  • 73.
    © 2018 NHNFORWARD. All rights reserved. THANK YOU