1.1.3. 리플리케이션 옵션과 변수

 

이 섹션에서는 슬레이브 리플리케이션 서버에서 사용할 수 있는 옵션들을 설명하기로 한다. 이 옵션들은 명령어 라인 또는 옵션 파일에서 지정할 수 있다.

마스터와 각 슬레이브에서 고유의 리플리케이션 ID를 설정하기 위해서는 반드시 server-id 옵션을 사용해야 한다. 각 서버는 1 에서 2³² – 1 사이의 양수 정수 중의 고유 값을 사용해야 하고, 각 ID는 반드시 다른 ID와 구분이 되어야 한다. 예: server-id=3.

실행 중에 있는 리플리케이션 구성이 고의적으로 변경되지 않았음을 확인하기 위한 옵션들은 다음과 같다:

• --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

MySQL 5.1.17 버전 이후에는 위 옵션들을 사용하지 않는다. 위 옵션들이 변경하는 설정 값은 mysqld가 시작될 때 무시되고 mysqld 로그에 있는 경고문이 나오게 된다. 리플리케이션으로 구성하기 위해서는 반드시 CHANGE MASTER TO ... 명령문을 사용해야 한다.

MySQL 5.1.16 이전 버전에서는 master.info 파일이 존재한다면 위 옵션들이 무시된다 (즉, MySQL 서버가 이미 리플리케이션으로 구성되어 있는 경우).  이 파일이 존재하고 위 옵션들이 my.cnf 파일에 들어 있거나 또는 명령어 라인 옵션으로 mysqld에 제공되더라도, 그것들은 무시되고 master.info에 들어 있는 정보를 대신 사용한다.

MySQL 5.0의 master.info 파일 포맷은 SSL 옵션과 상응되는 값을 가진다. 또한, 이 파일 포맷은 자신의 첫 라인에 파일의 전체 라인 수를 가지고 있다.  구형 서버 (4.1.1 이전 버전)를 새로운 버전으로 업그레이드 한다면, 새로운 서버는 시작 시점에 자동으로 master.info 파일을 새로운 포맷으로 업그레이드 시킨다. 하지만, 새 버전에서 구형 버전으로 다운그레이드를 하는 경우에는, 구형 버전의 서버를 맨 처음 시작하기 전에 수동으로 처음 라인을 제거해야 한다.

슬레이브 서버를 시작할 때 master.info 파일이 존재하지 않는다면, 슬레이브는 옵션 파일 또는 명령어 라인에서 지정한 옵션 값을 대신 사용한다. 서버를 처음으로 리플리케이션 서버로 구동 시키거나, 또는 RESET SLAVE를 구동 시킨 후에 슬레이브를 셧다운하고 다시 시작하면 이런 일이 발생한다.

슬레이브 서버를 시작할 때 master.info 파일이 존재한다면, 서버는 이 파일의 내용을 사용하게 되며 파일에 올라와 있는 값에 대응되는 옵션들을 무시한다. 따라서, master.info 파일 값에 대응되는 스타트업 옵션 값과는 다른 것으로 슬레이브 서버를 시작한다면, 서버가 master.info 파일 값을 계속 사용하기 때문에 다르게 적용된 값은 무시 된다. 다른 값을 사용하기 위해서는 반드시 master.info 파일을 제거한 다음에 재 시작을 하거나 또는 슬레이브가 구동하고 있는 동안에 그 값을 리셋하기 위한 CHANGE MASTER TO 명령문을 사용해서 재 시작을 하도록 한다.

이 옵션을 my.cnf 파일에 지정했다고 가정하자:

 

[mysqld]

master-host=some_host

 

서버를 리플리케이션 슬레이브로 처음 구동하면, 서버는 my.cnf 파일에서 그 옵션을 읽어서 사용한다. 그런 다음에, 서버는 그 값을 master.info 파일에 기록한다. 다음 번에 서버를 구동하면, 서버는 master.info 파일에서만 마스터 호스트 값을 읽게 되고 옵션 파일에 있는 값은 무시한다. some_other_host의 마스터 호스트를 다르게 지정하기 위해 my.cnf 파일을 수정한다고 하더라도 변경 내용은 적용되지 않는다. 변경 내용이 적용되도록 하기 위해서는 CHANGE MASTER TO를 사용해야 한다.

