24시간 365일 서비스를 위한 MySQL DB 이중화.
MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다.
목차
1. DB 이중화 필요성
2. 이중화 방안
- HW 이중화
- MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교
대상
- MySQL을 서비스하고 있는 인프라 담당자
- MySQL 이중화에 관심 있는 개발자
사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
24시간 365일 서비스를 위한 MySQL DB 이중화.
MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다.
목차
1. DB 이중화 필요성
2. 이중화 방안
- HW 이중화
- MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교
대상
- MySQL을 서비스하고 있는 인프라 담당자
- MySQL 이중화에 관심 있는 개발자
사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
- MariaDB 소개
- MariaDB 서버 구성 및 아키텍처 이해
- MariaDB 스토리지 엔진
- MariaDB 데이터베이스 관리
- 트랜잭션 / Locking 의 이해
- MariaDB 보안
- 백업과 복구를 통한 데이터베이스 관리
- MariaDB upgrade
- MariaDB 모니터링
- MySQL 에서 MariaDB 로의 전환
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
MariaDB 10.5 binary install (바이너리 설치)
- 네오클로바 DB지원사업부
1. About MariaDB
1.1 MariaDB 개요
1.2 MariaDB as a R-DBMS
1.3 Open Source Database System
2. 설치
2.1 설치 기본 정보
2.2 설치 준비
2.3 MariaDB 설치
2.4 MariaDB 시작 / 접속 / 종료
2.5 추가 설정
[오픈소스컨설팅]Day #1 MySQL 엔진소개, 튜닝, 백업 및 복구, 업그레이드방법Ji-Woong Choi
MySQL 소개
간략한 소개
version history
MySQL 사용처
제품 군 변화
시장 변화
MySQL 구성
MySQL 클라이언트 / 서버 개념
클라이언트 프로그램
MySQL 설치
MySQL 버전
MySQL 설치
MySQL 환경 설정
환경설정, 변수 설정
MySQL 스토리지 엔진 소개
MySQL tuning 소개 및 방법
데이터 백업/복구 방법
백업
복구
MySQL Upgrade
This tutorial covers all parallel replication implementation in MariaDB 10.0 and 10.1 and MySQL 5.6, 5.7 and 8.0 (including how it works in Group Replication).
MySQL and MariaDB have different types of parallel replication. In this tutorial, we present the different implementations that allow us to understand their limitations and tuning parameters. We cover how to make parallel replication faster and what to avoid for maximizing its benefits. We also present tests from Booking.com workloads.
Some of the subjects that are covered are group commit and optimistic parallel replication in MariaDB, the parallelism interval of MySQL and its Write Set optimization, and the ?slowing down the master to speed up the slave? optimization.
After this tutorial, you will know everything you need to implement and tune parallel replication in your environment. But more importantly, we will show how you can test parallel replication benefit in a non-disruptive way before deployment.
ProxySQL is a popular database proxy for MySQL/MariaDB servers. This focuses on the possible High availability options for ProxySQL and operations of inbuilt clustering feature in ProxySQL. This tech talk was presented at Mydbops Database Meetup on 27-04-2019 by Aakash M, Database Administrator with Mydbops and Vignesh Prabhu, Database Administrator with Mydbops.
MMUG18 - MySQL Failover and OrchestratorSimon J Mudd
Description of recovery and failover with of MySQL and specifically how orchestrator is designed to make this simpler.
A presentation I gave at the Madrid MySQL Users Group on 17/05/2017.
Maxscale switchover, failover, and auto rejoinWagner Bianchi
How the MariaDB Maxscale Switchover, Failover, and Rejoin works under the hood by Esa Korhonen and Wagner Bianchi.
You can watch the video of the presentation at
https://www.linkedin.com/feed/update/urn:li:activity:6381185640607809536
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
- MariaDB 소개
- MariaDB 서버 구성 및 아키텍처 이해
- MariaDB 스토리지 엔진
- MariaDB 데이터베이스 관리
- 트랜잭션 / Locking 의 이해
- MariaDB 보안
- 백업과 복구를 통한 데이터베이스 관리
- MariaDB upgrade
- MariaDB 모니터링
- MySQL 에서 MariaDB 로의 전환
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
MariaDB 10.5 binary install (바이너리 설치)
- 네오클로바 DB지원사업부
1. About MariaDB
1.1 MariaDB 개요
1.2 MariaDB as a R-DBMS
1.3 Open Source Database System
2. 설치
2.1 설치 기본 정보
2.2 설치 준비
2.3 MariaDB 설치
2.4 MariaDB 시작 / 접속 / 종료
2.5 추가 설정
[오픈소스컨설팅]Day #1 MySQL 엔진소개, 튜닝, 백업 및 복구, 업그레이드방법Ji-Woong Choi
MySQL 소개
간략한 소개
version history
MySQL 사용처
제품 군 변화
시장 변화
MySQL 구성
MySQL 클라이언트 / 서버 개념
클라이언트 프로그램
MySQL 설치
MySQL 버전
MySQL 설치
MySQL 환경 설정
환경설정, 변수 설정
MySQL 스토리지 엔진 소개
MySQL tuning 소개 및 방법
데이터 백업/복구 방법
백업
복구
MySQL Upgrade
This tutorial covers all parallel replication implementation in MariaDB 10.0 and 10.1 and MySQL 5.6, 5.7 and 8.0 (including how it works in Group Replication).
MySQL and MariaDB have different types of parallel replication. In this tutorial, we present the different implementations that allow us to understand their limitations and tuning parameters. We cover how to make parallel replication faster and what to avoid for maximizing its benefits. We also present tests from Booking.com workloads.
Some of the subjects that are covered are group commit and optimistic parallel replication in MariaDB, the parallelism interval of MySQL and its Write Set optimization, and the ?slowing down the master to speed up the slave? optimization.
After this tutorial, you will know everything you need to implement and tune parallel replication in your environment. But more importantly, we will show how you can test parallel replication benefit in a non-disruptive way before deployment.
ProxySQL is a popular database proxy for MySQL/MariaDB servers. This focuses on the possible High availability options for ProxySQL and operations of inbuilt clustering feature in ProxySQL. This tech talk was presented at Mydbops Database Meetup on 27-04-2019 by Aakash M, Database Administrator with Mydbops and Vignesh Prabhu, Database Administrator with Mydbops.
MMUG18 - MySQL Failover and OrchestratorSimon J Mudd
Description of recovery and failover with of MySQL and specifically how orchestrator is designed to make this simpler.
A presentation I gave at the Madrid MySQL Users Group on 17/05/2017.
Maxscale switchover, failover, and auto rejoinWagner Bianchi
How the MariaDB Maxscale Switchover, Failover, and Rejoin works under the hood by Esa Korhonen and Wagner Bianchi.
You can watch the video of the presentation at
https://www.linkedin.com/feed/update/urn:li:activity:6381185640607809536
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
2. 2
개정이력
버전 변경일 변경사유1
변경내용2
작성자 승인자
Ver. 1.0 2022.6.7 최초작성 문서 최초 작성 김경연
1
변경 사유: 변경 내용이 이전 문서에 대해 최초작성/승인/추가/수정/삭제 중 선택 기입
2
변경 내용: 변경이 발생되는 위치와 변경 내용을 자세히 기록(장.절과 변경 내용을 기술한다.)
3. 3
목차
개정이력 ....................................................................................................................................................................................2
1. MariaDB HA구성 ...............................................................................................................................................................5
1) 일반구성 .....................................................................................................................................................................5
2) 권장구성 .....................................................................................................................................................................6
3) 최소구성 .....................................................................................................................................................................6
4) MariaDB GTID 사용시 옵션 ................................................................................................................................6
5) MaxScale 2.5 버전의 협업모니터링 기능 지원에 따른 아키텍처 개선............................................6
6) IP 할당 ........................................................................................................................................................................7
7) 전체 서비스 중지 및 기동 순서 ......................................................................................................................7
2. Monitoring ..........................................................................................................................................................................8
1) keepliaved – 기동확인 ..........................................................................................................................................8
2) VIP(x.x.x.x) 활성화 상태확인 ...............................................................................................................................8
3) Maxscale – 기동확인 .............................................................................................................................................8
4) Maxscale – DB 서비스확인 .................................................................................................................................9
5) Maxscale – 노드확인 .............................................................................................................................................9
6) DB – 복제확인....................................................................................................................................................... 10
7) Maxscale – 주요 명령어.................................................................................................................................... 11
3. AUTO_FAILOVER/AUTO_REJOIN with MaxScale................................................................................................. 13
1) 작동방식 .................................................................................................................................................................. 13
2) 주요 파라미터들 ( in Monitor Module) ..................................................................................................... 13
3) 주의사항 .................................................................................................................................................................. 13
4) Service auto_failover / auto_rejoin 테스트 ................................................................................................ 14
4. Keepalived / MaxScale의 수동 Failover ............................................................................................................... 15
5. 5
1. MariaDB HA구성
본 내용은 MariaDB 에 대한 Master/Slave 서비스구성에 대하여 Maxscale 을 통해서
- Read/Write Connection 의 Load Balancing 구성
- Maxscale 을 통한 Auto Failover/Switchover / Rejoin 구성
- Keepalived 를 통한 Maxscale 의 고가용성 구성
을 목적으로 합니다.
1) 일반구성
Slave
MariaDB
Master
MariaDB
Client
Active
Maxscale
VIP
Passive
Maxscale
keepalived
status broadcast
Semi-Sync
Replication
base GTID
Database Query
R/W
R/W
6. 6
2) 권장구성
HOST 구성요소 설명
MAX1
keepalived Keepalived와 Maxscale은 동일노드에 구성합니다.
VIP enable
Maxscale
DB1 MariaDB DB노드간 Semi-Sync Replication 구성(Master)
MAX2
keepalived Keepalived와 Maxscale은 동일노드에 구성합니다.
VIP disable
Maxscale
DB2 MariaDB DB노드간 Semi-Sync Replication 구성(Slave).
3) 최소구성
HOST 구성요소 설명
DB1 keepalived (Keepalived+Maxscale) + MariaDB
VIP enable
Semi-Sync Replication - Master
Maxscale
MariaDB
DB2 keepalived (Keepalived+Maxscale) + MariaDB
VIP disable
Semi-Sync Replication - Slave
Maxscale
MariaDB
주의) keepalived를 통해서 VIP를 제어할 경우는 반드시 Maxscale과 keepalived를 동일노드에 함
께 구성해야 합니다. 일반적으로 Maxscale을 DB노드와 분리해서 사용하기를 권장드립니다.
4) MariaDB GTID 사용시 옵션
- CHANGE MASTER TO ~,MASTER_USE_GTID=(current_pos / slave_pos)
+ current_pos : 노드가 Failover필요한 경우. maxscale의 auto_failover=true 경우 필수.
+ slave_pos : 단순 복제구성(영구적)인 경우.
5) MaxScale 2.5 버전의 협업모니터링 기능 지원에 따른 아키텍처 개선
- 2.4 이전까지는 autofailover=true 설정을 다수의 maxscale에 설정할 경우, Master 장애에 대한
Failover 수행처리 과정의 충돌로 서비스 장애가 발생할 가능성이 존재합니다.
- 2.5 버전부터 협업모니터링(Cooperative Monitoring)기능 지원으로 Maxscale 노드간에 장애조치
에 대한 충돌이 발생하지 않는다.
https://mariadb.com/ko/resources/blog/mariadb-maxscale-2-5-cooperative-monitoring/
7. 7
- 주의할 점은 Backend노드의 MariaDB대수와 설정값에 따라서 협업모니터링 발생한다는 것이다.
6) IP 할당
#VIP - x.x.x.130
#1노드 - x.x.x.131
#2노드 - x.x.x.132
7) 전체 서비스 중지 및 기동 순서
OS에 계정은 keepalived, maxscale, mariadb를 제어할 수 있는 계정에서 수행하시면 됩니다.
- 전체 서비스를 중지하려는 경우는 다음순서로 수행하시면 됩니다.
+ WAS등 Client접속 중지합니다
+ Standby keepalived를 중지
+ Standby Maxscale을 중지
+ Slave서버의 복제상태를 확인하고 DB를 중지
+ Active의 keepalived를 중지
+ Active의 Maxscale을 중지
+ Active의 DB(Master)를 중지
- 전체 서비스를 시작하려면 중지순서와 반대로 수행합니다.
+ Active의 DB(Master)를 기동
+ Active의 Maxscale을 기동
+ Active의 keepalived를 기동
+ Standby의 DB(Slave)를 기동
+ Standby의 Maxscale을 기동
+ Standby의 keepalived를 기동
8. 8
2. Monitoring
하기 명령에 대한 결과는 구성환경에 따라 차이가 있습니다. 주요정보만 확인하시면 되겠습니다.
1) keepliaved – 기동확인
#1>$ systemctl status keepalived
Loaded: loaded (/usr/lib/systemd/system/keepalived.service; disabled; vendor preset: disabled)
Active: active (running) since 금 2022-05-27 15:56:11 KST; 1 weeks 3 days ago
Main PID: 100524 (keepalived)
CGroup: /system.slice/keepalived.service
├─100524 /usr/sbin/keepalived -D
├─100525 /usr/sbin/keepalived -D
└─100526 /usr/sbin/keepalived -D
#2>$ systemctl status keepalived
Loaded: loaded (/usr/lib/systemd/system/keepalived.service; disabled; vendor preset: disabled)
Active: active (running) since 금 2022-05-27 15:57:05 KST; 1 weeks 3 days ago
Main PID: 24892 (keepalived)
CGroup: /system.slice/keepalived.service
├─24892 /usr/sbin/keepalived -D
├─24893 /usr/sbin/keepalived -D
└─24894 /usr/sbin/keepalived -D
각노드의 기동(active)를 확인합니다.
2) VIP(x.x.x.x) 활성화 상태확인
# 1 >$ ip addr | grep x.x.x.130
inet x.x.x.130/32 scope global eth0
# 1 >$
# 2 >$ ip addr | grep x.x.x.130
#2>$
하나의 노드에만 VIP가 할당되어 있어야 합니다.
VIP가 할당된 노드의 Maxscale은 반드시 Active 상태이어야 합니다.
3) Maxscale – 기동확인
# 1 >$ systemctl status maxscale
maxscale.service - MariaDB MaxScale Database Proxy
Loaded: loaded (/usr/lib/systemd/system/maxscale.service; enabled; vendor preset: disabled)
Active: active (running) since 금 2022-05-27 17:11:13 KST; 1 weeks 3 days ago
Main PID: 105696 (maxscale)
CGroup: /system.slice/maxscale.service
└─105696 /usr/bin/maxscale
…
# 2 >$ systemctl status maxscale
maxscale.service - MariaDB MaxScale Database Proxy
Loaded: loaded (/usr/lib/systemd/system/maxscale.service; enabled; vendor preset: disabled)
Active: active (running) since 금 2022-05-27 17:10:06 KST; 1 weeks 3 days ago
Main PID: 30255 (maxscale)
CGroup: /system.slice/maxscale.service
└─30255 /usr/bin/maxscale
…
두 노드 모두 Maxscale이 기동중이어야 합니다.
특히 VIP가 할당된 노드의 Maxscale은 반드시 정상기동중이어야 합니다.
VIP가 비할당된 노드의 경우는 Maxscale/keepalived를 Maintenance를 위해서 중지할 수 있습니다.
9. 9
4) Maxscale – DB 서비스확인
# 1 >$ maxctrl list services
┌────────────────┬───────────────┬─────────────┬────────┐
│ Service │ Router │ Connections│Total Connections│ Servers │
├────────────────┼───────────────┼─────────────┼────────┤
│ RW-AutoService │ readconnroute 15 │ 46135 │ server1, server2 │
└────────────────┴───────────────┴─────────────┴────────┘
# 1 >$ maxctrl list listeners
┌─────────────────┬──────┬─────────┬─────────┬────────────────┐
│ Name │ Port │ Host │ State │ Service │
├─────────────────┼──────┼─────────┼─────────┼────────────────┤
│ RW-AutoListener │ 3306 │ 0.0.0.0 │ Running │ RW-AutoService │
└─────────────────┴──────┴─────────┴─────────┴────────────────┘
# 2 >$ maxctrl list services
┌────────────────┬───────────────┬─────────────┬────────┐
│ Service │ Router │ Connections│Total Connections│ Servers │
├────────────────┼───────────────┼─────────────┼────────┤
│ RW-AutoService │ readconnroute 0 │ 0 │ server1, server2 │
└────────────────┴───────────────┴─────────────┴────────┘
# 2 >$ maxctrl list listeners
┌─────────────────┬──────┬─────────┬─────────┬────────────────┐
│ Name │ Port │ Host │ State │ Service │
├─────────────────┼──────┼─────────┼─────────┼────────────────┤
│ RW-AutoListener │ 3306 │ 0.0.0.0 │ Running │ RW-AutoService │
└─────────────────┴──────┴─────────┴─────────┴────────────────┘
기동중인 maxscale노드에서 확인할 수 있으나, 일 반적으로 Maxscale명령은 VIP가 할당된 노드에서 확인(이하 생략)합니다.
서비스중인 Routing Port(listeners)와 노드정보를 확인할 수 있습니다.
서버스의 모듈정보(readconnroute, readwritesplit 등)을 확인 할 수 있습니다.
5) Maxscale – 노드확인
# 1 >$ maxctrl list servers
┌─────────┬─────────────┬──────┬─────────────┬┬─────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├─────────┼─────────────┼──────┼─────────────┼┼─────────────┤
│ server1 │ x.x.x.131 │ 3305 │ 16 │ Master, Running │ 0-2-3082565 │
├─────────┼─────────────┼──────┼─────────────┼┼─────────────┤
│ server2 │ x.x.x.132 │ 3305 │ 0 │ Slave, Running │ 0-2-3082565 │
└─────────┴─────────────┴──────┴─────────────┴┴─────────────┘
현재 MariaDB서버의 복제상태와 Connection정보를 확인할 수 있습니다.
일반적 readconnroute의 경우 반드시 하나의 노드는 M aster, Running 이어야 합니다.
Slave노드가 정상이라면 Slave, Running으로 확인되며, 복제지연이 발생하지 않는다면 GTID의 차이가 거의 없어야 합니다.
10. 10
6) DB – 복제확인
# 1 -MariaDB-Master> show slave status;
Empty set (0.000 sec)
# 1 -MariaDB-Master> show slave hosts;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
| 2 | | 3305 | 1 |
+-----------+------+------+-----------+
# 2 -MariaDB-Slave> show slave statusG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: x.x.x.131
Master_User: repl
Master_Port: 3305
Connect_Retry: 60
Master_Log_File: mariadb-bin.000006
Read_Master_Log_Pos: 610896349
Relay_Log_File: mariadb-realy.000006
Relay_Log_Pos: 610896650
Relay_Master_Log_File: mariadb-bin.000006
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 610896349
Relay_Log_Space: 610897006
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Current_Pos
Gtid_IO_Pos: 0-2-3082993
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Slave_DDL_Groups: 859433
Slave_Non_Transactional_Groups: 141
Slave_Transactional_Groups: 1459480
Master에서는 복제정보를 확인할 수 없습니다.
Slave에서는 복제가 정상이라면 IO Running, SQL Running 값이 YES이어야 하고, Second Behind Master값이 0이어야 합니다.
12. 12
│ │ "writeq_high_water": 16777216, │
│ │ "writeq_low_water": 8192 │
│ │ } │
└──────────────┴─────────────────────
#maxscale 도움말
$ m axctrl --help
maxctrl
명령:
maxctrl list <command> List objects
maxctrl show <command> Show objects
maxctrl set <command> Set object state
maxctrl clear <command> Clear object state
maxctrl drain <command> Drain objects
maxctrl enable <command> Enable functionality
maxctrl disable <command> Disable functionality
maxctrl create <command> Create objects
maxctrl destroy <command> Destroy objects
maxctrl link <command> Link objects
maxctrl unlink <command> Unlink objects
maxctrl start <command> Start objects
maxctrl stop <command> Stop objects
maxctrl alter <command> Alter objects
maxctrl rotate <command> Rotate log files
maxctrl reload <command> Reload objects
maxctrl call <command> Call module commands
maxctrl cluster <command> Cluster objects
maxctrl api <command> Raw REST API access
maxctrl classify <statement> Classify statement
Global Options:
-u, --user Username to use [문자열] [기본: "admin"]
-p, --password Password for the user. To input the password manually, use -p
'' or --password='' [문자열] [기본: "mariadb"]
-h, --hosts List of MaxScale hosts. The hosts must be in HOST:PORT format
and each value must be separated by a comma.
[문자열] [기본: "127.0.0.1:8989"]
-t, --timeout Request timeout in plain milliseconds, e.g '-t 1000', or as
duration with suffix [h|m|s|ms], e.g. '-t 10s'
[문자열] [기본: "10000"]
-q, --quiet Silence all output. Ignored while in interactive mode.
[여부] [기본: false]
--tsv Print tab separated output [여부] [기본: false]
HTTPS/TLS Options:
-s, --secure Enable HTTPS requests [여부] [기본: false]
--tls-key Path to TLS private key [문자열]
--tls-passphrase Password for the TLS private key [문자열]
--tls-cert Path to TLS public certificate [문자열]
--tls-ca-cert Path to TLS CA certificate [문자열]
-n, --tls-verify-server-cert Whether to verify server TLS certificates
[여부] [기본: true]
Options:
--version 버전 넘버를 보여줍니다 [여부]
--help 도움말을 보여줍니다 [여부]
If no commands are given, maxctrl is started in interactive mode. Use `exit` to
exit the interactive mode.
도움말을 참고해서 명령어를 실행할 수 있습니다.
기존정보를 추가/변경/삭제하는 명령어 실행은 주의하시기 바랍니다.
maxctrl list ~, maxctrl show ~ 명령을 통해서 모니터링 정보를 확인할 수 있습니다.
13. 13
3. AUTO_FAILOVER/AUTO_REJOIN with MaxScale
1) 작동방식
Maxscale은 Monitor module을 통해서 장애발생 시 자동조치를 수행할 수 있습니다.
auto_failover=true 이며 서비스구조(master/slave or galera)에 참여하는 각 노드를 주기적으로
health check를 수행하며 일정 횟수이상 통신이상이 확인되면 Slave중 한대를 New Master로 전환
하고 다른 Slave들을 New Master로 연결을 자동전환 합니다.
# cat /etc/maxscale.cnf
…
[MariaDB-Monitor]
type=monitor
module=mariadbmon
servers=server1,server2
monitor_interval=1000
auto_failover = true
auto_rejoin = true
handle_events=true
…
2) 주요 파라미터들 ( in Monitor Module)
Parameter 설명 기본값 권고값
auto_failover false true
auto_rejoin false true
switchover_on_low_disk_space Master 디스크공간 부족 시 failover 처리 여부 비활성화 비활성화
failover_timeout 장애/재결합 조치 제한시간(초) 90
switchover_timeout 전환조치 제한시간(초) 90
verify_master_failure Master 장애확인 검증 기능 활성화 여부. true true
master_failure_timeout Master 장애확인시 시간초과(초) 한계값 10 5
servers_no_promotion Candidate Master중 제외할 목록(no-master그룹?) “,”로 구분
promotion_sql_file New Master로 전환 후, New Master에서 실행할 수 있는 SQL 파일
demotion_sql_slave Old Master가 rejoin되는 경우 Old Master에서 실행할 callback 파일
handle_events mysql.event 에 대한 Object 상태제어.(SLAVE_SIDE_DISABLED ->ENABLED) on on
3) 주의사항
maxscale의 auto_failover & auto_rejoin은 MaxScale 2.2 부터 지원됩니다.
handle_events 는 Maxscale 2.3 부터 지원됩니다.
따라서 event_scheduler를 활용하시는 서비스구조라면 MaxScale 2.3.x 이후버전의 사용을 추천합
니다.
14. 14
4) Service auto_failover / auto_rejoin 테스트
4-1) auto_failover
tail –f /var/log/maxscale/maxscale.log
error : Monitor was unable to connect to server server2[192.168.100.11:3306] : 'Can't connect to MySQL server on '192.168.100.11' (115)'
notice : Server changed state: server1[192.168.100.11:3306]: master_down. [Master, Running] -> [Down]
warning: [mariadbmon] Master has failed. If master status does not change in 4 monitor passes, failover begins.
notice : [mariadbmon] Selecting a server to promote and replace 'server1'. Candidates are: 'server2'.
warning: [mariadbmon] Slave 'server2' has log_slave_updates disabled. It is a valid candidate but replication will break for lagging slaves
if 'server2' is promoted.
notice : [mariadbmon] Selected 'server2'.
notice : [mariadbmon] Performing automatic failover to replace failed master 'server1'.
notice : [mariadbmon] Event 'test.test_es_1' on server 'server2' set to 'ENABLE'.
notice : [mariadbmon] Failover 'server1' -> 'server2' performed.
notice : Server changed state: server2[192.168.100.12:3306]: new_master. [Slave, Running] -> [Master, Running]
정상수행
Master Daemon이 중지되면 Maxscale을 Master,Running을 Down을 상태를 변경합니다.
또한 Slave를 새로운 Master로 전환하기 위해서 Slave, Running에서 Master, Running으로 상태를 전환처리합니다.
4-2) auto_rejoin시 오류
Slave> show slave statusG;
…
Last_IO_Errno: 1236
Last_IO_Error : Got fatal error 1236 from master when reading data from binary log: 'Error: connecting slave requested to start from GTID
0-12-29, which is not in the master's binlog. Since the master's binlog contains GTIDs with higher sequence numbers, it probably means
that the slave has diverged due to executing extra erroneous transactions'
Using_Gtid: Current_Pos
…
마스터의 binary log가 Slave에 미처 복제되기전에 Slave가 신규 마스터로 승격되는 경우, 발생하는 문제.
async replication구성에서 innodb_flush_log_at_trx_commit= 1, sync_binlog= 1 에서도 동일증상 재현됨.
이 문제처럼 Master/Slave간 switch_over나 re_join에 문제가 발생하지 않으려면 Semi-Sync Replication을 구성해야 함.
semi-sync 구성후 정상수행.
15. 15
4. Keepalived / MaxScale의 수동 Failover
MaxScale 수동Failover Command는 매우 주의해서 사용하셔야 합니다.
운영환경에서는 특히 서비스영향도가 발생함으로 수행전에 노드/DB상태등을 확인 하신 후 사용
하세요.
1) VIP 전환 (server1 server2)
#2>$ systemctl status keepalived
Active: active (running) since 금 2022-05-27 15:56:11 KST; 1 weeks 3 days ago 확인) 반드시 active를 확인하세요.
…
#2>$ systemctl status maxscale
Active: active (running) since 금 2022-05-27 17:10:06 KST; 1 weeks 3 days ago 확인) 반드시 active를 확인하세요.
…
#2>$ maxctrl list servers
┌─────────┬─────────────┬──────┬─────────────┬┬─────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├─────────┼─────────────┼──────┼─────────────┼┼─────────────┤
│ server1 │ x.x.x.131 │ 3305 │ 0 │ Master, Running │ 0-2-3082565 │
├─────────┼─────────────┼──────┼─────────────┼┼─────────────┤
│ server2 │ x.x.x.132 │ 3305 │ 0 │ Slave, Running │ 0-2-3082565 │
└─────────┴─────────────┴──────┴─────────────┴┴─────────────┘
확인) 반드시 #2로 Connection 전환되기 전의 상태를 확인합니다.
#1>$ systemctl stop keepalived
#2>$ ip addr | grep x.x.x.130
inet x.x.x.130/32 scope global eth0
확인) VIP(x.x.x.x)가 #2로 넘어온 것을 확인합니다.
#2>$ maxctrl list servers
┌─────────┬─────────────┬──────┬─────────────┬┬─────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├─────────┼─────────────┼──────┼─────────────┼┼─────────────┤
│ server1 │ x.x.x.131 │ 3305 │ 12 │ Master, Running │ 0-2-3082566 │
├─────────┼─────────────┼──────┼─────────────┼┼─────────────┤
│ server2 │ x.x.x.132 │ 3305 │ 0 │ Slave, Running │ 0-2-3082566 │
└─────────┴─────────────┴──────┴─────────────┴┴─────────────┘
확인) 반드시 #2로 Connection이 유입되는 것을 확인해야 합니다.
VIP를 전환하려면 노드에 동일구성의 Maxscale이 반드시 기동중이어야 합니다.
2번노드의 VIP가 활성화 된 것과 Maxscale에 Connection정보가 정상유입됨을 확인하셔야 합니다.
2) VIP전환 없이 keepalived 기동/중지
# 2 >$ vi /etc/keepalived/keepalived.conf
…
vrrp_instance VI_1 {
priority 99
…
확인) VIP가 전환되지 않게 하려면 반드시 #1노드의 priority값(예를들어 100)보다 낮은값(99)으로 설정/저장하고 keepalived를 중지/기동해야 합니다.
# 2 >$ systemctl start keepalived
Active: active (running) since 금 2022-05-27 15:56:11 KST; 1 weeks 3 days ago 확인) 반드시 active를 확인하세요.
…
# 1 >$ ip addr
inet x.x.x.130/32 scope global eth0
VIP는 keepalived 기동시 prority가 높은노드의 keepalived daemon에 할당됩니다.
16. 16
3) Master / Slave에 대한 Switchover
# 1 >$ maxctrl list servers
┌─────────┬─────────────┬──────┬─────────────┬┬─────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├─────────┼─────────────┼──────┼─────────────┼┼─────────────┤
│ server1 │ x.x.x.131 │ 3305 │ 16 │ M a ster, Running │ 0-2-3082565 │
├─────────┼─────────────┼──────┼─────────────┼┼─────────────┤
│ server2 │ x.x.x.132 │ 3305 │ 0 │ S l ave, Running │ 0-2-3082565 │
└─────────┴─────────────┴──────┴─────────────┴┴─────────────┘
확인) 반드시 새로운 Master로 변경할 Server이름을 확인합니다.(여기서는 server2가 됩니다.)
# 1 >$ maxctrl list monitors
┌─────────────────┬─────────┬──────────────────┐
│ Monitor │ State │ Servers │
├─────────────────┼─────────┼──────────────────┤
│ MariaDB-Monitor │ Running │ server1, server2 │
└─────────────────┴─────────┴──────────────────┘
확인) 반드시 Monitor이름과 Server들의 이름을 확인합니다.
# 1 >$ maxctrl call command mariadbmon switchover MariaDB-Monitor server2 server1
OK
확인) 반드시 OK 메시지가 떠야 합니다. 오류가 발생하면 보관해두고, 다른 maxscale 노드에서 실행하시기 바랍니다.
# 1 >$ maxctrl list servers
┌─────────┬─────────────┬──────┬─────────────┬┬─────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├─────────┼─────────────┼──────┼─────────────┼┼─────────────┤
│ server1 │ x.x.x.131 │ 3305 │ 0 │ Slave, Running │ 0-2-3082565 │
├─────────┼─────────────┼──────┼─────────────┼┼─────────────┤
│ server2 │ x.x.x.132 │ 3305 │ 16 │ Master, Running │ 0-2-3082565 │
└─────────┴─────────────┴──────┴─────────────┴┴─────────────┘
확인) 반드시 신규Master(server2)가 Master, Running임을 확인합니다.
maxctrl call command mariadbmon switchover [monitor이름] [master될노드] [slave될노드]
Active Maxscale에서 Command를 수행하시기 권장합니다.
끝.