1.1.1. 리플리케이션 설정 방법

1.1.1.1. 리플리케이션 사용자 생성하기

1.1.1.2. 리플리케이션 마스터 구성 설정하기

1.1.1.3. 리플리케이션 슬레이브 구성 설정하기

1.1.1.4. 마스터 리플리케이션 정보 가져오기

1.1.1.5. mysqldump를 사용해서 데이터 스냅샷 생성하기

1.1.1.6. 로우 (Raw) 데이터 파일을 사용해서 데이터 스냅샷 생성하기

1.1.1.7. 새로운 마스터와 슬레이브를 사용해서 리플리케이션 설정하기

1.1.1.8. 현재 존재하는 데이터를 사용해서 리플리케이션 설정하기

1.1.1.9. 현재의 리플리케이션 환경에 새로운 슬레이브 추가하기

1.1.1.10. 슬레이브 서버에 마스터 구성 설정하기

이 섹션에서는 MySQL 서버 리플리케이션을 완벽하게 설정하는 방법을 설명하고 있다. 리플리케이션을 설정하는 방법은 여러 가지가 있기 때문에, 사용자 환경에 가장 적절하다고 판단되는 방식을 사용해서 리플리케이션을 구축하도록 한다.

모든 리플리케이션 설정 단계에서 고려해야 할 사항들은 다음과 같다:

• 리플리케이션용 바이너리 로그를 마스터에서 읽어 오기 위한 슬레이브 사용자를 생성한다.
• 바이너리 로그를 활성화 하고 고유 ID를 사용하도록 마스터 서버를 구성한다.
• 마스터에 연결할 각 슬레이브는 반드시 고유 ID를 사용하도록 한다.
• 데이터 스냅샷 또는 리플리케이션을 시작하기 전에, 마스터 바이너리 로그의 위치를 기록해 두도록 한다. 이것은 슬레이브가 이벤트를 실행할 위치 정보이다.
• 이미 마스터에 데이터가 있고 슬레이브로 하여금 이 데이터에 동기화 되도록 만들기 위해서는, 데이터베이스에 대한 데이터 스냅샷을 생성해야 한다. 스냅샷은 mysqldump 또는 데이터 파일 복사본을 사용해서 만들 수 있다
• 마스터 호스트 이름, 로그인 인증서 및 바이너리 로그 이름과 위치 정보와 같은 마스터 설정 값을 사용해서 슬레이브를 구성할 수 있다.

Note        

리플리케이션을 설정하기 위해서는 SUPER 권한이 필요하다는 점을 알아두기 바란다.

1.1.1.1. 리플리케이션 사용자 생성하기

각각의 슬레이브는 표준 사용자 이름과 패스워드를 사용해서 마스터 서버에 연결해야 한다. 또한, 리플리케이션용 사용자는 반드시 REPLICATION SLAVE 권한을 가지고 있어야 한다.

리플리케이션을 위한 특정 사용자를 생성할 필요는 없지만, 사용자 정보는 반드시 master.info 파일 안에 일반 문장으로 저장되어 있어야 한다. 따라서, 리플리케이션 프로세스만을 처리하는 사용자를 생성할 수 있다.

리플리케이션을 처리할 수 있는 사용자를 생성하거나 또는 이미 존재하는 사용자에게 리플리케이션 권한을 부여하기 위해서는 GRANT 명령문을 사용한다. 리플리케이션만을 처리하는 사용자를 새로 생성한다면, 그 사용자는 REPLICATION SLAVE 권한만을 가지도록 한다. 예를 들면, repl이라는 사용자가 도메인 midomain.com 안에 있는 모든 호스트에 리플리케이션 접속을 하도록 만들고자 한다면:

mysql> GRANT REPLICATION SLAVE ON *.*

    -> TO 'repl'@'%.midomain.com' IDENTIFIED BY 'slavepass';

각 슬레이브 서버 별로 서로 다른 사용자를 생성하거나, 또는 동일한 사용자를 생성할 수 있다.

1.1.1.2. 리플리케이션 마스터 구성 설정하기

리플리케이션을 구동하기 위해서는 마스터 서버에 바이너리 로깅이 활성화 되어야 한다. 바이너리 로깅이 활성화 되지 않으면 리플리케이션을 사용할 수 없다.

리플리케이션 그룹 안에 있는 각각의 서버는 반드시 고유의 server-id를 가지고 있어야 한다. 서버 ID는 그룹 안에서 각 서버를 구분하기 위한 것이며, 반드시 1 과 (2³²)-1) 사이의 양수 정수 값으로 설정되어야 한다.