위에서 설명하였듯이, 서버는 스타트업 옵션 대신에 이미 존재하고 있는 master.info 파일에 우선권을 주기 때문에 CHANGE MASTER TO 명령문을 사용해서 이 값들을 대신 지정하도록 한다.

아래의 예문은 슬레이브 서버를 구성하기 위해 스타트업 옵션을 보다 광범위하게 사용하는 방법을 보여주는 것이다:

 

[mysqld]

server-id=2

master-host=db-master.mycompany.com

master-port=3306

master-user=pertinax

master-password=freitag

master-connect-retry=60

report-host=db-slave.mycompany.com

 

아래의 리스트는 리플리케이션을 제어하는데 사용하는 스타트업 옵션들이다. 이 옵션들 대부분은 서버가 구동되고 있는 동안에 CHANGE MASTER TO 명령문을 사용해서 리셋 시킬 수 있다. --replicate-* 옵션과 같은 것들은 슬레이브 서버가 시작될 때에만 설정될 수 있다.

• --log-slave-updates

일반적으로, 슬레이브는 마스터 서버에서 전달 받은 업데이트를 자신의 바이너리 로그에 기록하지 않는다. 이 옵션은 SQL 쓰레드가 실행한 업데이트를 자신의 바이너리 로그에 기록하도록 만든다. 슬레이브를 바이너리 로깅을 활성화 시키기 위한 --log-bin 옵션과 함께 시작해야만 이 옵션이 적용된다. --log-slave-updates는 리플리케이션 서버를 서로 연결할 때 사용하는 것이다. 아래와 같은 배열을 사용해서 리플리케이션 서버를 설정한다고 가정하자:

 

 A -> B -> C

 

여기에서, A는 슬레이브 B에 대해 마스터 역할을 하고, B는 슬레이브 C에 대해 마스터 역할을 한다. 이렇게 동작하기 위해서는, B가 반드시 마스터인 동시에 슬레이브가 되어야 한다. 바이너리 로깅을 활성화 시키기 위해서는 A와 B 모두에서 --log-bin 옵션을 실행해야 하고, A에서 받은 업데이트를 B가 자신의 바이너리 로그에 기록할 수 있도록 B는 --log-slave-updates 옵션을 실행해야 한다.

• --log-warnings[=level]

이 옵션은 에러 로그에 보다 자세한 메시지를 기록하도록 만든다. 리플리케이션 관점에서 보면, 서버는 네트워크 접속 실패 후에 지속적으로 접속을 다시 시도하는 경고문을 만들며, 각각의 슬레이브가 어떻게 시작되는지에 대한 정보를 알려 준다. 이 옵션은 디폴트로 활성화 된다; 이것을 비활성화 시키기 위해서는, --skip-log-warnings를 사용한다. 단절된 접속은 이 값이 1보다 크지 않는 한 에러 로그에 기록되지 않는다.

• --master-connect-retry=seconds

마스터가 다운 되거나 또는 접속이 끊어지는 경우에, 마스터에 재 접속을 시도하기 전에 슬레이브 쓰레드가 슬립 (sleep)하는 시간. master.info 파일에 있는 값이 우선권을 가진다. 이것을 설정하지 않으면, 디폴트는 60이 된다. 재 연결 시도 횟수는 --master-retry-count 옵션으로 설정한다.

• --master-host=host_name

마스터 리플리케이션 서버의 호스트 이름 또는 IP 번호. master.info에 있는 값이 우선권을 갖는다. 마스터 호스트를 지정하지 않으면, 슬레이브 쓰레드를 시작할 수 없다.

• --master-info-file=file_name

슬레이브가 마스터 정보를 기록하는 파일 이름. 디폴트는 데이터 디렉토리에 있는 mysql.info가 된다.

• --master-password=password

