스마트웹앱콘텐츠전문가/데이터베이스

mysql replication(양방향 복제)

9D4U 2019. 12. 3. 11:23
728x90
반응형

MySQL Replication은 하나의 MySQL 서버(마스터 서버)에서 다른 MySQL 서버(슬레이브 서버)로 데이터를 복제하는 기술입니다. 이를 통해 데이터의 가용성, 백업, 부하 분산 등을 개선할 수 있습니다. MySQL Replication은 주로 마스터-슬레이브 복제, 마스터-마스터 복제그룹 복제 방식으로 구성할 수 있습니다.

 

 

 


1. MySQL Replication 기본 개념

 

 

1.1. 마스터-슬레이브 복제 (Master-Slave Replication)

  • 마스터 서버에서 발생한 변경사항(INSERT, UPDATE, DELETE 등)을 슬레이브 서버에 실시간으로 복제하는 방식입니다.
  • 마스터 서버에서 데이터를 변경하면 그 변경 사항이 슬레이브 서버에 전파됩니다.
  • 슬레이브 서버는 읽기 전용으로 설정되어, 주로 데이터 읽기 요청을 처리하는 데 사용됩니다. 마스터 서버는 데이터 쓰기를 처리합니다.

 

1.2. 마스터-마스터 복제 (Master-Master Replication)

  • 두 서버가 서로 마스터가 되어, 양방향으로 데이터 복제가 이루어집니다.
  • 각 서버는 읽기쓰기 작업을 모두 처리할 수 있으며, 데이터를 상호 복제합니다.
  • 마스터-마스터 복제는 데이터의 이중화와 가용성을 높이는 데 사용됩니다. 그러나 충돌을 방지하기 위한 추가적인 설정이 필요할 수 있습니다.

 

1.3. 그룹 복제 (Group Replication)

  • MySQL 5.7 이후 도입된 그룹 복제는 다수의 MySQL 서버 간에 자동으로 데이터를 동기화하는 기능입니다.
  • 이는 멀티 마스터 환경을 지원하며, 여러 서버가 서로 데이터를 복제하고, 장애 발생 시 자동으로 리더를 선출하는 방식입니다.
  • 그룹 복제는 동시 쓰기 작업을 처리하며, 데이터의 일관성과 가용성을 보장합니다.

 

 

 


2. MySQL Replication 작동 원리

 

MySQL Replication은 두 주요 구성 요소로 이루어져 있습니다:

  1. 이벤트 기록 (Binary Log): 마스터 서버는 모든 데이터를 변경하는 작업을 binary log(binlog)에 기록합니다.
  2. 슬레이브 서버의 이벤트 읽기: 슬레이브 서버는 마스터의 binary log를 읽어 자신에게 적용합니다.

 

2.1. 마스터 서버

  • binary log (binlog): 마스터 서버에서 수행된 데이터 변경 사항을 기록합니다. 이 로그는 슬레이브 서버가 데이터를 복제하는 데 사용됩니다.
  • 마스터 서버는 트랜잭션 ID이벤트를 포함한 binlog를 슬레이브 서버에 전송합니다.

 

2.2. 슬레이브 서버

  • IO 쓰레드: 슬레이브 서버는 마스터 서버의 binlog를 읽고, 이를 relay log라는 별도의 로그에 저장합니다.
  • SQL 쓰레드: relay log에 기록된 binlog 이벤트를 실행하여 데이터 변경을 슬레이브 서버에 적용합니다.

 

 

 

반응형

 

 


3. MySQL Replication 설정 방법

 

3.1. 마스터 서버 설정

  1. MySQL 설정 파일 수정 (my.cnf 또는 my.ini)
    • 마스터 서버에서 다음과 같은 설정을 추가합니다:
    [mysqld]
    server-id = 1   # 고유한 서버 ID (슬레이브 서버와 구분)
    log-bin = mysql-bin  # binary log 활성화
    binlog-do-db = your_database_name  # 복제할 데이터베이스 선택
    
  2. MySQL 재시작:
  3. sudo service mysql restart
  4. 마스터 서버에서 복제 사용자 생성:
  5. CREATE USER 'replication_user'@'%' IDENTIFIED BY 'password'; GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'%'; FLUSH PRIVILEGES;
  6. 현재 바이너리 로그 위치 확인:출력 예시:이 정보를 슬레이브 서버에 전달합니다.
  7. +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000001 | 154 | your_database_name | | +------------------+----------+--------------+------------------+
  8. SHOW MASTER STATUS;

 

