1.1 Replication 이란?
Replication은 3.23.15부터 지원되기 시작한 기능으로 ‘복제’라는 사전적 의미에 맞게 마스터의
MySQL 서버의 데이터를 여러 대의 슬레이브
MySQL 서버의 데이터와 동기화 시켜주는 기능이다. 주로,
MySQL의 데이터를 실시간으로 백업하거나, 데이터 서버의 부하분산을 하고자 할 때 많이 사용된다.
Dual-Master Replication을 구축하기 위해, 먼저 Master-Slave로 구성된 Replication 상태를 만들어야 한다.
1.2 How to Set Up Replication
1.2.1 MASTER 와 SLAVE 설치
MySQL을 master 와 slave 서버에 설치한다. 안정성을 위해 두 서버의 버전을 맞춰주는 것이 좋다. Replication 기능은 3.23.15부터 지원되기 시작하였으나 3.23.32부터 안정화되었다고 알려져 있으므로, 그 이상 혹은 최신 버전의
MySQL 을 설치하길 권장한다.
1.2.2 MASTER 계정생성
slave 서버에서 master 서버에 접속할 수 있도록, master 서버에 계정을 만든다. 사용자를 추가해 주어야 한다는 말이다. 이 계정에 REPLICATION SLAVE 권한을 주어야 한다. replication에만 사용할 계정이라면 추가적인 권한은 주지 않아도 된다. slave 서버에서master 서버에 접속할 계정과 패스워드에 권한을 부여하는 명령은 다음과 같다.
master mysql > GRANT REPLICATION SLAVE ON *.*
-> TO 'user_name'@'user_host' IDENTIFIED BY 'user_password';
여기서 user_name은 중복되지 않는 이름이면 되며, user_host 는 slave로 만들 서버의 주소 혹은 도메인 네임을 적어준다. 이 주소의 slave 유저만 master 서버로 접속할 수 있다. 4.0.2 이전 버전의
MySQL에서는, REPLICATION SLAVE 권한이 없으므로, 다음과 같이 FILE 권한으로 대신한다.
master mysql > GRANT FILE ON *.*
-> TO 'user_name'@'user_host' IDENTIFIED BY 'user_password';
1.2.3 MASTER 데이터 SLAVE 에 복사
master 서버의 기본 데이터를 백업 받아, slave 서버의 데이터베이스에 복사한 후, 데이터 디렉토리에서 압축을 푼다.
HOT 백업
master mysql > FLUSH TABLES WITH READ LOCK;
master shell > tar -cvf /tmp/mysql-snapshot.tar .
slave shell > tar -xvf /tmp/mysql-snapshot.tar
master mysql > UNLOCK TABLES;
mysqldump 이용 백업
master Shell > mysqldump -u root -p ‘password’ -B db_name > dump_file.sql
1.2.4 MASTER 환경설정
Master 와 Slave 의 데이터 베이스 환경을 설정한다. 우선 master 서버를 설정하도록 한다.
master shell> vi /etc/my.cnf
master 서버는 디폴트로 구성이 되어 있을 것이므로,
mysqld 섹션에 log-bin이 있는 지 확인한다.
[mysqld]
log-bin
server-id = 1
1.2.5 SLAVE 환경설정
다음은 slave 서버의 환경설정이다.
slave shell> vi /etc/my.cnf
mysqld 섹션으로 가서 server-id를 master 서버의 server-id와 다르게 설정한다. 본 문서에서는 2로 설정하도록 하겠다. slave 서버를 여러 대로 구축하고자 할 때에 각 slave 서버의 server-id는 각각 달라야 한다는 것에 주의하자. 2^32-1까지 가능하다.
[mysqld]
server-id = 2
master-host = xxx.xxx.xxx.xxx(user_host)
master-port = 3306
master-user = user_name
master-password = user_password
master 서버의 데이터를 백업 받았다면, slave 서버를 시작하기 전에 slave 서버의 데이터 디렉토리에 master 서버의 데이터를 복사해 둔다. mysqldump를 사용했다면, 다음으로 가서 먼저, slave 서버를 스타트한다.
1.2.6 SLAVE 서버 스타트
slave 서버를 스타트한다.
slave shell > /etc/init.d/mysqld start
1.2.7 SLAVE 덤프파일 LOAD
mysqldump를 사용해 백업 파일을 만들었다면, slave 서버에 덤프 파일을 로드시킨다.
slave shell > mysql -u root -p < dump_file.sql
1.2.8 MASTER 계정 설정
slave 서버에서 master-host, master-user, master-password 등의 설정을 다음과 같이 바꿀 수도 있다. 물론 /etc/my.cnf에서 설정하지 않았을 경우에도 쓸 수 있다.
slave mysql > CHANGE MASTER TO
-> MASTER_HOST='master_host_name',
-> MASTER_USER='replication_user_name',
-> MASTER_PASSWORD='replication_password',
-> MASTER_LOG_FILE='recorded_log_file_name',
-> MASTER_LOG_POS=recorded_log_position;
각 옵션의 최대 길이는 다음과 같다.
MASTER_HOST 60
MASTER_USER 16
MASTER_PASSWORD 32
MASTER_LOG_FILE 255
1.2.9 SLAVE 쓰레드 스타트
slave 쓰레드를 스타트한다.
slave mysql > START SLAVE;
1.2.10 SUCCESS CERTIFICATION
mysql/data/slave.err을 확인하여 다음과 같은 메시지가 있으면 성공적으로 설정된 것이다.
Slave I/O thread: connected to master 'user_name@user_host:3306', replication started in log 'FIRST' at position 4
1.3 How to Set Up Dual-Master Replication
우선 이후에서는 지금까지 master 라고 칭했던 서버를 mysql1 서버라고 하고, slave라 칭했던 서버를 mysql2 서버라 하겠다. 듀얼 마스터 리플리케이션을 구축할 두 대의 서버에는 동일 버전의 최신
MySQL이 설치되어 있으며, Master-Slave 리플리케이션이 구축된 상태에 있다고 간주한다.
이미 앞에서 리플리케이션 구축에 대해 자세히 설명하였으므로, 과정에 대해서만 기술하기로 하겠다.
1.3.1 SLAVE STOP
mysql2 서버로 이동한 후, mysql2 서버의 mysql 구동을 멈춘다.
mysql2 shell > /etc/init.d/mysqld stop
1.3.2 SLAVE LOG DELETE
mysql2 서버의 -bin log를 삭제한다.
1.3.3 SLAVE RESTER
mysql2 서버의 mysql을 구동시킨다.
mysql2 shell > /etc/init.d/mysqld start
1.3.4 GRANT REPLICATION SLAVE
d. mysql2 서버에서 GRANT REPLICATION SLAVE명령을 실행한다. Dual-Master란 것이 서로가 서로의 master이자 slave가 되는 것이므로, 이전의 설치에서 slave였던 mysql2가 mysql1 서버의 유저를 slave 유저로 갖게 된다.
mysql2 mysql > GRANT REPLICATION SLAVE ON *.*
-> TO 'users_name'@'users_host' IDENTIFIED BY 'users_password';
1.3.5 MASTER SETUP
이제 mysql1 서버로 이동하여, 설정을 계속한다. 우선, mysql1 서버의 mysql 구동을 멈춘다.
mysql1 shell > /etc/init.d/mysqld stop
1.3.6 MASTER CONFIGURATION
mysql1 서버의 /etc/my.cnf 파일을 수정한다.
mysqld 섹션으로 가서 mysql2 서버를 마스터로 간주하도록 정보를 추가한다.
[mysqld]
server-id = 1 <= 그대로 두고, 아래 내용을 추가한다.
master-host = users_host
master-port = 3306
master-user = users_name
master-password = users_password
1.3.7 MASTER START
mysql1 서버의 mysql을 구동시킨다.
mysql1 shell > /etc/init.d/mysqld start
1.3.8 SUCCESS CERTIFICATION
mysql/data/mysql1.err을 확인하여 다음과 같은 메시지가 있으면 성공적으로 설정된 것이다.
Slave I/O thread: connected to master 'ccotti@222.112.137.172:3306', replication started in log 'FIRST' at position 4
지금까지 별다른 문제없이 설치를 진행하였다면, 각 서버의 mysql 모니터에서 데이터를 입력하고, 두 서버가 서로 연동이 되는 것을 확인할 수 있을 것이다.
위의 설정에서 두 대의 서버 중 한 대가 장애를 일으키는 경우 한 서버를 리부팅한다고 가정할 때, 별도의 설정이 없다면 기존의
MySQL 리플리케이션 구성에서는 두 서버 간의 동기화가 원활히 일어나지 않았다. 그런 경우 다음을 순서대로 진행하며, 장애를 복구할 수 있다. 우선 mysql1 서버를 재시작해야 한다고 가정하자.
1. mysql1의 mysql/data/ 의 mysql1-bin.*를 지운다.
2. mysql1의 mysqld를 시작한다.
mysql1 shell > /etc/init.d/mysqld start
3. mysql2의 mysql 모니터에서 다음 명령어를 실행한다.
mysql2 mysql > slave stop;
mysql2 mysql > slave reset;
mysql2 mysql > slave start;
● master와 slave 데이터 일치 방법
- master mysql을 정지시키고 대상 파일들을 백업(복사) - master mysql을 구동
-> 이 후 변경사항들이 bin-log에 기록됨
- slave에 백업한 DB 파일들을 복사 후 구동
-> master의 bin-log를 참고하여 데이터 일치됨 ※ 이 때, 복사한 파일의 소유자(mysql인지?) 확인 철저 ※ my.cnf 설정에서 특정 DB를 선택한 경우 master와 slave 모두 동일하게 설정해야 함
(한 쪽은 설정하지 않고 한 쪽은 설정한 경우 오동작)
※ my.cnf 주의사항 : mysql_safe 실행 시 DB_DIR 옵션에 따라 불러오는 위치 달라짐
● slave에서 'LOAD TABLE FROM MASTER' 나 'LOAD DATA FROM MASTER' 명령을
사용하기 위해서는 replication 계정에 다음은 권한 추가 필요
- SUPER, RELOAD, SELECT 권한을 replication 계정에 부여 ● 다음 명령을 통해 mysql의 내부cache를 clear시키고 쓰기 방지 가능
※ mysql 기본 테이블인
MyISAM 테이블을 사용할 경우 - mysql> FLUSH TABLES WITH READ LOCK;
● 쓰기 방지 해제 명령
- mysql> UNLOCK TABLES;
● slave의 mysql을 replication 미적용하고 구동 방법
- /usr/local/bin/mysqld_safe --skip-slave-start ● slave 동작 구동 방법 - mysql> start slave;
※ slave 설정 미인식 등의 문제 발생 시
mysql> change master to 명령을 사용하여 설정
● replication 정상동작 확인
- mysql> show processlist;
또는 mysql> show processlist\G ; 상세한 내용 확인
- mysql> show slave status;
또는 mysql> show slave status\G ; 상세한 내용 확인 또는 mysql> show master status;
- error 로그 확인
출처 - http://wiki.kldp.org/wiki.php/MySQL%B8%AE%C7%C3%B8%AE%C4%C9%C0%CC%BC%C7
===================================================================================
#MYsql 리플리케이션이란? # Replication은 3.23.15부터 지원되기 시작한 기능으로 ‘복제’라는 사전적 의미에 맞게 마스터의 MySQL 서버의 데이터를 여러 대의 슬레이브 MySQL 서버의 데이터와 동기화 시켜주는 기능이다. 주로, MySQL의 데이터를 실시간으로 백업하거나, 데이터 서버의 부하분산을 하고자 할 때 많이 사용된다.
0. 서버 설정 1번서버 - master 서버 : 1차네임서버 : 192.168.1.
1112번서버 - slave 서버 : 2차네임서버 : 192.168.1.222
mysql 버전은 모두 mysql 5.X 이다.
두 서버 모두 mysql 데이터는 /free/mysql_data 에 위치해 있다고 가정한다.
1. Master 서버 설정
# vi /etc/my.cnf
(1) my.cnf 파일에서 #log-bin=mysql-bin 부분의 주석을 반드시 해제해준다
슬레이브 서버에서 저 바이너리 로그를 기준으로 데이터 리플리케이션을 실행 하기 때문에 저 로그파일이 꼭 필요하다!
(2) server-id = 1 로 설정한다.
마스터서버와 슬레이브서버의 번호가 서로 다르기만 하면 되기 때문에 원하는 번호를 지정한다.
# Replication Master Server (default)
# binary logging is required for replication
log-bin=mysql-bin # required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id = 1 |
(3) slave 서버 에서 접속 할 수 있는 Mysql 계정을 생성해준다
# mysql -u root -p 로 디비 접속
mysql > GRANT REPLICATION SLAVE ON *.* TO 유저명@접속허용할IP IDENTIFIED BY '패스워드';
접속허용할 IP에 특정 IP만을 부여 할 수도 있고 '%' 를 적어주면 모든 외부의 접속을 허용한다는 의미이다.
mysql > use mysql
mysql > select * from user \G;
명령로 설정이 되어 있는지 확인 할 수 있다.
아래 셋팅은 실제 마스터 서버인 1차네임서버 서버의 설정 내용이다.
접속을 허용한 유저 이름은 : nayana
nayana의 접속을 허용한 IP : 192.168.1.222 (2차 네임서버)
슬레이브 서버(192.168.1.222) 에서 nayana 라는 계정의 Replication 접속을 허용한 것을 볼 수 있다.
*************************** 10. row ***************************
Host: 192.168.1.222
User: nayana
Password: *7CC252065609E6F96DD42A08D09D6C0DDBFBB0B1
Select_priv: N
Insert_priv: N
Update_priv: N
Delete_priv: N
Create_priv: N
Drop_priv: N
Reload_priv: N
Shutdown_priv: N
Process_priv: N
File_priv: N
Grant_priv: N
References_priv: N
Index_priv: N
Alter_priv: N
Show_db_priv: N
Super_priv: N
Create_tmp_table_priv: N
Lock_tables_priv: N
Execute_priv: N
Repl_slave_priv: Y <- 요 부분이 Y로 되어있으면 된다!!
Repl_client_priv: N
Create_view_priv: N
Show_view_priv: N
Create_routine_priv: N
Alter_routine_priv: N
Create_user_priv: N
ssl_type:
ssl_cipher:
x509_issuer:
x509_subject:
max_questions: 0
max_updates: 0
max_connections: 0
max_user_connections: 0
10 rows in set (0.00 sec)
|
(4) mysql을 재시작 하고 마스터 서버의 동작을 확인한다.
"mysql-bin.000022" 라는 바이너리 로그 파일을 생성한 것을 볼 수 있다.
mysql> show master status;
+------------------------+-----------+-------------------+------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------------+-----------+-------------------+------------------------+
| mysql-bin.000022 | 8385 | | |
+------------------------+-----------+-------------------+------------------------+
1 row in set (0.00 sec) mysql> |
2. Slave 서버 설정
(1) 마스터 서버의 DB를 슬레이브 서버의 DB에 복사한다!(= 최초1회는 직접 복사해서 동기화해준다!)
이유는?
mysql 리플리케이션은 rsync와 다르게 동기화로 엮여진 시점부터의 DB변화를 동기화 시킨다.
[ 동기화 전 DB 구조]
마스터 슬레이브
1 1
2 2
3
########## 동기화 후 마스터 서버에 4 라는 DB를 추가하면? #########
[ 동기화 후 DB 구조]
마스터 슬레이브
1 1
2 2
3 4
4
이렇게 4 라는 DB만 추가되고 3이라는 DB는 추가되지 않는다. 애초에 처음부터 DB내용이 달랐기 때문!
rsync 였다면 양쪽에 모두 똑같아 졌을 것이다.
[ 마스터 서버 ]
# cd /free
# tar zcvf mysql.tar.gz mysql_data
# sz mysql.tar.gz
압축한 파일을 다운받아 슬레이브 서버의 /free/mysql_data 디렉토리에 플어준다. 이로서 최초 동기화를 완료했다.
(2) /etc/my.cnf 파일을 수정한다!
57 , 62 번 라인은 주석처리해주고 98번 라인부터는 아래와 같이 주석을 풀고 마스터 서버에 접속할 정보를 적는다.
# Replication Master Server (default)
# binary logging is required for replication
57 # log-bin=mysql-bin # required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
62 # server-id = 1 98 # but will not function as a slave if omitted
server-id = 2
# The replication master for this slave - required
master-host = 192.168.1.111
# The username the slave will use for authentication when connecting
# to the master - required
master-user = nayana
# The password the slave will authenticate with when connecting to
# the master - required
master-password = 패스워드
# The port the master is listening on.
# optional - defaults to 3306
master-port = 3306
# binary logging - not required for slaves, but recommended
log-bin=mysql-bin |
(3) mysql 을 재시작 한후 mysql에 접속하여 동기화가 되었는지 확인한다.
동기화가 정상적으로 되었다면 아래와 같이 "Waiting for master to send event" 라는 구문이 출력된다!
mysql> show slave status;
+----------------------------------+----------------+-------------+-------------+---------------+------------------+---------------------+-------------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
| Slave_IO_State | Master_Host | Master_User | Master_Port | Connect_Retry | Master_Log_File | Read_Master_Log_Pos | Relay_Log_File | Relay_Log_Pos | Relay_Master_Log_File | Slave_IO_Running | Slave_SQL_Running | Replicate_Do_DB | Replicate_Ignore_DB | Replicate_Do_Table | Replicate_Ignore_Table | Replicate_Wild_Do_Table | Replicate_Wild_Ignore_Table | Last_Errno | Last_Error | Skip_Counter | Exec_Master_Log_Pos | Relay_Log_Space | Until_Condition | Until_Log_File | Until_Log_Pos | Master_SSL_Allowed | Master_SSL_CA_File | Master_SSL_CA_Path | Master_SSL_Cert | Master_SSL_Cipher | Master_SSL_Key | Seconds_Behind_Master |
+----------------------------------+----------------+-------------+-------------+---------------+------------------+---------------------+-------------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
| Waiting for master to send event | 192.168.1.111 | nayana | 3306 | 60 | mysql-bin.000022 | 8385 | mysqld-relay-bin.000015 | 235 | mysql-bin.000022 | Yes | Yes | | | | | | | 0 | | 0 | 8385 | 235 | None | | 0 | No | | | | | | 0 |
+----------------------------------+----------------+-------------+-------------+---------------+------------------+---------------------+-------------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
1 row in set (0.00 sec) mysql> |
이제 마스터 서버에서 DB를 생성하거나 삭제하면 슬레이브 서버에서도 똑같이 동기화가 될 것이다!! 올레~!
출처 - http://www.koreaidc.com/bbs/set_view.php?b_name=idcpds&w_no=104&page=1
===================================================================================
MySQL Replication(복제)은 한 개나 2개 이상의 MySQL database server(slave)가 하나의 MySQL database server(master)로 부터 데이터를 복제해 갈 수 있는 기능을 제공한다.
MySQL Replication은 비동기 방식으로 처리된다. 즉 slave는 master로부터 데이터를 받아 복제하기 위해 항상 master에 연결되어 있을 필요가 없다.
MySQL Replication은 Binary logging mechanism을 사용하여 이뤄진다.
Master 서버는(MySQL 인스턴스)는 binary log에 변경된 데이터 정보를 기록하며 이 log를 slave가 읽어서 실행함으로써 복제가 된다.
Master에서 binary logging이 활성화되면 Master의 모든 데이터 구문이 bindary log에 저장되며 slave는 bindary log의 모든 내용을 복사해서 읽어온다.
따라서 slave는 log 파일내의 position을 유지할 필요가 있다. 그래야 로그파일 전체를 처음
부터 읽지 않고 효과적으로 로그 파일을 운영할 수 있다.
여기서 position은 로그파일내 위치를 의미하며 어느 부분부터 읽겠다는 것을 의미 한다.
Configuration에 따라 다음과 같은 단위로 복제가 이뤄질 수 있다.
l all database
l selected database
l selected tables within a database
Replication 구성 예 – Appendix A.
Replication Configuration
[ Master Configuration ]
1. Replication User 생성
slave는 master에 접속하여 데이터를 복제하기 위한 MySQL 계정이 필요하다. root를 사용해도 상관 없지만 slave에 Replication 설정을 하면(slave configureation 참조) 계정 정보가암호화되지 않은 텍스트 형태로 slave 서버의 master.info(mysql\data) 파일에 기록이 되기 때문에 보안상 root나 기타 계정을 사용하는 것을 권하지 않는다. 따라서 복제를 위한 계정을 하나 생성한다.
이 계정은 단지 REPLICATION SLAVE Privilege만 있으면 되므로 다음과 같이 계정을 생성한다.(REPLICATION SLAVE Privilege만 있으면 된다는 의미는 INSERT/UPDATE 등과 같은Privilege는 필요 없다는 의미이다. 따라서 복제 계정은 mysql query실행을 할 수 없다.)
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY 'slavepass'; |
è repl이 계정이며 slavepass가 계정의 비밀번호 이다.
è %대신 IP주소를 넣으면 그 IP로부터 접속하는 slave에 대해서만 접속을 허용하겠다는 의미(그냥 %를 사용하자..!)
n 예) ….. ON *.* TO 'repl'@'1.1.1.2' IDENTIFIED BY 'slavepass';
2. Configuration 설정(my.ini)
[mysqld] log-bin=mysql-bin server-id=1 |
è server-id는 1~(2^32)-1내의 숫자중 아무것이나 설정해도 된다.
3. MySQL 데몬 재시작
4. Master 정보 보기
mysql> FLSUSH TABLES WITH READ LOCCK; mysql> SHOW MASTER STATUS; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000001 | 98 | | | +------------------+----------+--------------+------------------+ |
è File : 로그 파일을 의미한다.
è Position : 로그 파일내 읽을 위치
è Binlog_Do_DB : binary log 파일(변경된 이벤트 정보가 쌓이는 파일)
è Binlog_Ignore_DB : 복제 제외 정보
n Binlog_Do_DB와 Binlog_Ignore_DB는 Slave 시작하기 전까지는 나타나지 않는다.
[ Slave Configuration ]
1. Configuration 설정
[mysqld] server-id=2 replicate-do-db=’database name’ |
è slave의 server-id를 정의한다. 이 1~(2^32)-1내의 숫자중 아무것이나 설정해도 되나 Master와는 다르게 한다.
è replicate-do-db: 복제할 데이터베이스를 의미한다.
n 2개 이상의 데이터 베이스 복제를 원하면 replicate-do-db를 더 추가한다.
2. database dump
복제할 데이터베이스를 master로부터 dump하여 넣는다.
3. CHANGE MASTER TO
Master로 연결하기 위한 정보를 다음과 같이 설정한다.
mysql> CHANGE MASTER TO MASTER_HOST='Master server host name or Master server IP', MASTER_USER='replication user', MASTER_PASSWORD='replication password', MASTER_LOG_FILE='Log File name', MASTER_LOG_POS=position; |
è MASTER_HOST: Master 서버의 정보를 입력한다.
è MASTER_USER: replication을 위해 생성한 계정 ID
è MASTER_PASSWORD: replication을 위해 생성한 계정 비밀번호
è MASTER_LOG_FILE: SHOW MASTER STATUS에서 보이는 로그 파일 명
è MASTER_LOG_POS: SHOW MASTER STATUS에서 보이는 position값
n SHOW MASTER STATUS는 master에서 실행해야 한다.(master 설정 참고)
4. MySQL 데몬 재시작
※ Slave가 실행이 되면(MySQL 데몬 시작 또는 slave start) master에 접속하기 위한 정보를 master.info(mysql\data)에서 읽어 온다. 만일 master.info에 아무런 정보가 없으면 my.ini를 참고하여 master.info에 연결정보를 기록한다.
여기서 주의할 점은 이미 master.info에 정보가 있으면 my.ini를 참조하지 않으므로 my.ini정보를 수정해도 master에 연결시 반영되지 않는다.
그러나 CHANGE MASTER TO를 이용하면 master.info를 바로 변경한다.
따라서 master 연결정보는 my.ini에 설정하는 것 보다는 CHANGE MASTER TO를 이용하여 설정하는게 낫다.
다음과 같은 option이 CHANGE MASTER TO에서 사용된다.
master-host
master-user
master-password
master-port
master-connect-retry
master-ssl
master-ssl-ca
master-ssl-capath
master-ssl-cert
master-ssl-cipher
master-ssl-key
[양방향 동기화 처리]
Master서버에서 Slave도 구현하고자 한다면 다음과 같은 방법으로 처리
1. 현재 Slave서버에 replication 계정 생성
2. 현재 Slave의 my.ini 변경
log-bin=mysql-bin 추가
3. 현재 SLAVE 서버 데몬 재시작
4. 현재 Master의 my.ini 변경
replicate-do-db=’database name’추가
4. 현재 Master에서 CHANGE MASTER TO 실행
5. 현재 Master 서버 데몬 재시작
Replication Monitoring
//ON Master mysql> SHOW PROCESSLIST\G *************************** 1. row *************************** Id: 11 User: repl Host: 192.168.1.22:3556 db: NULL Command: Binlog Dump Time: 21960 State: Has sent all binlog to slave; waiting for binlog to be updated Info: NULL |
Slave인 192.168.1.22가 repl계정으로 thread11에 연결되어 있음을 보여준다.
//On Slave mysql> show processlist\G *************************** 1. row *************************** Id: 1 User: system user Host: db: NULL Command: Connect Time: 23049 State: Waiting for master to send event Info: NULL *************************** 2. row *************************** Id: 2 User: system user Host: db: NULL Command: Connect Time: 4294967289 State: Has read all relay log; waiting for the slave I/O thread to update it Info: NULL |
Id 1: Master 서버와 통신하기 위한 I/O Thread
Id 2: update된 내용을 처리하기 위한 SQL Thread
위 2개의 Thread에 오류가 발생하면 안된다.
mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.14 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000004 Read_Master_Log_Pos: 9187563 Relay_Log_File: shin-relay-bin.000013 Relay_Log_Pos: 9187700 Relay_Master_Log_File: mysql-bin.000004 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: ipm3 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: 9187563 Relay_Log_Space: 9187700 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 |
Slave_IO_State: 현재 Slave의 상태를 나타낸다.(Appendix B 참고)
Slave_IO_Running: I/O Thread 상태
Slave_SQL_Running: SQL Thread 상태
Last Error: 최근에 발생한 오류, 정상인 경우 이 값은 없다.
Seconds_BeHind_Master: 이 값이 크면 클수록 Master로부터 복제할 수 없는 데이터가 많음을 나타낸다.
mysql> stop slave mysql> start slave |
MySQL 데몬(서비스)를 재 시작하면 slave는 자동으로 시작된다.(my.ini에 옵션 skip-slave-start이 있으면 자동 시작 안한다.)
Appendix A. Replication 구성 예
Figure 16.1. Using replication to improve the performance during scaleout
출처 - http://hanaduri.egloos.com/2389708
===================================================================================
MySQL Replication 개요
- 해당 글은 MySQL 4.0.x 버전에서 테스트후 작성된 글이며
공식적으로 Replication기능은 3.23 이상의 버전부터 지원되는것으로 알고 있습니다.
- 빠른 글 설명을 위해 대부분의 존칭은 생략합니다.
1. Replication 의 개요 & 필요성
나는 회사 서버에서 실제로 사용해본 데이터베이스는 MySQL과 MSSQL정도로만 압축되며,
현재 회사 서비스의 메인데이터베이스는 모두 MySQL로 이루어져있다.
좀 지난이야기이지만 데이터베이스가 엉켜(?)서 MySQL내의 특정 테이블이 말소되어버린적이 있다.
혹은 phpMyAdmin같은 웹 데이터베이스 관리 프로그램이나 MySQL-Front같은 어플리케이션 관리도구등을 사용한다면
버튼하나, 링크하나잘못 클릭해서 데이터베이스가 통째로 날라갈수가 있다.
그런데 일반 pc에서 하드포맷이나 데이터 삭제시
도스시절 unformat이나 undelete, finaldata 등등의 여러가지 방법으로 복구를 했던반면
데이터베이스는 한번 날라가면 끝이다.
데이터베이스의 보존방법은 크게 Dump를 이용한 방식과 Replication을 이용하는 방식이 있는데
두가지의 분명한 장단점이 존재한다!
ㄱ. Dump를 이용한 데이터베이스 백업의 장단점
- 문제가 생겼을때 특정 시점으로의 복원이 가능하다(덤프 받아놓은 날짜의 데이터베이스로 돌려놓을수 있다.
- 한번 덤프를 받을때 데이터가 많을수록 덤프 시간은 기하급수적으로 늘어난다.
- 한번 덤프를 받아놓은것들이 누적되면 용량이 장난아니게 불어난다.
ㄴ. Replication을 이용한 데이터베이스 백업의 장단점.
- 실시간으로 데이터를 옮겨적기때문에 원본 데이터베이스에 문제가 발생해서 서비스를 중단할 경우에도 리플리케이션서버로 대처가 가능하다.
- 특정시점으로의 복원은 불가능하다.
- Replication에 사용하는 Log를 주기적으로 비워주지 않으면 용량의압박이 상당하다.
위에서도 볼수있듯, 두가지의 가장큰 차이점은 특정시점으로의 복원여부, 그리고 실시간 백업이다.
그래서 나의 경우는 두가지 백업을 모두 애용하는 편이며, Replication은 이제 없으면 허전한 그런것이 되어버렸다.
리플리케이션의 구현시, 장점은 위에 있는게 전부가 아니다.
원본 데이터베이스(master)는 쓰기만 하고, 쿼리문 등으로 데이터베이스를 읽는 작업은 Slave에서 처리해도 가능한,
효율적인 분산작업을 위해서도 필요한것이다.
2. Replication의 설정
리플리케이션에서는 하드 IDE시절 수도없이 작업했던 Master, Slave의 개념만 잘 알고 있으면 된다.
Master는 원본데이터베이스, Slave는 백업받는 대상 데이터베이스라고 생각하면 되며, 일반적으로 알려진 리플리케이션의 설정은 다음과 같다.
(리눅스버전, MySQL 4.0 기준 설명)
ㄱ. Master의 설정
일단 처음부터 쉽게 생각하려면, Replication의 기본 구성은 다음과 같다.
a. Master에서는 데이터베이스에서 일어나는 모든 작업을 Log에 기록하게 되며, 해당 로그는 Postion 값을 가지고 있다.
b. Slave에서는 Master에 설정되어 있는 계정으로 접근하여 Master의 정보를 보게되며, Log의 Postion값을 읽어들여, 어디까지 가져왔는지를 알아내서
포지션값을 갱신하면서 데이터를 계속 긁어온다.
윗말을 정리하자면 Master는 값을 계속 기록만 하고, Slave에서는 Master로 접근후에 데이터를 계속 가져오기만 한다.
그럼 Slave에서 Master로 연결하기 위한 계정 설정은 Master에서 만들어주는것이며, 계정설정은 다음과 같은 방법으로 Master에 기록하게 된다.
GRANT file ON *.* TO 리플리케이션아이디@'아이피.아이피.아이피.아이피' IDENTIFIED BY '패스워드'
권한 설정을 할때 file대신 All privileges 권한을 줘도 무방하긴하지만, 어짜피 file에 대해서만 긁어오는 작업을 수행하므로, 기타 권한에 대해 주는것은 불필요하다
또한 아이피부분 역시 %로 대처할수도 있으나, 대부분의 리플리케이션은 같은 네트워크안에 속해있는 서버끼리 작업하는게 보통이므로 아이피는 적어주는게 좋다.
권한 설정은 다 되었으므로, my.cnf에 대한 설정방법은 다음과 같다.
(윈도우 버전은 my.ini의 설정을 고치면 된다.)
-------------------/etc/my.cnf--------------------------
[mysqld]
......
# MySQL 의 리플리케이션 기능을 사용하기 위한 binary log 설정
log-bin = /mysqltemp/log/replication.log
server-id = 1
binlog-do-db = 데이터베이스1
binlog-do-db = 데이터베이스2
--------------------------------------------------------
log-bin = 파일경로/파일이름
입력하지 않는경우 기본적으로 Mysql의 Lib Directory에 기록이 된다.
해당 로그가 쌓이게될때 용량을 무시할 수준이 아니므로 기억하기 좋은 위치로 지정해서 사용하기 바란다.
server-id = 번호
해당 아이디의 숫자는 고유한 숫자를 입력해야되며 중요한건 slave와 id가 틀려야 한다.
binlog-do-db = 데이터베이스1
해당 MySQL내에서 여러 데이터베이스중 Replication을 할 데이터베이스를 적어준다.
데이터베이스가 다수인경우 해당 구절을 계속 추가해야되며,
binlog-do-db = 데이터베이스1,데이터베이스2 식으로 추가하는건 동작하지 않는다고 알려져있다.
ㄴ. Slave의 설정
Slave에서는 아까도 이야기 했듯 Master로 접근후에 데이터베이스를 가져오기만 하므로 별도의 계정생성이 필요없으며
my.cnf 설정파일을 수정하는것으로 작업이 완료된다.
-------------------/etc/my.cnf--------------------------
[mysqld]
......
server-id = 2
master-host = 아이피.아이피.아이피.아이피
master-user = 리플리케이션아이디
master-password = 패스워드
replicate-do-db = 가져올 데이터베이스1
replicate-do-db = 가져올 데이터베이스2
master-port = 3306
--------------------------------------------------------
slave설정시 Master와 틀린건 가져올 마스터 데이터베이스의 아이피를 적어줘야한단것과(어디서 읽어올지는 알아야하니까)
접근에 필요한 계정(아까 GRANT file On...으로 생성한 계정의 아이디/패스워드)를 기록, 그리고 읽어들일 데이터베이스명
(Master의 binlog-do-db=데이터베이스1)을 기재해주어야 한다는것이다.
3. 동기화 팁
보통 리플리케이션은 백지상태에서 시작하기보다는 특정 데이터베이스가 돌아가고 있는 상황에서 리플리케이션 서버를 추가로 운영하는 경우로
발전되므로, 다음과 같은 두가지 처리방법이 있다.
※리플리케이션 동기화시에는 최대한 데이터베이스의 내용이 일치하는게 좋으므로, Master에서 더이상 DB의 입출력이 일어나지 않는 상태에서 작업하는것이 좋다.
즉. slave와 master의 mysql을 중단시켜놓고 작업을 하는것이 좋다.
(/etc/rc.d/init.d/mysql stop)
ㄱ. Dump를 이용하여 처리하는방법
- 데이터베이스를 덤프뜬후, Slave에서 Restore시키는 방식, 단점으론 시간이 굉장히 많이 소모되므로 추천하지 않는다.
ㄴ. MySQL 데이터 디렉토리를 통째로 옮기는 방법
- 권장하는 방식이며, 데이터베이스가 위치한곳 (/var/lib/mysql또는 /var/db같은...)을 통째로 압축해서 복사하거나, 아니면 그냥 복사하는 방식이다.
본인은 Linux(AnnyungLinux 1.2)서버에서 다른 리눅스서버(AnnyungLinux 1.2)로 옮길때 한번에 2기가 이상은 ftp에서 옮겨지지 않는 기현상(? 단일 파일 2G이상 생성 불가. 파티션형태...) 이 발생하여
다음과 같은 처리를 하였다.
a. tar cvfpz - sourcedirectory | split -b 1500m - databasebackup.tar.gz (1.5G로 분할 압축) - Master에서 가져올 디렉토리를 압축
b. Slave에 접근후 ftp -> open 아이피.아이피.아이피.아이피, -> 압축파일 경로로 변경 -> get databasebackup.tar.gz
c. 가져온후 마스터측의 압축은 삭제, 복사작업등의 권한(chown,chmod)등은 적절하게 설정
4. 리플리케이션의 실제 동작명령
동기화가 완료되었다면 mysql에서 다음과 같은 명령어로 여러 동작들을 확인 가능하다.
(아이피는 임의처리하였다)
먼저 master 서버의 상태를 보자.
ㄱ. show processlist; - 현재 동작하고 있는 processlist를 확인가능하다.
mysql> show processlist;
+--------+----------+----------------------+---------+-------------+--------+----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+--------+----------+----------------------+---------+-------------+--------+----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
| 8 | replsvr | ***.***.***.***:**** | NULL | Binlog Dump | 747916 | Has sent all binlog to slave; waiting for binlog to be updated | NULL
ㄴ. show master status; - 리플리케이션 마스터의 동작 상태, 포지션값등을 알수있다.
mysql> show master status;
+-----------------+-----------+---------------+------------------+
| File | Position | Binlog_do_db | Binlog_ignore_db |
+-----------------+-----------+---------------+------------------+
| replication.002 | 351161171 | test1, test2 | |
+-----------------+-----------+---------------+------------------+
1 row in set (0.00 sec)
여기서 중요한건 file에서 replication.002에 현재 기록중인것을 알고 있으며, slave측에서 001등을 다 가져온 상태라면 해당 로그(replication.001)는 지워도 무방하다.
slave의 상태는 다음과 같이 확인 가능하다.
mysql> show processlist;
+----+-------------+-----------+------+---------+--------+-----------------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-------------+-----------+------+---------+--------+-----------------------------------------------------------------------+------------------+
| 2 | system user | | NULL | Connect | 748267 | Waiting for master to send event | NULL |
| 3 | system user | | NULL | Connect | 8 | Has read all relay log; waiting for the I/O slave thread to update it | NULL |
ㄷ. 동일하게 show slave status로 slave의 상태와 포지션값을 알수있다.(아이피, port 임의처리)
mysql> show slave status;
+----------------+-------------+-------------+---------------+-----------------+---------------------+-------------------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+------------+------------+--------------+---------------------+-----------------+
| Master_Host | Master_User | Master_Port | Connect_retry | Master_Log_File | Read_Master_Log_Pos | Relay_Log_File | Relay_Log_Pos | Relay_Master_Log_File | Slave_IO_Running | Slave_SQL_Running | Replicate_do_db | Replicate_ignore_db | Last_errno | Last_error | Skip_counter | Exec_master_log_pos | Relay_log_space |
+----------------+-------------+-------------+---------------+-----------------+---------------------+-------------------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+------------+------------+--------------+---------------------+-----------------+
| ***.***.**.*** | replsvr | **** | 60 | replication.002 | 355000057 | wisereplication-relay-bin.003 | 355000141 | replication.002 | Yes | Yes | test1,test2 | | 0 | | 0 | 355000057 | 355000141 |
+----------------+-------------+-------------+---------------+-----------------+---------------------+-------------------------------+---------------+-----------------------+------------------+-------------------+-----------------+---------------------+------------+------------+--------------+---------------------+-----------------+
이때 중요한것은 master status와 slave status를 봤을때 읽어들이는 파일명(위에서는 replication.002)와 Postion을 비교해서 차이가 나지 않으면 성공한것이다.
ㄹ. 그외 명령어
reset Master;
reset slave;
위의 명령어로 둘의 포지션값과 로그파일 생성을 초기화 시킬수 있다.
slave stop;
master stop;
위의 명령어로 리플리케이션 서버의 동작정지를 시킬수 있다.
slave start;
master start;
위의 명령어로 리플리케이션 서버의 정지를 해제하고 다시 가동시킬수 있다.
5. 그 외의 환경 실험.
예전 리플리케이션을 구현할때 4.0과 4.1에서도 서로 리플리케이션이 가능했다.
4.0과 5.0간에는 테스트 해보지 않았으나 충돌이 발생할 확률이 지대일듯 하다.
(가급적 같은 버전을 쓰자?)
또한 리눅스(master), 윈도우즈(slave)같은 환경에서도 제대로 동작했다.
(운영체제는 가리지 않는다. 단지 윈도우즈/MySQL 조합은 그리 권장하는 조합이 아니란건...)
6. 끝으로
얼마전 윈도우즈 서버 해킹으로 인해 윈도우즈의 스케쥴 관리 기능을 이용해 매일 특정시간 주기적으로 데이터베이스를 덤프했는데
둘다 리눅스 머신으로 바뀌면서 Crontab, 쉘스크립트등의 사용법을 몰라서 아직 매일 Dump작업을 못하고 있는 실정이다.
다음 강좌에서 저말고 누군가 리눅스에서 crontab을 쓰는방법과 쉘스크립트 작성법등을 강좌 해주면 캐감사하겠다.
출처 - http://docs.cena.co.kr/?mid=textyle&category=13634&document_srl=17327