서버 ID를 설정하기 위해서는, MySQL 서버를 셧 다운 시킨 후에 my.cnf 또는 my.ini 파일 구성을 편집하도록 한다.

[mysqld] 섹션 안에 있는 구성 파일에 아래의 옵션을 추가하도록 한다. 이 옵션들이 이미 존재하기는 하지만 코멘트 처리되어 있다면, 코멘트 처리를 해지한 후에 원하는 형태로 변경하도록 한다. 예를 들면, 바이너리 로깅을 활성화 하고자 한다면, mysql-bin이라는 로그 파일 이름을 사용해서 서버 ID를 1로 설정한다:

[mysqld]

log-bin=mysql-bin

server-id=1

1.1.1.3. 리플리케이션 슬레이브 구성 설정하기

슬레이브 서버에서는 고유 슬레이브 ID만 설정하면 된다:

[mysqld]

server-id=2

여러 대의 슬레이브를 설정하는 경우에는, 각 슬레이브 별로 반드시 서로 다른 server-id 값을 설정하도록 한다.

server-id 값을 지정하지 않으면, master-host를 지정하지 않는 경우에는 1로 설정되고, 그렇지 않으면 2로 설정된다. server-id를 생략하면, 마스터는 모든 슬레이브 연결을 거부하고, 슬레이브는 마스터에 연결할 수 없게 된다. 따라서, server-id를 생략하는 것은 바이너리 로그를 사용한 백업을 실행할 때에만 유용하다.

리플리케이션을 활성화 하기 위해서는 슬레이브에서 바이너리 로깅을 활성화할 필요는 없다. 하지만, 슬레이브에서 바이너리 로깅을 활성화 하면, 바이너리 로그를 사용해서 슬레이브에서 데이터 백업과 크래시 복구를 할 수 있고, 슬레이브를 보다 복잡한 리플리케이션 환경으로 구성할 수 있다는 장점이 있다.

1.1.1.4. 마스터 리플리케이션 정보 가져오기

슬레이브에서 리플리케이션을 구성하기 위해서는, 마스터 바이너리 로그 안에 있는 마스터의 현재 위치를 알아야 한다. 슬레이브는 마스터의 현재 위치에서 리플리케이션 프로세스를 시작한다.

리플리케이션을 시작하기 전에 슬레이브에 전달해서 동기화를 이루어야 하는 데이터를 마스터가 가지고 있다면, 마스터에서 명령문 처리를 중단한 후에 현재 위치를 가져 오고, 데이터를 덤프한다. 명령문을 멈추지 않은 채로 데이터를 덤프 한다면, 마스터 상태 정보가 동기화 되지 않기 때문에 슬레이브 데이터베이스와 동기화가 이루어지지 않거나 또는 크래시가 발생하게 된다.

다음의 단계를 실행해서 마스터 상태 정보를 가져 오도록 한다:

1.      명령어 라인 클라이언트를 시작한 후에 FLUSH TABLES WITH READ LOCK 명령문을 실행해서 모든 테이블을 플러시 (flush)한 후에 쓰기 연산 명령문을 잠근다:

 mysql> FLUSH TABLES WITH READ LOCK;

InnoDB 테이블의 경우에는 FLUSH TABLES WITH READ LOCK 명령문 역시 COMMIT 연산을 잠근다는 점을 알아두자.

Warning

읽기 연산 잠금이 계속 유효하도록 FLUSH TABLES 명령문이 실행되는 동안에는 클라이언트를 종료하지 말도록 한다. 클라이언트를 종료하면, 잠금도 해제가 된다.

2.      SHOW MASTER STATUS 명령문을 실행해서 마스터의 현재 바이너리 로그 이름과 오프 셋을 알아본다:

mysql > SHOW MASTER STATUS;

+---------------+----------+--------------+----------------+

| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+---------------+----------+--------------+----------------+

| mysql-bin.003 | 73       | test         | manual,mysql     |

+---------------+----------+--------------+----------------+

File 컬럼은 로그 이름을 보여주며, Position은 파일 안에 있는 오프셋 (offset)을 보여준다. 이 예제에서 보면, 바이너리 로그 파일은 mysql-bin.003 이고 오프셋은 73이다. 이 값들을 기록해 둔다. 이 값들은 슬레이브를 설정할 때 필요하며, 슬레이브가 마스터에서 새로운 업데이트를 진행할 때의 리플리케이션 위치를 나타내는 것이다.

