http://simonshin.egloos.com/2247545
리플리케이션 스타트업 옵션들
이 섹션에서는 여러분이 슬레이브 리플리케이션 서버에서 사용할 수 있는 옵션들에 대해 설명하기로 한다. 이 옵션들은 명령어 라인 또는 옵션 파일에서 지정할 수 있다.
마스터와 각 슬레이브에서, 여러분은 고유의 리플리케이션 ID를 설정하기 위해서 반드시 server-id옵션을 사용해야 한다. 각 서버의 경우, 여러분은 1 에서 232 – 1 사이의 양수 정수 중의 고유 값을 사용해야 하고 각 ID는 반드시 다른 ID와 구분이 되어야 한다. 예: server-id=3.
바이너리 로깅을 제어하기 위한 마스터 옵션들은 Section 5.12.3, “바이너리 로그”에서 설명을 한다.
어떤 슬레이브 리플리케이션 옵션들은 슬레이브가 그 옵션 값을 가지고 시작될 때 master.info파일이 존재한다면 무시가 되는 것과 같은 형태로 특별히 취급되는 것들이 있다. 아래의 옵션들이 이런 방식으로 처리된다:
· --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.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는 여러분이 리플리케이션 서버를 서로 연결 (chain) 할 때 사용하는 것이다. 예를 들면, 아래와 같은 배열을 사용해서 리플리케이션 서버를 설정한다고 가정하자:
A -> B -> C
여기에서, A는 슬레이브B에 대한 마스터 역할을 하고, B는 슬레이브 C에 대해 마스터 역할을 한다. 이렇게 동작하기 위해서는, B가 반드시 마스터인 동시에 슬레이브가 되어야 한다. 바이너리 로깅을 활성화 시키기 위해 A와 B 모두에서 --log-bin옵션을 실행해야 하고, A에서 받은 업데이트를 B가 자신의 바이너리 로그에 기록할 수 있도록 B는 --log-slave-updates옵션을 실행해야 한다.
· --log-warnings
이 옵션은 에러 로그에 보다 자세한 메시지를 기록하게끔 만든다. 리플리케이션 관점에서 보면, 서버는 네트워크/접속 실패 후에 지속적으로 접속을 다시 시도하는 경고문을 만들며, 각각의 슬레이브가 어떻게 시작되는지에 대한 정보를 여러분에게 알려 준다. 이 옵션은 디폴트로 활성화 된다; 이것을 비활성화 시키기 위해서는, --skip-log-warnings를 사용한다. 단절된 접속은 이 값이 1보다 크지 않는 한 에러 로그에 기록되지 않는다.
· --master-connect-retry=seconds
마스터가 다운 되거나 또는 접속이 끊어지는 경우에, 마스터에 재 접속을 시도하기 전에 슬레이브 쓰레드가 슬립 (sleep)하는 시간. master.info파일에 있는 값이 우선권을 가진다. 설정되지 않으면, 디폴트는 60이 된다.
· --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
슬레이브가 마스터에 접속을 시도하는 횟수 (접속 포기 전까지).
· --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을 사용하는 마스터 서버 보안 리플리케이션 접속 설정용으로 사용된다. 각각의 의미는Section 5.9.7.5, “SSL 명령어 옵션”에서 설명하고 있는 --ssl, --ssl-ca, --ssl-capath, --ssl-cert,--ssl-cipher, --ssl-key옵션들과 같다. master.info파일에 있는 값들이 우선권이 있다.
· --master-user=user_name
슬레이브가 서버에 접속을 할 때 슬레이브 쓰레드가 인증을 위해 사용하는 계정의 사용자 이름. 이 계정은 반드시 REPLICATION SLAVE권한을 가지고 있어야 한다. master.info파일 값이 우선권이 있다. 만일 마스터 사용자 이름이 설정되지 않았다면, 사용자 이름을 test라고 가정한다.
· --max-relay-log-size=size
서버가 자동으로 릴레이 로그 파일을 순환시키는 크기. 자세한 정보는 Section 6.3.4, “리플리케이션릴레이 및 상태 파일”를 참조할 것.
· --read-only
슬레이브는 자신의 쓰레드가 보내거나 SUPER권한 사용자가 보내는 업데이트 이외에는 어떠한 업데이트도 하지 못하도록 한다. 즉, 슬레이브 서버가 클라이언트에서 오는 업데이트를 받아들이지 못하도록 만드는 옵션이다. MySQL 5.0.16 이후에는 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)이 생길 수 있기 때문이다.여러분은 --max-relay-log-size(또는 --max-relay-log-size가 0 일 경우에는,--max-binlog-size) 값의 두 배 보다는 작게 --relay-log-space-limit 값을 설정하지 말아야 한다. 그렇지 않으면, --relay-log-space-limit가 초과되기 때문에 I/O 쓰레드는 사용 가능 공간을 기다리게 되지만, SQL 쓰레드는 깨끗이 비워야 할 릴레이 로그를 가지지 않게 되고, 따라서 I/O 쓰레드를 만족시키지 못하게 된다. 이것은 I/O쓰레드가 임시적으로 --relay-log-space-limit를 무시하게끔 만들어 버린다.
· --replicate-do-db=db_name
디폴트 데이터 베이스 (즉, USE가 선택하는 것)가 db_name인 곳에서는 명령문 리플리케이션을 제한하도록 서버에게 지시한다. 한 개 이상의 데이터 베이스를 지정하기 위해서는, 각각의 데이터 베이스 별로 한 번씩 이 옵션을 사용한다. 이 옵션을 사용하면, 서로 다른 데이터 베이스를 선택했거나 또는 아무런 데이터 베이스도 선택하지 않는 동안에는 UPDATE some_db.some_table SETfoo='bar'와 같이 크로스–데이터베이스 (cross-database) 명령문을 복제하지 않는다는 점을 알아두자.
여러분이 예상하는 것과는 다르게 동작하는 예를 보자: 만일 슬레이브가 --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 포트 번호. 슬레이브가 디폴트 포트가 아닌 것을 주목 (listen)하거나 또는 여러분이 마스터 서버 또는 다른 클라이언트에서 슬레이브로 접속을 하기 위한 특별 터널 (tunnel)을 가지고 있는 경우에만 이 값을 설정한다. 확신이 없다면, 이 값을 설정하지 않도록 한다.
· --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옵션으로 제어할 수 있다.
· --slave-skip-errors=[err_code1,err_code2,...|all]
일반적으로, 슬레이브에서 에러가 발생되면 리플리케이션은 중단이 된다. 이를 통해 여러분은 데이터의 일관성을 수동으로 해결할 수 있게 된다. 이 옵션은 옵션 값에 열거되어 있는 에러 중의 하나를 명령문이 리턴 하더라도 리플리케이션을 계속 진행하도록 슬레이브 SQL 쓰레드에게 지시한다.
여러분이 에러 발생 원인에 대해 충분히 이해하고 있지 않으면 이 옵션을 사용하지 말도록 한다. 만일 리플리케이션 설정과 클라이언트 프로그램에 오류가 없고 (no bug), MySQL 자체에도 오류가 없다면, 리플리케이션을 중단 시키는 에러는 결코 발생하지 않는다.
에러 코드에 대해서는, 슬레이브 에러 로그와 SHOW SLAVE STATUS결과에 나와 있는 에러 메시지 번호를 사용한다.