슬레이브가 마스터에 접속을 할 때 슬레이브 쓰레드가 인증용으로 사용하는 계정의 패스워드. master.info 파일에 있는 값이 우선권을 가지게 된다. 이것을 설정하지 않으면, 패스워드가 비어 있다고 생각한다.

• --master-port=port_number

마스터가 슬레이브 접속을 기다리는 (listening) TCP/IP 포트 번호. master.info 파일에 있는 값이 우선권을 가진다. 이것을 설정하지 않으면, 이미 설정이 컴파일 되어 있다고 가정을 한다 (일반적인 경우 3306).

• --master-retry-count=count

슬레이브가 마스터에 접속을 시도하는 횟수 (접속 포기 전까지). 디폴트는 86400.

• --master-ssl, --master-ssl-ca=file_name, --master-ssl-capath=directory_name, --master-ssl-cert=file_name, --master-ssl-cipher=cipher_list, --master-ssl-key=file_name

이 옵션은 SSL을 사용하는 마스터 서버 보안 리플리케이션 접속 설정용으로 사용된다. master.info 파일에 있는 값들이 우선권이 있다.

• --master-user=user_name

슬레이브가 서버에 접속할 때 슬레이브 쓰레드가 인증용으로 사용하는 계정의 사용자 이름. 이 계정은 반드시 REPLICATION SLAVE 권한을 가지고 있어야 한다. master.info 파일 값이 우선권이 있다. 마스터 사용자 이름을 설정하지 않았다면, 사용자 이름은 test라고 가정한다.

• --max-relay-log-size=size

서버가 자동으로 릴레이 로그 파일을 순환시키는 크기. 디폴트 크기는 1GB이다.

• --read-only

슬레이브는 자신의 쓰레드 또는 SUPER 권한 사용자가 보내는 업데이트 이외에는 어떠한 업데이트도 하지 못하도록 한다. 즉, 슬레이브 서버가 클라이언트에서 오는 업데이트를 받아들이지 못하도록 만드는 옵션이다. TEMPORARY 테이블에는 이 옵션이 적용되지 않는다.

• --relay-log=file_name

릴레이 로그용 이름. 디폴트 이름은 host_name-relay-bin.nnnnnn이며, 여기에서 host_name은 슬레이브 서버 호스트 이름이고, nnnnnn는 릴레이 로그가 이만큼의 시퀀스로 생성되었음을 가리키는 것이다. 호스트 이름과는 무관한 릴레이 로그 이름을 생성하고자 하는 경우, 또는 릴레이 로그가 점점 커지고 (그리고 max_relay_log_size의 크기를 줄이고 싶지 않으며) 이 릴레이 로그들을 데이터 디렉토리가 아닌 다른 곳에 저장하고 싶은 경우, 또는 디스크 간 로드 밸런싱을 통해 속도를 증가 시키고자 할 경우에 이 옵션을 지정하도록 한다.

• --relay-log-index=file_name

릴레이 로그 인덱스 파일의 이름. 디폴트 이름은 데이터 디렉토리 내에 있는 host_name-relay-bin.index이며, 여기에서 host_name은 슬레이브 서버의 이름이 된다.

• --relay-log-info-file=file_name

릴레이 로그 정보를 기록하기 위한 파일의 이름. 디폴트 이름은 데이터 디렉토리 내에 있는 relay-log.info가 된다.

• --relay-log-purge={0|1}

릴레이 로그가 더 이상 필요 없게 되는 순간에 자동으로 이 로그를 비워 버리는 (purging)것을 활성화 또는 비 활성화 시킨다. 디폴트는 1 (활성화)임. 이것은 SET GLOBAL relay_log_purge = N을 사용해서 동적으로 변경 시킬 수 있는 글로벌 변수이다.

• --relay-log-space-limit=size

이 옵션은 슬레이브에 있는 모든 릴레이 로그 전체의 최대 크기 (바이트 단위)를 지정한다. 이 값이 0 이면 “제한 없음 (no limit)”을 의미한다. 제한된 디스크 공간을 가지고 있는 슬레이브 서버 호스트에 유용한 옵션이다. 제한 값에 도달하면, I/O 쓰레드는 SQL 쓰레드를 사용하지 않는 릴레이 로그를 가져와서 제거하기 전까지 마스터 서버에서 오는 바이너리 로그 이벤트를 읽지 않는다. 이 제한 값은 절대적인 것이 아니라는 것을 알아두자: SQL쓰레드는 릴레이 로그를 삭제하기 전에 보다 많은 이벤트를 요구하는 경우가 있다. 이러한 경우, I/O 쓰레드는 SQL 쓰레드가 몇몇 릴레이 로그를 삭제할 수 있을 때까지 제한치를 초과하게 되는데, 그렇게 하지 않으면 데드락 (deadlock)이 생길 수 있기 때문이다. --relay-log-space-limit 값은 --max-relay-log-size (또는 --max-relay-log-size가 0 일 경우에는, --max-binlog-size) 값의 두 배 보다는 작게 설정하지 말도록 한다. 그렇지 않으면, --relay-log-space-limit가 초과되기 때문에 I/O 쓰레드는 사용 가능 공간을 기다리게 되지만, SQL 쓰레드는 깨끗이 비워야 할 릴레이 로그를 가지지 않게 되기 때문에 I/O 쓰레드를 만족시키지 못하게 된다. 이것은 I/O 쓰레드가 임시적으로 --relay-log-space-limit를 무시하게끔 만들어 버린다.

• --replicate-do-db=db_name

리플리케이션을 제한하도록 서버에게 지시한다. 한 개 이상의 데이터 베이스를 지정하기 위해서는, 각각의 데이터 베이스 별로 한 번씩 이 옵션을 사용한다. 이 옵션을 사용하면, 서로 다른 데이터 베이스를 선택했거나 또는 아무런 데이터 베이스도 선택하지 않는 동안에는 UPDATE some_db.some_table SET foo='bar'와 같이 크로스-데이터베이스 (cross-database) 명령문을 복제하지 않는다는 점을 알아두자.

 

Warning

여러 개의 데이터베이스를 지정하기 위해서는, 이 옵션에 대한 인스턴스를 여러 개 사용해야 한다. 데이터베이스 이름에는 콤마가 들어 있기 때문에,  콤마로 구분된 리스트를 제공한다면, 제공된 리스트는 하나의 데이터베이스 이름으로 처리가 될 것이다.

 

예상하는 것과는 다르게 동작하는 예를 보자: 슬레이브가 --replicate-do-db=sales와 함께 시작되고 마스터에서 아래와 같은 명령문을 입력했다면, UPDATE 명령문은 복제되지 않는다:

 

USE prices;

UPDATE sales.january SET amount=amount+1000;

이렇게 “디폴트 데이터 베이스를 단지 검사만 하는” 동작이 일어나는 주된 이유는, 명령문 하나만 가지고서는 명령문을 복제할지 또는 하지 말아야 할지를 알기가 어렵기 때문이다 (예를 들면, 다중-테이블 DELETE 명령문 또는 여러 개의 데이터 베이스를 넘나드는 다중-테이블 UPDATE 명령문을 사용 중일 경우). 전체 데이터 베이스를 검색할 필요가 없는 경우에는 당연히 디폴트 데이터 베이스만 검사하는 것이 빠를 것이다.

크로스-데이터 베이스 업데이트를 수행할 필요가 없다면, --replicate-wild-do-table=db_name.%를 대신 사용하도록 한다.

• --replicate-do-table=db_name.tbl_name

지정한 테이블로만 복제하도록 슬레이브 쓰레드에게 지시한다. 한 개 이상의 테이블을 지정하기 위해서는, 각각의 테이블 별로 한 번씩 이 옵션을 사용한다. 이 옵션은--replicate-do-db와는 반대로 크로스-데이터 베이스에 대해서도 동작을 한다.

• --replicate-ignore-db=db_name

디폴트 데이터 베이스가 (즉, USE가 선택하는 것) db_name인 곳에서는 모든 명령문을 복제하지 않도록 서버에게 지시한다. 한 개 이상의 데이터 베이스를 무시하도록 하기 위해서는, 각각의 데이터 베이스 별로 한번씩 이 옵션을 사용한다. 크로스-데이터 베이스 업데이트를 사용하고 있고 이러한 데이터 베이스들이 업데이트 되는 것을 원하지 않을 경우에는 이 옵션을 사용하지 말도록 한다.

기대하는 것처럼 동작하지 않는 예를 보자: 슬레이브가 --replicate-ignore-db=sales와 함께 시작되고 아래와 같은 명령문을 마스터에서 입력하였다면, UPDATE 명령문은 복제되지 않는다:

 

USE prices;

UPDATE sales.january SET amount=amount+1000;

크로스-데이터 베이스 업데이트를 실행하고자 한다면, --replicate-wild-ignore-table=db_name.%를 대신 사용한다.

• --replicate-ignore-table=db_name.tbl_name

동일한 명령문이 다른 모든 테이블을 업데이트하더라도 지정 테이블에 대한 업데이트 명령문은 모두 복제하지 말도록 슬레이브에게 지시한다. 한 개 이상의 테이블을 무시하도록 지정하기 위해서는, 각각의 테이블 별로 한번씩 이 옵션을 사용한다. 이것은 --replicate-ignore-db와는 반대로 크로스-데이터 베이스 업데이트를 실행한다.

• --replicate-rewrite-db=from_name->to_name

마스터 상에서 디폴트 데이터 베이스 (즉, USE가 선택하는 것)가 from_name이었다면, 그것을 to_name로 해석하도록 슬레이브에게 지시한다. 테이블을 포함하는 명령문에만 영향을 주며 (CREATE DATABASE, DROP DATABASE, 그리고 ALTER DATABASE와 같은 명령문은 제외), 마스터에서 디폴트 데이터 베이스가 from_name일 경우에만 영향을 준다. 이것은 크로스-데이터 베이스를 업데이트 하지 않는다. 데이터 베이스 이름을 해석하는 것은 --replicate-* 규칙을 테스트 하기 전에 이루어 진다.

 이 옵션을 명령어 라인에서 사용하고 ‘>’ 문자가 명령어 해석기에서 특수 문자로 받아 들여진다면, 인용 부호를 사용해서 이 옵션 값을 지정하도록 한다. 예를 들면:

 

shell> mysqld --replicate-rewrite-db="olddb->newdb"

• --replicate-same-server-id

슬레이브 서버에서 사용됨. 일반적으로는 디폴트 설정 값인 0을 사용하는데, 이값은 순환 리플리케이션 (circular replication)에 의한 무한 루프를 방지한다. 이 값을 1로 설정한다면, 슬레이브는 자신의 서버 ID를 가지고 있는 이벤트를 건너 띄지 않게 된다. 1로 설정하는 경우는 거의 없다. --log-slave-updates가 사용된다면, 1로 설정할 수 없다. 디폴트로, 슬레이브 I/O 쓰레드는 바이너리 로그 이벤트가 슬레이브 서버 ID를 가지고 있는 경우에는 그것을 릴레이 로그에 기록조차 하지 않는다는 것을 알아두자 (이것은 디스크 사용량을 절감시키는데 도움이 된다). 따라서, --replicate-same-server-id를 사용하고자 한다면, 슬레이브 SQL 쓰레드가 실행하길 원하는 이벤트를 읽게끔 만들기 전에 이 옵션과 함께 슬레이브가 실행되도록 해야 한다.

• --replicate-wild-do-table=db_name.tbl_name

업데이트된 모든 테이블이 지정 데이터 베이스와 테이블 이름 패턴을 매치 (match)하는 곳에서는 명령문 리플리케이션을 제한하도록 슬레이브 쓰레드에게 지시한다. 이러한 패턴에는 ‘%’ 및 ‘_’ 와일드 카드 문자가 포함될 수 있는데, 이것들은 LIKE 패턴-매칭 연산자에 대한 것과 동일한 의미를 가진다. 한 개 이상의 테이블을 지정하기 위해서는, 각각의 테이블 별로 한번씩 이 옵션을 사용한다. 이것은 크로스-데이터 베이스 업데이트를 실행한다.