바이너리 로깅이 활성화 되기 전에 마스터가 구동 되었다면, SHOW MASTER STATUS 또는 mysqldump --master-data가 출력하는 로그 이름과 위치 값은 비어 있게 된다. 이와 같은 경우에는, 나중에 슬레이브 로그 파일과 위치를 지정할 때 사용하는 값들이 빈 스트링 ('') 및 4가 된다.

이제, 슬레이브는 리플리케이션을 구동하기 위한 바이너리 로그 읽기 시작 위치 정보를 가지게 되었다.

1.1.1.5. mysqldump를 사용해서 데이터 스냅샷 생성하기

현재 존재하는 마스터 데이터베이스의 데이터를 스냅샷 하는 방법 중의 하나는 mysqldump 툴을 사용하는 것이다. 일단 데이터 덤프가 만들어지면, 슬레이브가 리플리케이션을 시작하기 전에 슬레이브에 덤프한 데이터를 전달하도록 한다.

mysqldump를 사용해서 데이터 스냅샷을 만들기 위해서는 다음과 같이 한다:

• 서버에서 테이블을 잠그지 않았다면:

명령어 라인 클라이언트를 시작한 후에 FLUSH TABLES WITH READ LOCK 명령문을 사용해서 모든 테이블을 플러시한 후에 쓰기 명령문을 잠그도록 한다:

mysql> FLUSH TABLES WITH READ LOCK;

SHOW MASTER STATUS 명령문을 실행해서 슬레이브를 시작할 때 사용할 바이너리 로그 상세 정보는 반드시 기록해 두도록 한다. 스냅샷 시점과 바이너리 로그 위치는 반드시 일치해야 한다.

다른 세션에서, 데이터베이스 전체 또는 특정 데이터베이스에 대한 덤프를 mysqldump로 실행한다:

shell> mysqldump --all-databases --lock-all-tables >dbdump.db

• --master-data 옵션을 사용해서 덤프를 실행할 수 있는데, 이 옵션을 사용하면 리플리케이션 프로세스를 시작하기 위해 필요한 CHANGE MASTER 명령문이 자동으로 슬레이브에 첨부된다.

shell> mysqldump --all-databases --master-data >dbdump.db

1.1.1.6. 로우 (Raw) 데이터 파일을 사용해서 데이터 스냅샷 생성하기

데이터베이스가 매우 큰 경우에는, mysqldump 툴을 사용하는 것 보다 로우 (raw) 데이터 파일을 복사해서 각 슬레이브에 전달하는 것이 더욱 효과적이다.

하지만, 복잡한 캐시와 (또는) 로깅 알고리즘을 사용하는 스토리지 엔진 테이블에서 이 방법을 사용하면 완벽한 “정시 (in time)” 스냅샷이 만들어지지 않을 수 있는데, 그 이유는 아무리 글로벌 읽기 잠금을 확보하였다고 하더라도 캐시 정보와 로깅 업데이트가 적용되지 않을 수 있기 때문이다.

예를 들면, 글로벌 읽기 잠금을 가지고 있다면 InnoDB 테이블에 대한 파일 시스템 스냅샷을 시작할 수 있다. 내부적으로는 (InnoDB 스토리지 엔진 내부) 스냅샷이 일관되게 유지되지는 않지만 (InnoDB 캐시는 플러시되지 않기 때문에), 염려하지 않아도 되는데, 그 이유는 InnoDB가 이것을 스타트업 시점에 해석해서 일관된 값을 전달하기 때문이다. 즉, InnoDB가 이 스냅샷에서 시작될 때 아무런 충돌 없이 크래시 복구 (crash recovery)를 수행할 수 있다는 것을 의미하는 것이다. 하지만, InnoDB 테이블의 스냅샷을 일관성 있게 유지하는 동안에는 MySQL 서버를 종료할 수는 없다.

로우 데이터 스냅샷은 cp 또는 copy와 같은 표준 복사 툴, scp 또는 rsync와 같은 원격 복사 툴, zip 또는 tar와 같은 아카이빙 툴, 또는 dump와 같은 파일 시스템 스냅샷 툴을 사용해서 만든다. 특정 데이터베이스에 대해서만 리플리케이션을 실행한다면, 해당 테이블에 관련된 파일만을 복사하도록 한다. InnoDB의 경우, innodb_file_per_table 옵션을 활성화 시키지 않으면 모든 데이터베이스에 들어 있는 모든 테이블이 하나의 파일에 저장된다.