3.2. 슬레이브 서버 설정

  1. MySQL 설정 파일 수정 (my.cnf 또는 my.ini)
    • 슬레이브 서버에서 다음과 같은 설정을 추가합니다:
    [mysqld]
    server-id = 2  # 고유한 서버 ID (마스터와 구분)
    
  2. 슬레이브 서버에서 복제 설정:
    • 슬레이브 서버에서 마스터 서버의 정보를 사용하여 복제를 설정합니다:
    CHANGE MASTER TO
      MASTER_HOST='master_server_ip',
      MASTER_USER='replication_user',
      MASTER_PASSWORD='password',
      MASTER_LOG_FILE='mysql-bin.000001',
      MASTER_LOG_POS=154;
    
  3. 슬레이브 서버 시작:
  4. START SLAVE;
  5. 슬레이브 서버 상태 확인:출력에서 Slave_IO_Running과 Slave_SQL_Running이 Yes이면 복제가 정상적으로 작동하고 있는 것입니다.
  6. SHOW SLAVE STATUS\G

 

 

 


4. MySQL Replication의 장점과 단점

 

장점

  • 데이터 가용성 향상: 마스터 서버의 데이터가 슬레이브 서버에 복제되어 장애 발생 시 빠르게 대체할 수 있습니다.
  • 부하 분산: 읽기 요청을 슬레이브 서버에서 처리하여 마스터 서버의 부하를 줄일 수 있습니다.
  • 백업: 슬레이브 서버를 사용하여 주기적인 백업을 수행할 수 있습니다.

 

단점

  • 지연 문제: 슬레이브 서버에 데이터가 복제되는 데 시간이 걸리기 때문에 마스터-슬레이브 간 데이터 지연이 발생할 수 있습니다.
  • 데이터 충돌: 마스터-마스터 복제에서는 데이터 충돌을 방지하기 위한 추가적인 관리가 필요합니다.
  • 복잡성: 복제 환경이 복잡해지고, 장애 처리 및 모니터링이 어려울 수 있습니다.

 

 

 


5. MySQL Replication 활용 사례

 

  • 읽기 부하 분산: 여러 슬레이브 서버를 두고, 읽기 작업을 슬레이브 서버에서 처리하여 마스터 서버의 부하를 분산합니다.
  • 데이터 백업: 슬레이브 서버를 백업 서버로 활용하여 마스터 서버의 데이터를 안전하게 보관합니다.
  • 지리적 분산: 여러 지역에 복제된 서버를 두어 데이터의 가용성을 높입니다.

 

 

 


6. 양방향 복제 구성 예시

 

양방향 복제는 서로가 master임과 동시에 slave라는 의미.

-------환경-----

db 서버1(mariadb) - 192.168.0.32(centos7)

db 서버2(mariadb) - 192.168.0.69(centos7)

 

mariadb는 서버1,2 모두 동일한 버전

-----------------

 

[공통 사항 : 서버1과 서버2 모두 적용]

1. replication 계정을 생성

mysql> grant replication slave on *.* to 'repl_user'@'192.168.%' identified by 'test456';

 

[서버1]

1. my.cnf 수정

~]# vi /etc/my.cnf

[mysqld]에서 log-bin과 server-id 내용을 추가한다.

 

2. 서비스 재시작

~]# systemctl restart mariadb

 

3. my.cnf 수정 내용 적용되었는 지 확인.

mysql > show variables like 'server_id';

 

4. 서버2에서 작업해주어야 할 값들 확인.

mysql > show master status\G;

File값과 Position값 기억.

[서버2]

1. my.cnf 수정

~]# vi /etc/my.cnf

[mysqld]에서 log-bin과 server-id 내용을 추가한다.

 

2. 서비스 재시작

~]# systemctl restart mariadb

 

3. my.cnf 수정 내용 적용되었는 지 확인.

mysql > show variables like 'server_id';

 

4. 서버1에서 작업해주어야 할 값들 확인.

mysql > show master status\G;

File값과 Position값 기억.

[서버1]

서버2에서 확인한 File, Position값을 가지고, Master 서버로 연결 설정

(mysql > stop slave;) 

mysql> change master to master_host='192.168.0.69', master_user='repl_user', master_password='test456', master_log_file='mysql-bin.000008', master_log_pos= 245;

(mysql > start slave; )

[서버2]

서버1에서 확인한 File, Position값을 가지고, Master 서버로 연결 설정

(mysql > stop slave; ) 생략가능

mysql > change master to master_host='192.168.0.32', master_user='repl_user', master_password='test456', master_log_file='mysql-bin.000007', master_log_pos= 1571;

(mysql > start slave; ) 생략가능

 

 

cf) Master 설정은 my.cnf 에서도 가능함.

 

[공통]

DB 서버 재시작

~]# systemctl restart mariadb;

 

결과 확인 :

서버1, 서버2에서 

결과 중 Slave_IO_Running, Slave_SQL_Running이 Yes로 되어 있는지 확인.

 


 

 

 

 

MySQL Replication은 데이터 가용성, 부하 분산, 백업 및 장애 복구를 위한 중요한 기술입니다. 복제의 설정은 복잡할 수 있으므로 각 단계에서 정확한 설정을 확인하고 테스트하는 것이 중요합니다. 복제 방식에 따라 성능 및 관리 측면에서 장단점이 있기 때문에, 시스템에 맞는 복제 구성을 선택하는 것이 중요합니다.

 

 

 

728x90