예제: --replicate-wild-do-table=foo%.bar%는 데이터 베이스 이름이 foo로 시작되고 테이블 이름이 bar로 시작되는 곳에서 테이블을 사용하는 업데이트만을 복제한다

테이블 이름 패턴이 %이라면, 모든 테이블 이름 및 데이터베이스-레벨 명령문에도 적용되는 옵션들을 매치 (match)한다 (CREATE DATABASE, DROP DATABASE, 그리고 ALTER DATABASE). 예를 들면, --replicate-wild-do-table=foo%.%를 사용한다면, 데이터 베이스 이름이 패턴 foo%와 매치가 되는 경우에 데이터 베이스-레벨 명령문을 복제한다.

데이터 베이스 또는 테이블 이름 패턴에 와일드 카드 문자를 포함 시키기 위해서는, 그 문자들을 백슬레시 (backslash)를 사용해서 이스케이프 (escape) 시킨다. 예를 들면, my_own%db라는 이름의 데이터 베이스에 있는 모든 테이블은 복제하지만 my1ownAABCdb 데이터 베이스로부터는 테이블을 복제하고 싶지 않다면, ‘_’와 ‘%’문자를 다음과 같이 이스케이프 (escape)시켜야 한다: --replicate-wild-do-table=my\_own\%db. 명령어 라인에서 이 옵션을 사용한다면, 사용하는 명령어 해석기에 따라서 인용 부호나 이중 (double) 백슬래시를 사용해서 옵션 값을 지정해야 한다. bash 쉘을 사용할 경우에는, --replicate-wild-do-table=my\\_own\\%db라고 입력해야 한다.

• --replicate-wild-ignore-table=db_name.tbl_name

입력한 와일드카드 패턴과 테이블이 하나라도 매치가 되는 곳에서는 명령문을 복제하지 못하도록 슬레이브 쓰레드에게 지시한다. 한 개 이상의 테이블을 무시하도록 지정하기 위해서는, 각각의 테이블 별로 한번씩 이 옵션을 사용한다. 이것은 크로스-데이터 베이스 업데이트를 실행한다.

예제: --replicate-wild-ignore-table=foo%.bar%는 데이터 베이스 이름이 foo로 시작되고 테이블 이름이 bar로 시작되는 곳에서 테이블을 사용하는 업데이트는 복제하지 않는다.

매칭 작업이 어떻게 이루어지는지에 대해서는, --replicate-wild-do-table 옵션을 설명하는 부분을 참고한다. 옵션 값에 와일드카드 문자를 포함하기 위한 규칙은 --replicate-wild-ignore-table에 적용되는 것과 동일하다.

• --report-host=slave_name

슬레이브를 등록 (registration)하는 동안에 마스터에 보고되는 슬레이브 호스트 이름 또는 IP 번호. 이것은 마스터 서버에서 SHOW SLAVE HOSTS 실행하면 얻을 수 있다. 슬레이브를 마스터에 등록하고 싶지 않을 경우에는 이 값을 설정하지 않는다. 슬레이브 접속 후에 TCP/IP 소켓에서 슬레이브 IP 번호를 마스터가 단순히 읽는 것만으로는 충분하지 못하다는 점을 알아두자. NAT및 다른 라우팅 (routing) 이슈 때문에 해당 IP가 마스터 또는 다른 호스트에서 슬레이브로 접속을 하기 위한 값이 아닐 수 있다.

• --report-port=slave_port_num

슬레이브를 등록하는 동안에 마스터에 보고되는 슬레이브 접속용 TCP/IP 포트 번호. 슬레이브가 디폴트 포트가 아닌 것에 존재하거나, 또는 마스터 서버 또는 다른 클라이언트에서 슬레이브로 접속을 하기 위한 특별 터널 (tunnel)을 가지고 있는 경우에만 이 값을 설정한다. 확신이 없다면, 이 값을 설정하지 않도록 한다.

• --report-password=password

슬레이브가 등록되는 동안 마스터에 보고되는 슬레이브 계정 패스워드. --show-slave-auth-info 옵션을 사용하면, 마스터에서 SHOW SLAVE HOSTS 명령문으로 이 값을 확인할 수 있다.

• --report-user=user_name

슬레이브가 등록되는 동안 마스터에 보고되는 슬레이브 계정 사용자 이름. --show-slave-auth-info 옵션을 사용하면, 마스터에서 SHOW SLAVE HOSTS 명령문으로 이 값을 확인할 수 있다.

• --show-slave-auth-info

--report-user 및 --report-password 옵션과 함께 실행된 슬레이브의 사용자 이름과 패스워드를 마스터 서버의 SHOW SLAVE HOSTS 명령문 결과로 출력한다.

• --skip-slave-start

서버가 시작될 때 슬레이브 쓰레드를 시작하지 말도록 서버에게 지시한다. 나중에 슬레이브 쓰레드를 시작하기 위해서는, START SLAVE 명령어를 사용한다.

• --slave_compressed_protocol={0|1}

이것을 1로 설정하면, 슬레이브/마스터 프로토콜에 대해서 압축을 사용한다 (양쪽 서버가 모두 지원을 할 경우).

• --slave-load-tmpdir=file_name

슬레이브가 임시 파일을 만드는 디렉토리의 이름. 이 옵션은 tmpdir 시스템 변수 값과 동일한 것을 디폴트로 사용한다. 슬레이브 SQL 쓰레드가 LOAD DATA INFILE 명령문을 복제할 때, 이 쓰레드는 릴레이 로그에서 읽어 와서 임시 파일에 저장할 파일을 추출하고, 그 파일을 테이블에 전달한다.  마스터에 있는 그 파일이 매우 큰 것이라면, 슬레이브에 있는 임시 파일도 역시 큰 것이 된다. 따라서, 이 옵션은 충분한 사용 가능 공간을 가지고 있는 파일 시스템 디렉토리에 임시 파일을 저장하도록 슬레이브에 지시할 때 사용을 권장한다. 그와 같은 경우, 릴레이 로그 역시 크기 때문에 그 파일 시스템에 릴레이 로그를 저장하기 위해서는 --relay-log 옵션을 함께 사용할 필요가 있다.

이 옵션으로 지정된 디렉토리는 디스크 기반 파일 시스템 (메모리 기반이 아님)에 위치해야 하는데, 그 이유는 LOAD DATA INFILE을 복제하기 위한 임시 파일은 머신이 재 시작될 때에도 존재해야 하기 때문이다. 또한, 그 디렉토리는 시스템 스타트업 과정 중에 OS가 제거할 수 없어야 한다.

• --slave-net-timeout=seconds

접속이 끊어져서 읽기가 중단 되었기 때문에 재 접속을 시도해야 한다고 슬레이브가 판단을 하기 전에 마스터에서 오는 데이터를 기다리는 대기 시간. 첫 번째 재 접속은 이 타임 아웃이 끝나면 즉시 시도된다. 재 시도 간격 (interval)은 --master-connect-retry 옵션으로 제어할 수 있다. 디폴트는 3600 초임 (1 시간).

• --slave-skip-errors=[err_code1,err_code2,...|all]

일반적으로, 슬레이브에서 에러가 발생하면 리플리케이션은 중단된다. 이러한 경우에는 데이터 일관성을 수동으로 해결해야 한다. 이 옵션은 옵션 값에 열거되어 있는 에러 중의 하나를 명령문이 리턴 하더라도 리플리케이션을 계속 진행하도록 슬레이브 SQL 쓰레드에게 지시한다.

에러 발생 원인에 대해 충분히 이해하고 있지 않으면 이 옵션을 사용하지 말도록 한다.  리플리케이션 설정과 클라이언트 프로그램에 오류가 없고 (no bug), MySQL 자체에도 오류가 없다면, 리플리케이션을 중단 시키는 에러는 결코 발생하지 않을 것이다.

에러 코드에 대해서는, 슬레이브 에러 로그와 SHOW SLAVE STATUS 결과에 나와 있는 에러 메시지 번호를 사용한다.