특히, 아카이브에서는 다음과 같은 파일을 제외할 수 있다:

• mysql 데이터베이스 관련 파일.
• master.info 파일.
• 마스터의 바이너리 로그 파일.
• 모든 릴레이 로그 파일.

로우 데이터 스냅샷을 사용해서 가장 일관성 있는 결과를 얻고자 한다면, 스냅샷을 진행하는 동안에는 서버를 셧다운 시키도록 한다:

1.      읽기 잠금을 획득한 후에 마스터 상태 정보를 가져온다.

2.      다른 세션에서 MySQL 서버를 셧다운 시킨다:

shell> mysqladmin shutdown

3.      MySQL 데이터 파일 복사본을 만든다. 아래의 여러 가지 방식 중에 하나를 실행하면 된다:

shell> tar cf /tmp/db.tar ./data

shell> zip -r /tmp/db.zip ./data

shell> rsync --recursive ./data /tmp/dbdata

4.      마스터에서 MySQL 인스턴스를 시작한다.

    데이터베이스를 셧다운 시키지 않은 채로 마스터에서 시스템 스냅샷을 만들기
    위해서는 다음과 같이 한다:

1.      읽기 잠금을 획득한 후에 마스터 상태 정보를 가져온다.

2.      MySQL 데이터 파일 복사본을 만든다. 아래의 여러 가지 방식 중에 하나를 실행하면 된다:

shell> tar cf /tmp/db.tar ./data

shell> zip -r /tmp/db.zip ./data

shell> rsync --recursive ./data /tmp/dbdata

InnoDB 테이블을 사용하고 있다면, InnoDB Hot Backup 툴을 사용하도록 한다.

3.      읽기 잠금을 획득한 클라이언트에서 잠금을 해제 시킨다:

  mysql> UNLOCK TABLES;

일단 데이터베이스 복사본 또는 아카이브를 만들고 나면, 슬레이브 리플리케이션을 실행하기 전에 각 슬레이브에 복사한 파일을 전달하도록 한다.

1.1.1.7. 새로운 마스터와 슬레이브를 사용해서 리플리케이션 설정하기

새로운 마스터와 슬레이브를 사용해서 리플리케이션을 설정하는 것은 매우 쉽다.

새로운 마스터와 슬레이브 간에 리플리케이션을 설정하기 위해서는 다음과 같이 진행한다:

1.      필요한 구성 요소를 사용해서 MySQL 마스터를 구성한다.

2.      MySQL 마스터를 시작한다.

3.      리플리케이션 사용자를 생성한다.

4.      마스터 리플리케이션 상태 정보를 가져온다.

5.      읽기 잠금을 해제한다:

 mysql> UNLOCK TABLES;

6.      슬레이브에서 MySQL 구성을 편집한다.

7.      MySQL 슬레이브를 시작한다.

8.      마스터 리플리케이션 서버 구성을 설정하기 위한 CHANGE MASTER 명령어를 실행한다.

새로운 서버를 사용해서 리플리케이션을 구성하는 경우에는 읽어올 데이터가 없기 때문에 어떠한 정보도 복사하거나 가져올 필요가 없다.

현재 존재하는 데이터베이스의 데이터를 사용해서 새로운 리플리케이션을 설정하고자 한다면, 마스터에서 덤프 파일을 구동 시키도록 한다. 데이터베이스 업데이트는 자동으로 슬레이브에 전달된다:

shell> mysql -h master < fulldb.dump

1.1.1.8. 현재 존재하는 데이터를 사용해서 리플리케이션 설정하기

현재 존재하는 데이터를 사용해서 리플리케이션을 설정하는 경우에는, 리플리케이션 서비스를 시작하기 전에 어떤 방식으로 마스터 데이터를 가져와서 슬레이브에 전달하는 것이 가장 효과적인지를 결정해야 한다.

현재 존재하는 데이터를 사용해서 리플리케이션을 설정하는 기본 과정은 다음과 같다:

1.      server-id 및 바이너리 로깅을 아직 구성하지 않았다면, 마스터 서버를 셧다운 시킨 후에 이 옵션들을 구성하도록 한다.

2.      서버가 이미 올바르게 구성되어 있다면, 마스터 서버 상태 정보를 가져온 후에 mysqldump 또는 로우 데이터 스냅샷 방식을 사용해서 스냅샷을 만들도록 한다.

3.      MySQL 마스터를 구동한 후에, 슬레이브가 사용할 사용자 계정을 생성한다.

