SMALL
하나의 DB 서버에 많은 트래픽이 몰리게 된다면 큰 병목 현상이 일어나
정상적인 서비스를 제공하지 못하는 상황이 발생하기도 합니다.
이를 개선하기 위해 MySQL과 MariaDB는 DB서버를 분산하여 처리할 수 있게 도와주는 Replication 구조를 제공합니다.
Replication는 복제라는 의미로, Master/Slave 구조를 기반으로 하여 Master 서버에서의 변경 사항을 Slave 서버가 받아와서 데이터의 정합성을 맞추고 APP이나 WEB 서버의 요청을 Slave에서 처리할 수 있는 형태입니다.
(여기서 정합성이란 두 서버 간의 데이터가 서로 일치하는지 여부를 말합니다.)
- Master/Slave Replication 구조의 특징
-
N개의 Slave DB를 추가적으로 구성할 수 있습니다.
-
비동기 방식으로 데이터를 복제합니다.
-
Master 서버의 bin-log(바이너리 로그)를 Slave 서버의 relay-log로 복사하는 방식으로 데이터를 복제합니다.
-
Master 서버에서는 INSERT, UPDATE, DELETE 쿼리를,Slave 서버에서는 SELECT 쿼리를 실행하여 서버 트래픽을 분산시킬 수 있습니다.
-
많은 READ 처리와 적은 WRITE 환경에 대한 일반적인 시나리오로써, 데이터 분석은 Master 서버에 영향을 많이 줄 수 있기 때문에 데이터 조회 부담을 Slave 서버에 나누어 줄 수 있습니다.
-
실시간 백업이 가능하여 Master 서버에 오류 발생 시 Slave 서버를 이용하여 Master 서버를 복구할 수 있습니다.
-
Replication 구조를 적용하면 Master/Slave 서버 간 데이터 동기화의 시간이 소요되기 때문에 데이터 정합성의 문제가 발생할 수 있습니다.
-
Slave 서버에서의 데이터 조작이 발생하면 Master 서버와의 정합성이 깨지고 이를 보완하기 위한 추가 작업이 필요하게 됩니다.
-
Master 서버는 바이너리 로그를 안정적으로 기록하기 위해 락(Lock)을 유지하고, 로그를 기록하는 작업 또한 디스크I/O를 추가적으로 소모합니다.
Maria DB Replication (Master/Slave) 이중화 설정하는 법
실습한 운영체제 : Windows 10
Master와 Slave의 버전은 서로 같거나 Slave의 버전이 더 높은 경우여야 합니다.
1. 우선 MariaDB와 MySQL WorkBench를 아래 URL을 통해 설치합니다.
각 Master / Slave MariaDB는 본문 날짜 기준(2022.04.26)
MariaDB Server 10.8.2 RC 버전으로 서로 동일하게 설치하였습니다.
(설치 과정 생략)
2. 윈도우즈 검색을 통해 Maria DB Client를 실행하여 설치여부를 확인합니다.
3. MariaDB가 설치된 경로로 이동하여 my.ini 파일을 메모장으로 실행합니다.
[윈도우10 OS 기준 기본 설치경로]
C:\Program Files\MariaDB 10.8\data 로 이동
4. [Master] 서버 측 설정
4-1 my.ini 수정
[mysqld] 하위에 아래 구문을 추가 후 저장합니다.
log-bin=mysql-bin
server-id = 1
log-bin은 Slave에서 Master와 연결할 file 참조명이 됩니다.
4-2 root 계정으로 DB에 로그인 후 테스트로 사용할 스키마와 테이블을 생성합니다.
CREATE SCHEMA `slave_test_schema` ;
CREATE TABLE `slave_test_schema`.`slave_test_member` (
`member_se` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
`member_nm` VARCHAR(20) NOT NULL,
`member_id` VARCHAR(20) NOT NULL,
PRIMARY KEY (`member_se`));
4-3 Master 서버에 접속할 Slave 계정을 생성 후 권한을 부여해줍니다.
USE mysql;
CREATE USER 'username'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'username'@'%' identified by 'password';
GRANT ALL PRIVILEGES ON `slave_test_schema`.* TO 'username'@'%';
FLUSH PRIVILEGES;
4-4 Maria-DB 서버를 재시작합니다.
4-4. SHOW MASTER STATUS;
해당 쿼리를 실행하여 master 서버의 설정 상태가 정상으로 확인된다면 완료입니다.
File, Position 데이터는 [Slave] 서버 측에서 사용하므로 해당 값을 전달해주어야 합니다.
5. [Slave] 서버 측 설정
5-1. my.ini 수정
[mysqld] 하위에 아래 구문을 추가 후 저장합니다.
log-bin=mysql-bin
server-id = 2
5-2 서비스를 재시작합니다. (상단 Master와 같은 방법)
5-3 root 계정으로 로그인 후 테스트용으로 시작할 스키마와 테이블을 생성합니다.
(Master 서버의 덤프를 복사해서 사용해도 무방합니다.)
CREATE SCHEMA`slave_test_schema`;
CREATE TABLE `slave_test_schema`.`slave_test_member`(
`member_se` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
`member_nm` VARCHAR(20)NOT NULL,
`member_id` VARCHAR(20)NOT NULL,
PRIMARY KEY(`member_se`));
5-4 각 항목에 맞게 데이터를 입력 후 해당 CHANGE 쿼리를 입력 후 실행합니다.
CHANGE MASTER TO
MASTER_HOST=“master_ip_address”,
MASTER_USER=“username”,
MASTER_PASSWORD=“password”,
MASTER_PORT=3306,
MASTER_LOG_FILE=“(Master Status File Data)”,
MASTER_LOG_POS= (Master Status Position Data);
5-4 START SLAVE; 실행
START SLAVE;
미러링이 시작되면 Master에서 작업되는 모든 DB 데이터 항목이 Slave 에서도 동일하게 적용됩니다.
5-5 SLAVE 상태를 확인합니다.
SHOW SLAVE STATUS;
Slave_IO_State: Waiting for master to send event 가 떠야 정상입니다.
6. Master / Slave 서버 설정이 정상적으로 적용되었는지 확인합니다.
Master 서버에서 새로운 테이블을 생성해본 후
데이터 조작 쿼리 INSERT, UPDATE, DELETE를 실행해봅니다.
그 후 Slave 서버에서 SELECT 하여 확인해봅니다.
주의사항
-
Replication을 하다 보면 Binary Log가 계속 쌓이게 됩니다.이를 개선하기 위해 my.ini에 expire_logs_days에 유효기간을 설정해주어야 합니다.
-
DB 변경사항이 log 파일로 저장된 후 Slave 서버에서 log 파일을 읽어 변경사항을 그대로 DB에 적용하는 방식이므로 두 관계를 설정하기 전에 기존 데이터가 있다면 Slave 서버에 미리 복사 및 동기화 후 진행해야 합니다. (기존 데이터는 복제하지 않습니다.
-
Master 서버를 재시작하게 된다면 mastet status의 file과 position 데이터가 변경되므로 Slave 서버에서 재설정해주어야 합니다.
BIG
'DataBase > Maria DB' 카테고리의 다른 글
| [DB/AWS] 리눅스2 MARIA DB 설치 - 2) MariaDB 설치 (0) | 2023.02.08 |
|---|---|
| [DB/AWS] 리눅스2 MARIA DB 설치 - 1) 스토리지 볼륨 사용할수 있도록 만들기 (0) | 2023.02.08 |
| [DB] MariaDB 백업 스케줄 설정과 백업파일 AWS S3 저장소 업로드 (0) | 2023.02.08 |
| [DB] MariaDB 실행 계획 (0) | 2023.02.07 |
| [DB] 더 빠른 SQL 쿼리를 위한 데이터베이스 튜닝 규칙 (0) | 2023.02.07 |