[관리] Mysql Replication 을 이용한 미러링 구축 방법

Mysql Replication 을 이용한 미러링 구축 방법  

        

  – 필요성 –

서버 운영 중에 발생하는 예기치 못한 서비스 중단에 대해 최신 자료의 복

구는 반드시 필요하다.

특히 데이터 베이스를 이용해서 회원의 정보나 주문 정보를 저장하는 경

우, 정보의 유실은 고객의 입장에서는 큰 손해가 될 수 있다.

이에 간단하게 나마 실시간 Mysql 미러링 구축에 대해 설명한다.

– REPLICATION 란? –

데이터 베이스에서는 데이터백업/복구와 관련하여 Replication 이라는 기

능을 제공한다.

Replication은 복제를 의미하며, Replication 기능과 용도는 각각의 데이

터 베이스 특징에 따라 다르지만 기본적으로 데이터 백업과 복구를 의미하

는 것은 같다.

Mysql 에서 Replication 은 백업/복구는 물론 미러링 구축으로 활용하기

좋은 도구이다.

또한 마스터 서버의 데이터 베이스에 과부하가 걸리는 경우, Replication

을 통해 슬레이브 서버로의 효과적인 분산이 가능하다.

– Mysql Replication 의 특징 –

대략적인 기능상의 특징은 다음과 같다.

1. 마스터-> 슬레이브로의 일방향 복제기능.

2. 바이너리 로그(binlog)를 이용한 미러링.

3. 쿼리에 의한 부하 분산.

4. 다수의 슬레이브 서버를 이용한 부하 분산.

– REPLICATION 작동 원리 –

마스터와 슬레이브의 Mysql 데이터베이스를 같은 환경(매우 중요)으로 설

치하여 마스터 서버와 슬레이브 서버에 각각 Mysql 서버 고유넘버를 지정

한다. 고유넘버는 2^32-1까지 가능하다. 마스터와 슬레이브는 이 고유넘버

로 서로를 인식하여 작동하게 된다.

작동원리를 살펴보면,

Mysql Replication 은 마스터에 입력되는 쿼리를 바이너리 로그에 기록하

게 되고, 슬레이브는 마스터의 바이너리 로그의 업데이트 여부를 추적하

여 업데이트 된 경우, 바이너리 로그에 기록된 쿼리문을 슬레이브로 가져

와 처리하게 된다.

즉 실시간 미러링이 되며 마스터와 동일한 자료를 보유하게 된다.

만일 이 과정에서 에러가 발생하는 경우, 슬레이브는 에러 로그를 작성한

다. 후에 에러를 추적하여 바이너리 로그를 분석하여 유실된 자료에 대해

자동 업데이트가 가능하다.

– REPLICATION 설정 방법 –

1. 마스터와 슬레이브에 Mysql 을 설치

2. 마스터와 슬레이브 Mysql 의 데이터를 일치시킴.(mysql/var 디렉토리

이하)

3. 다음과 같은 my.cnf 파일을 마스터와 슬레이브에 각각 설정

——– 마스터 ——

[mysqld]

log-bin

server-id=1

의 내용을 작성하여 /etc/my.cnf 파일로 저장.

——– 슬레이브 ——–

[mysqld]

master-host=마스터의 IP/도메인 주소

master-user=아이디

master-password=패스워드

master-port=3306 (마스터 Mysql 포트번호)

server-id=2

의 내용을 작성하여 /etc/my.cnf 파일로 저장

여기서 중요한 것은 슬레이브의 my.cnf에 지정되는 아이디와 암호이다.

마스터에서 지정한 외부 접근(슬레이브에 대해)이 가능하고 최소 파일변

경 권한이 있는 유저이어야 한다. 잘 생각해 보면 왜 그런지 알 수 있다.

즉 슬레이브에서 마스터로 접근하는 유저가 repl 이라면, 마스터에서는 아

래와 같은 유저를 생성해 주어야 한다.

GRANT FILE ON *.* TO repl@”%” IDENTIFIED BY ‘<password>’;

그래야 Replication 을 이용한 모든 처리가 가능하다.

여기서 % 대신 슬레이브 서버의 IP만을 등록하여도 상관없다.

만일 여러 대의 슬레이브 서버를 구축하는 경우, server-id 라는 고유넘버

를 달리하여 슬레이브 설정과 같이 해 주면 된다. 단 중복되면 안됨.

이제 모든 설정이 완료되면 마스터와 슬레이브 서버를 재시작한다.

– REPLICATION 작동 확인 방법 –

설정과 Mysql 재시작이 완료되면 Replication 작동 상태를 확인한다.

먼저 마스터의 Mysql Shell로 로그인 하여

> show master status ;

를 하여 다음과 같은 메시지가 나온다면 정상이다.

+————-+———-+————–+——————+

| File | Position | Binlog_do_db | Binlog_ignore_db |

+————-+———-+————–+——————+

| sim-bin.002 | 73 | | |

+————-+———-+————–+——————+

file 에 나오는 sim-bin.002 라는 것은 현재 사용되는 바이너리 로그 파일

명이며 Position은 마지막 업데이트 된 위치 이다.

Mysql 버전에 따라 위의 메시지는 바뀔 수 있다.

다음으로 슬레이브의 Mysql Shell로 로그인 하여 작동 상태를 확인한다.

> show slave status;

를 하여 다음과 같은 메시지가 나온다면 정상적이다.

+————–+————-+————-+—————+———

—-+—–+

| Master_Host | Master_User | Master_Port | Connect_retry | Log_File

| Pos | Slave_Running |

+————–+————-+————-+—————+———

—-+—–+

| sim.tt.co.kr | chodong | 3306 | 60 | sim-bin.002 | 73 | Yes |

+————–+————-+————-+—————+———

—-+—–+

마찬가지로 마스터 서버에 대한 정보, 유저정보가 나타나고 slave

running 항목에 YES 라는 메시지가 보이면 정상 작동 중이다.

위에서 보듯이 Pos 부분에 수치(73)이 마스터와 동일하다.

또한 show processlist; 명령을 통해 각각의 프로세스 정보를 확인하는 방

법도 있다.

마스터 서버에서 show processlist ; 를 한 결과이다.

Id User Host db Command Time State Info

1 chodong 211.47.65.106 Binlog Dump 336959 Slave connection: waiting

for binlog update

위와 같이 슬레이브 서버의 접속 상태와 접속시간 등의 정보를 볼 수 있

다.

슬레이브에서 show processlist ; 한 결과이다.

Id User Host db Command Time State Info

57 system user none Connect 502778 Reading master update

마찬가지로 마스터 서버에 대한 접속 상태와 접속시간 등을 알 수 있다.

-> 실제 구축된 Replication 구경하기

+ 마스터서버 : http://sim.tt.co.kr/~sim/phpmyadmin

+ 슬레이브서버 : http://test1.tt.co.kr/~system/phpmyadmin

– REPLICATION 이 지원하지 않는 것 –

현재 Mysql Replication 은 쿼리 단위로의 미러링을 지원한다.

이에 따른 중요 문제가 발생한다.

1. RAND() in updates does not replicate properly. Use RAND

(some_non_rand_expr) if you are replicating updates with RAND(). You

can, for example, use UNIX_TIMESTAMP() for the argument to RAND().

랜덤 함수에 의해 발생되어지는 자료에 대한 업데이트가 이루어지지 않는

다. 랜덤 함수가 발생한 필드의 자료는 공란(null)로 입력된다.

2. LOAD DATA INFILE will be handled properly as long as the file

still resides on the master server at the time of update

propagation. LOAD LOCAL DATA INFILE will be skipped.

load data infile 에 의한 데이터 입력시 마스터 서버에 파일이 남아 있

는 상태에서만 가능하다. 이와는 반대로 load local data infile 은 업데

이트 되지 않는다.

– REPLICATION 활용 방안 –

1. 미러링으로 활용

마스터의 Mysql data를 실시간으로 백업 받는다.

마스터 서버에 장애가 발생하여 미러링 서버가 작동하게 되면 자연적으로

슬레이브 Mysql 이 작동하게 되며, 마스터 복구시 init.sh 를 통해 슬레이

브의 데이터를 받아오므로 거의 자료의 유실 없이 Mysql 서버를 복구할

수 있다.

그러나 위에서와 같이 Load Local INFILE 문은 Replication이 안된다는 단

점이 있다.

2. 과부하 마스터서버의 부하 분산서버로 활용

Mysql 에 과부하를 유발하는 마스터서버의 미러서버에 슬레이브를 설정하

여 쿼리문을 분산시킨다.

즉 마스터서버에서는 데이터 전송이 적은 UPDATE, INSERT, DELETE 문을 사

용하고 슬레이브서버에서는 데이터 전송이 많은 SELECT 문을 사용하도록

한다.

두대의 Mysql 서버를 사용하게 되므로 각각에 대해 유저설정을 해 주어야

한다.

– 결 론 –

Load Local INFILE 문을 지원하지 않는 문제로 호스팅 서버에서 적용하기

에는 제약이 따른다.