4.      슬레이브 구성을 업데이트 한다.

5.      다음 단계는 어떻게 마스터 스냅샷을 만들었는지에 따라서 달라진다.

mysqldump를 사용하였다면:

a.      슬레이브를 --skip-slave 옵션과 함께 시작해서 리플리케이션이 구동되지 않도록 한다.

b.      덤프 파일을 가져온다:

 shell> mysql < fulldb.dump

로우 데이터 파일을 사용해서 스냅샷을 만들었다면:

c.      데이터 파일을 슬레이브 데이터 디렉토리에 넣는다:

 shell> tar xvf dbdump.tar

파일 퍼미션과 소유권을 가지고 있어야 한다.

d.      슬레이브를 --skip-slave 옵션과 함께 시작한다.

6.      마스터 상태 정보를 사용해서 슬레이브를 구성한다. 이렇게 하면 리플리케이션을 시작하기 위해 필요한 바이너리 로그 파일 및 위치 정보가 슬레이브에게 전달된다.

7.      슬레이브 쓰레드를 시작한다:

  mysql> START SLAVE;

이 과정을 실행하고 나면, 슬레이브는 마스터에 연결이 되고, 스냅샷이 만들어진 이후에 발생한 모든 업데이트를 마스터에서 가져오게 된다.

마스터 server-id 옵션을 설정하지 않으면, 슬레이브는 마스터에 연결되지 않는다.

슬레이브 server-id 옵션을 설정하지 않았다면, 슬레이브 에러 로그에 다음과 같이 에러 메시지가 들어가게 된다:

Warning: You should set server-id to a non-0 value if master_host is set; we will force server id to 2, but this MySQL server will not act as a slave.

여러 가지 다른 이유로 인해 슬레이브가 리플리케이션을 구동하지 못하는 경우에도 해당 에러 메시지가 슬레이브 에러 로그에 기록된다.

일단 슬레이브가 리플리케이팅 되면, 슬레이브 데이터 디렉토리에 master.info 및 relay-log.info 파일이 존재하게 된다. 슬레이브는 이 두 파일들을 사용해서 자신이 실행한 마스터 바이너리 로그 트랙을 관리한다. 이 두 파일들은 특별한 경우가 아니라면 삭제 또는 편집을 하지 않도록 한다. 삭제 또는 편집을 해야 하는 경우가 발생하더라도, 리플리케이션 파라미터를 수정하는 CHANGE MASTER TO 명령문을 사용하는 것이 더욱 현명하다. 슬레이브는 이 명령문에서 지정한 값을 사용해서 상태 파일을 자동으로 업데이트한다.

일단 마스터 서버의 스냅샷을 만들고 나면, 그것을 사용해서 다른 슬레이브를 동일한 방식으로 설정할 수 있다. 마스터 서버의 스냅샷을 다시 만들 필요는 없는 것이다.

1.1.1.9. 현재의 리플리케이션 환경에 새로운 슬레이브 추가하기

현재의 리플리케이션 환경에 새로운 슬레이브를 추가하고자 한다면, 마스터를 셧다운 시키지 않은 채로 설정을 진행할 수 있다. 즉, 슬레이브에 설정을 복사하면 된다.

슬레이브를 복사하기 위해서는:

1.      기존 슬레이브를 셧다운 시킨다:

shell> mysqladmin shutdown

2.      기존 슬레이브 데이터 디렉토리를 복사해서 새로운 슬레이브에 전달한다. 로그 파일과 릴레이 로그 파일까지 모두 복사하도록 한다.

3.      기존 슬레이브의 master.info 및 relay.info 파일을 복사해서 새로운 슬레이브에 전달한다. 이 파일들은 현재의 로그 위치를 가지고 있다.

4.      기존 슬레이브를 시작한다.

5.      새 슬레이브의 구성 파일을 편집해서 새로운 고유 server-id를 부여한다.

6.      새 슬레이브를 시작한다; 리플리케이션은 master.info 파일 옵션을 사용해서 시작하게 된다.

1.1.1.10. 슬레이브 서버에 마스터 구성 설정하기

슬레이브가 마스터와 리플리케이션 통신을 하도록 설정하기 위해서는, 통신에 필요한 정보를 슬레이브에 전달해야 한다. 관련 정보를 슬레이브에 전달하기 위해서는 아래의 명령문을 슬레이브에서 실행한다:

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;

아래의 테이블은 각 스트링-값 옵션들이 사용할 수 있는 최대 길이를 나타내는 것이다: