--abort-slave-event-count

이 옵션이 0 (기본값)이 아닌 양의 정수 値 으로 설정되면 다음과 같이 복제 작동에 영향을줍니다. 슬레이브 SQL 쓰레드가 실행 한 후 値 로그 이벤트의 실행이 허용되며 슬레이브 SQL 쓰레드는 마스터에서 네트워크 연결이 끊어진 것처럼 그 이상의 이벤트를받지 않습니다. 슬레이브 쓰레드는 계속해서 SHOW SLAVE STATUS 의 출력은 Slave_IO_Running 및 Slave_SQL_Running 열 모두에 Yes 가 표시되지만, 그 이후의 이벤트는 릴레이 로그에서 읽을 수 없습니다.

이 옵션은 복제 테스트 및 디버깅을 위해 MySQL 테스트 스위트에서 내부적으로 사용됩니다. 프로덕션 환경 설정에서 사용하는 것을 상정하고 있지 않습니다.

--disconnect-slave-event-count

이 옵션은 복제 테스트 및 디버깅을 위해 MySQL 테스트 스위트에서 내부적으로 사용됩니다.

--log-slave-updates

일반적으로 슬레이브는 마스터 서버로부터받은 업데이트를 자신의 바이너리 로그에 기록하지 않습니다. 이 옵션은 슬레이브가 SQL 쓰레드에 의해 실행되는 업데이트를 자신의 바이너리 로그에 기록합니다. 이 옵션을 사용하려면 --log-bin 옵션을 사용하여 슬레이브를 시작하고 바이너리 로깅을 활성화해야합니다. MySQL 5.5 이전에서는 --log-slave-updates 옵션을 사용하여도 --log-bin 옵션으로 서버를 시작하지 않고 서버가 시작되지 않고 오류와 함께 실패합니다. MySQL 5.6에서는 경고가 생성 될뿐입니다. (Bug # 44663) --log-slave-updates 는 복제 서버를 체인 할 때 사용됩니다. 예를 들어, 이러한 복제 서버를 설정합니다.

 A -> B -> C

여기에서 A 는 슬레이브 B 의 마스터로서 기능하고 B 는 슬레이브 C 의 마스터로서 기능합니다. 이 기능하려면 B 는 마스터하고 슬레이브이어야합니다. 바이너리 로깅을 활성화하기 위해 A 와 B 모두를 --log-bin 으로 시작하고 A 에서받은 업데이트를 B 에 의해 그 바이너리 로그에 기록되도록 B 를 --log-slave-updates 옵션 로 시작해야합니다.

--log-slow-slave-statements

슬로우 쿼리 로그가 활성화되어 있으면이 옵션은 슬레이브에서 실행에 long_query_time 초 이상의 시간이 걸린 쿼리 로깅을 사용합니다.

이 명령 행 옵션은 MySQL 5.6.11에서 삭제되고 log_slow_slave_statements 시스템 변수로 대체했습니다. 시스템 변수는 옵션과 같은 방법으로 명령 행 또는 옵션 파일에 설정할 수 있기 때문에 서버를 시작할 때 어떤 변경을 할 필요는 없지만, 시스템 변수는 런타임에 값을 검사하거나 설정할 수 있습니다.

--log-warnings [= level ]

서버는 그것이 실행하고 있는지에 대한 메시지를 더 많은 오류 로그에 기록합니다. 복제를위한 서버는 그것이 네트워크 또는 연결 실패 후 다시 연결에 성공했음을 경고를 생성하고 각 슬레이브 thread가 어떻게 시작했는지에 대한 정보를 제공합니다. 이 옵션은 기본적으로 (1)이 유효합니다. 해제하려면 --log-warnings=0 을 사용합니다. 값이 1보다 큰 경우 중단 된 연결이 오류 로그에 기록되고 새로운 연결 시도에 대한 액세스 거부 오류가 기록됩니다. 섹션 B.5.2.11 "통신 오류 및 중단 된 연결" 을 참조하십시오.

--master-info-file = file_name

마스터의 정보를 슬레이브가 기록 파일에 사용할 이름입니다. 데이터 디렉토리의 기본 이름은 master.info 입니다. 이 파일의 형식은 섹션 17.2.2.2 "노예 상태 로그" 를 참조하십시오.

--master-retry-count = count

슬레이브 마스터에 연결을 시도 횟수 (이것을 넘으면 중단). 다시 연결 CHANGE MASTER TO 문 MASTER_CONNECT_RETRY 옵션으로 설정된 간격으로 (기본값은 60)에서 시행됩니다. 다시 연결은 --slave-net-timeout 옵션에 따라 슬레이브에 의한 데이터 읽기 시간이 초과 할 때 트리거됩니다. 기본값은 86400입니다. 값 0은 "영구적"을 의미하고, 슬레이브는 영원히 연결을 시도합니다.

이 옵션은 MySQL 5.6.1 이후에 사용되지 않으며 향후 MySQL 릴리스에서 제거 될 예정입니다. 대신 CHANGE MASTER TO 문 MASTER_RETRY_COUNT 옵션을 사용하도록 응용 프로그램을 업데이트하십시오.

--max-relay-log-size = size

이 크기 서버는 릴레이 로그 파일을 자동으로 회전합니다. 값이 0이 아닌 경우, 크기가이 값을 초과하면 릴레이 로그는 자동으로 회전됩니다. 이 값이 0 (기본값)의 경우, 릴레이 로그 회전이 발생하는 크기는 max_binlog_size 의 값에 의해 결정됩니다. 자세한 내용은 섹션 17.2.2.1 "슬레이브 릴레이 로그" 를 참조하십시오.

--read-only

슬레이브가 슬레이브 쓰레드 또는 SUPER 권한을 가진 사용자 이외의 수정을 허용하지 않습니다. 슬레이브 서버에서 슬레이브가 클라이언트에서 수락하지 않고 확실하게 그 마스터 서버에서만 업데이트를 받아들이도록하려면이 도움이 될 수 있습니다. 이 변수는 TEMPORARY 테이블에는 적용되지 않습니다.

--relay-log = file_name

릴레이 로그의 기본 이름. 기본베이스 이름은 host_name -relay-bin 입니다. 다른 디렉토리를 지정하기 위해 선두에 절대 경로 이름을 붙인 기본 이름이 지정되지 않는 한 서버는 데이터 디렉토리에 파일을 씁니다. 서버는 기본 이름에 숫자 접미사를 추가하여 차례로 릴레이 로그 파일을 만듭니다.

MySQL 서버 옵션을 해석하는 방식 때문에이 옵션을 지정하려면 값을 지정해야합니다. 기본베이스 이름은 옵션이 실제로 지정된 경우에만 사용됩니다. 값을 지정하지 --relay-log 옵션을 사용하면 예기치 않은 동작이되는 경우가 있습니다. 이 동작은 사용되는 다른 옵션 그들이 지정된 순서와 그들이 명령 행에서 또는 옵션 파일으로 명기되었는지에 따라 달라집니다. MySQL 서버 옵션을 어떻게 처리할지에 대한 자세한 내용은 섹션 4.2.3 "프로그램 옵션 지정" 을 참조하십시오.

이 옵션을 지정하면 지정된 값은 릴레이 로그 인덱스 파일의 기본 이름으로도 사용됩니다. --relay-log-index 옵션을 사용하여 다른 릴레이 로그 인덱스 파일을 지정하여이 동작을 재정의 할 수 있습니다.

MySQL 5.6.5 이후에는 서버가 인덱스 파일에서 항목을 읽을 때 항목에 상대 경로가 포함되어 있는지 여부를 확인합니다. 이 경우 경로의 상대 부는 --relay-log 옵션을 사용하여 설정된 절대 경로로 대체됩니다. 절대 경로는 바뀌지 않습니다. 이러한 경우 사용되는 새로운 경로를 활성화하기 위해 인덱스를 수동으로 편집해야합니다. MySQL 5.6.5 이전에는 바이너리 로그 또는 릴레이 로그 파일의 위치를​​ 변경하려면 수동 개입이 필요했습니다. (Bug # 11745230, Bug # 12133)

다음 작업을 수행 할 때 --relay-log 옵션이 유용 할 수 있습니다.

MySQL 5.6.2 이후에서는 릴레이 로그 파일 이름 (경로)를 relay_log_basename 시스템 변수에서 얻을 수 있습니다.

--relay-log-index = file_name

릴레이 로그 인덱스 파일에 사용되는 이름입니다. 데이터 디렉토리의 기본 이름은 host_name -relay-bin.index 입니다. 여기서 host_name 은 슬레이브 서버의 이름입니다.

MySQL 서버 옵션을 해석하는 방식 때문에이 옵션을 지정하려면 값을 지정해야합니다. 기본베이스 이름은 옵션이 실제로 지정된 경우에만 사용됩니다. 값을 지정하지 --relay-log-index 옵션을 사용하면 예기치 않은 동작이되는 경우가 있습니다. 이 동작은 사용되는 다른 옵션 그들이 지정되는 순서 및 옵션을 명령 행 또는 옵션 파일으로 명기 된에 따라 달라집니다. MySQL 서버 옵션을 어떻게 처리할지에 대한 자세한 내용은 섹션 4.2.3 "프로그램 옵션 지정" 을 참조하십시오.

이 옵션을 지정하면 지정된 값은 릴레이 로그의 기본 이름으로도 사용됩니다. --relay-log 옵션을 사용하여 다른 릴레이 로그 파일 기본 이름을 지정하여이 동작을 재정의 할 수 있습니다.

--relay-log-info-file = file_name

슬레이브가 릴​​레이 로그 정보를 기록하는 파일에 사용할 이름입니다. 데이터 디렉토리의 기본 이름은 relay-log.info 입니다. 이 파일의 형식은 섹션 17.2.2.2 "노예 상태 로그" 를 참조하십시오.

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

릴레이 로그 파일이 불필요하게되자 자동으로 제거하는 것을 활성화 또는 비활성화합니다. 기본값은 1 (활성화)입니다. 이것은 SET GLOBAL relay_log_purge = N 에서 동적으로 변경할 수있는 글로벌 변수입니다. --relay-log-recovery 옵션을 사용할 때 릴레이 로그 제거를 해제하면 데이터 일관성이 위험에 노출되기 때문에 충돌로부터 안전하지 않습니다.

--relay-log-recovery = {0 | 1}

서버 시작 직후의 릴레이 로그 자동 복구를 사용합니다. 복구 과정에서 새로운 릴레이 로그 파일을 만들고 SQL 스레드 위치를이 새로운 릴레이 로그에 초기화하고 I / O 스레드를 SQL 쓰레드 위치에 초기화합니다. 그 후, 마스터에서 릴레이 로그 읽기가 계속됩니다. 이것은 손상된 수있는 릴레이 로그가 처리되지 않는 것을 보장하기 위해 리플리케이션 슬레이브에서 충돌 후 사용하십시오. 기본값은 0 (해제)입니다.

충돌 안전 슬레이브을 제공하려면이 옵션을 활성화 (1로 설정), --relay-log-info-repository 를 TABLE 로 설정하고 relay-log-purge 를 활성화해야합니다. relay-log-purge 가 잘못된 경우 --relay-log-recovery 옵션을 사용하여 삭제되지 않은 파일에서 릴레이 로그를 읽고 데이터 충돌이 발생하고 충돌 안전이 아니게 될 위험이 억제됩니다 . 자세한 내용은 충돌 안전 복제 를 참조하십시오.

MySQL 5.6.6 이전에이 옵션이 멀티 스레드 슬레이브로 사용하는 경우, 슬레이브는 오류와 함께 실패하고 슬레이브로 CHANGE MASTER TO 를 실행 할 수 없습니다. MySQL 5.6.6 이후에서는 START SLAVE UNTIL SQL_AFTER_MTS_GAPS 를 사용하여 릴레이 로그의 격차를 처리 할 수 있습니다. 이 문을 실행 한 뒤, CHANGE MASTER TO 를 사용하여 슬레이브를 새로운 마스터로 장애 조치 할 수 있습니다. (Bug # 13893363)

--relay-log-space-limit = size

이 옵션은 슬레이브의 모든 릴레이 로그의 총 크기 (바이트)의 상한을 설정합니다. 값 0은 "제한 없음"을 나타냅니다. 이것은 디스크 공간이 제한되어있는 슬레이브 서버 호스트에 도움이됩니다. 제한에 도달하면 SQL 쓰레드가 오래도록 사용하지 않는 릴레이 로그의 일부를 제거 할 때까지 I / O 쓰레드는 마스터 서버에서 바이너리 로그 이벤트 읽기를 중지합니다. 이 제한은 절대 없습니다. SQL thread가 릴레이 로그를 삭제하기 전에 더 많은 이벤트를 필요로하는 경우가 있습니다. 이 경우 SQL 쓰레드가 일부 릴레이 로그를 삭제할 수있을 때까지 I / O 스레드는 제한을 초과합니다. 그렇지 않으면 교착 상태에 있기 때문입니다. --relay-log-space-limit 를 --max-relay-log-size (또는 --max-relay-log-size 가 0의 경우는 --max-binlog-size ) 값의 2 배 미만 설정하지 마십시오. 이 경우 I / O 스레드가 공간을 대기 할 가능성이 있습니다. --relay-log-space-limit 을 초과하더라도, SQL 스레드는 제거 할 릴레이 로그를 가지지 않고, I / O 스레드를 충족시킬 수 없기 때문입니다. 이 경우 I / O 스레드는 강제로 --relay-log-space-limit 를 일시적으로 무시합니다.

--replicate-do-db = db_name

이 옵션의 영향은 명령문 기반 또는 행 기반의 두 복제를 사용 중인지에 따라 다릅니다.

문 기반 복제 기본 데이터베이스 (즉, USE 에서 선택된 것)가 db_name 인 문에 복제를 제한하도록 슬레이브 SQL thread에 지시합니다. 여러 데이터베이스를 지정하려면이 옵션을 여러 번 (데이터베이스마다 1 회) 사용합니다. 그러나 이렇게하면 다른 데이터베이스는 선택되는 (또는 데이터베이스가 선택되지 않음) 그러나, UPDATE some_db.some_table SET foo='bar' 등의 크로스 데이터베이스 문을 복제하지 않습니다.

문 기반 복제를 사용할 때 기대하는대로 작동하지 않는 예 : 슬레이브가 --replicate-do-db=sales 로 시작되고 마스터에서 다음 문을 발행하는 경우 UPDATE 문은 복제되지 않습니다.

 USE prices;
 UPDATE sales.january SET amount = amount + 1000;

이 "기본 데이터베이스 만 확인"조치의 주된 이유는 문만에서 복제해야하는지 여부를 알기가 어렵다 때문입니다 (예를 들어, 여러 데이터베이스에 걸쳐 작동하는 여러 테이블 DELETE 문 또는 UPDATE 문을 사용 경우). 또한 필요가없는 경우 모든 데이터베이스가 아니라 기본 데이터베이스 만 확인하는 것이 빠릅니다.

행 기반 복제 데이터베이스 db_name 에 복제를 제한하도록 슬레이브 SQL thread에 지시합니다. db_name 에 속하는 테이블 만 변경됩니다. 현재 데이터베이스는 이에 영향을주지 않습니다. 슬레이브가 --replicate-do-db=sales 로 시작되어 열 기반 리플리케이션이 활성화 된 경우 다음 문이 마스터에서 실행됩니다.

 USE prices;
 UPDATE sales.february SET amount = amount + 100;

슬레이브에서 sales 데이터베이스의 february 테이블을 UPDATE 문에 따라 변경됩니다. 이것은 USE 문이 실행되었는지 여부에 관계없이 발생합니다. 그러나 열 기반 리플리케이션과 --replicate-do-db=sales 를 사용할 때 다음 문을 마스터로 발행하고 슬레이브에 영향을주지 않습니다.

 USE prices;
 UPDATE prices.march SET amount = amount-25;

문 USE prices 가 USE sales 에 변경된 경우에도 UPDATE 문의 결과는 복제되지 않습니다.

--replicate-do-db 가 열 기반 리플리케이션과 명령문 기반 리플리케이션에서 어떻게 처리에 관한 또 다른 중요한 차이점은 여러 데이터베이스를 참조하는 명령문에서 발생합니다. 슬레이브가 --replicate-do-db=db1 에 시작되어 다음 문이 마스터에서 실행되는 것으로합니다.

 USE db1;
 UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;

문 기반 복제를 사용하는 경우 두 테이블이 슬레이브로 업데이트됩니다. 그러나 열 기반 리플리케이션을 사용하는 경우에는 table1 만 슬레이브에서 영향을받습니다. table2 는 다른 데이터베이스에 있기 때문에 슬레이브에서 table2 는 UPDATE 에 의해 변경되지 않습니다. 여기에서 USE db1 문 대신 USE db4 문이 사용 된 것으로합니다.

 USE db4;
 UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;

이 경우 문 기반 복제를 사용하는 경우에는 UPDATE 문의 영향은 슬레이브가 없습니다. 그러나 열 기반 리플리케이션을 사용하는 경우, UPDATE 는 슬레이브에서 table1 을 변경하지만 table2 는 변경하지 않습니다. 즉, --replicate-do-db 의해 지정된 데이터베이스의 테이블 만 변경되어 기본 데이터베이스를 선택하여이 동작에 영향을주지 않습니다.

크로스 데이터베이스 업데이트를 작동해야하는 경우, 대신에 --replicate-wild-do-table= db_name .% 를 사용하십시오. 섹션 17.2.3 "서버가 복제 필터링 규칙을 어떻게 평가 하는가?" 를 참조하십시오.

--replicate-ignore-db = db_name

--replicate-do-db 와 마찬가지로이 옵션의 영향 명령문 기반 또는 행 기반의 두 복제가 사용되는지에 따라 다릅니다.

문 기반 복제 기본 데이터베이스 (즉, USE 에서 선택된 것)가 db_name 인 문을 복제하지 않도록 슬레이브 SQL thread에 지시합니다.

행 기반 복제 데이터베이스 db_name 의 테이블을 업데이트하지 않도록 슬레이브 SQL thread에 지시합니다. 기본 데이터베이스에는 영향을주지 않습니다.

문 기반 복제를 사용하는 경우, 다음 예제는 예상대로 작동하지 않습니다. 슬레이브가 --replicate-ignore-db=sales 로 시작되는 다음 문을 마스터에서 발행하는 것으로합니다.

 USE prices;
 UPDATE sales.january SET amount = amount + 1000;

이런 경우 UPDATE 문은 복제됩니다. --replicate-ignore-db 이 ( USE 문에서 지정된) 기본 데이터베이스에만 적용되기 때문입니다. sales 데이터베이스가 문에서 명시 적으로 지정된 때문에 문은 필터링되지 않았습니다. 그러나 열 기반 리플리케이션을 사용하는 경우에는 UPDATE 문의 영향은 슬레이브에 전달되지 않고, sales.january 테이블의 노예 복사는 변경되지 않습니다. 이 예에서는 sales 데이터베이스의 마스터 복사본의 테이블에 추가 한 모든 변경은 --replicate-ignore-db=sales 에 의해 노예로 무시됩니다.

무시하는 데이터베이스를 여러 개 지정하려면이 옵션을 여러 번 (데이터베이스마다 1 회) 사용합니다. 데이터베이스 이름에 쉼표를 포함 할 수 있기 때문에 쉼표로 구분 된 목록을 지정하면 목록은 단일 데이터베이스의 이름으로 처리됩니다.

크로스 데이터베이스 업데이트를 사용하여 이러한 업데이트를 복제하지 않으려면이 옵션을 사용하지 마십시오. 섹션 17.2.3 "서버가 복제 필터링 규칙을 어떻게 평가 하는가?" 를 참조하십시오.

크로스 데이터베이스 업데이트를 작동해야하는 경우, 대신에 --replicate-wild-ignore-table= db_name .% 를 사용하십시오. 섹션 17.2.3 "서버가 복제 필터링 규칙을 어떻게 평가 하는가?" 를 참조하십시오.

--replicate-do-table = db_name.tbl_name

복제를 특정 테이블에 제한하도록 슬레이브 SQL 쓰레드에게 지시하여 복제 필터를 만듭니다. 여러 테이블을 지정하려면이 옵션을 여러 번 (테이블 당 1 회) 사용합니다. --replicate-do-db 과는 대조적으로, 이것은 크로스 데이터베이스 업데이트와 기본 데이터베이스 업데이트에 모두 작동합니다. 섹션 17.2.3 "서버가 복제 필터링 규칙을 어떻게 평가 하는가?" 를 참조하십시오.

이 옵션은 테이블에 적용되는 문에만 영향을줍니다. 스토어드 루틴 같은 다른 데이터베이스 개체에만 적용되는 문에는 영향을주지 않습니다. 스토어드 루틴에 작용하는 문을 필터링하려면 하나 이상의 --replicate-*-db 옵션을 사용합니다.

--replicate-ignore-table = db_name.tbl_name

지정된 테이블을 업데이트하는 명령문을 복제하지 않도록 (다른 테이블이 동일한 명령문에 의해 갱신 될 수 있었다고해도) 슬레이브 SQL thread에 지시하여 복제 필터를 만듭니다. 무시하는 테이블을 복수 지정하려면이 옵션을 여러 번 (테이블 당 1 회) 사용합니다. --replicate-ignore-db 과는 대조적으로, 이것은 크로스 데이터베이스 업데이트 기능합니다. 섹션 17.2.3 "서버가 복제 필터링 규칙을 어떻게 평가 하는가?" 를 참조하십시오.

이 옵션은 테이블에 적용되는 문에만 영향을줍니다. 스토어드 루틴 같은 다른 데이터베이스 개체에만 적용되는 문에는 영향을주지 않습니다. 스토어드 루틴에 작용하는 문을 필터링하려면 하나 이상의 --replicate-*-db 옵션을 사용합니다.

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

기본 데이터베이스 (즉, USE 에서 선택된 것)을 to_name 로 변환하는 복제 필터를 작성하도록 (그것이 마스터의 from_name 인 경우) 슬레이브에 지시합니다. ( CREATE DATABASE , DROP DATABASE , ALTER DATABASE 등의 문이 아니라) 테이블에 관련된 문의 만 영향을받습니다 ( from_name 이 마스터의 기본 데이터베이스의 경우에만). 여러 개서를 지정하려면 여러 번이 옵션을 사용합니다. 서버는 일치하는 from_name 값에서 첫 번째를 사용합니다. 데이터베이스 이름 변환은 --replicate-* 룰이 테스트되기 전에 이루어집니다.

이 옵션을 사용하면 테이블 이름이 데이터베이스 이름으로 규정되는 문은 --replicate-do-table 등의 테이블 수준 복제 필터링 옵션에서 작동하지 않습니다. 이름이 a 의 데이터베이스가 마스터에 있고 이름이 b 의 것이 슬레이브에있어, 각각 테이블 t 가 포함되어 --replicate-rewrite-db='a->b' 에서 마스터를 실행 한 것 합니다. 나중에 DELETE FROM at 을 실행합니다. 이 경우 관련된 필터링 규칙은 다음과 같습니다 이유로 작동하지 않습니다.

마찬가지로 --replication-rewrite-db 옵션은 크로스 데이터베이스 업데이트에서는 작동하지 않습니다.

이 옵션을 명령 행에서 사용할 때 " > " 이 명령 인터프리터에 고유 한 경우는 옵션 값을 따옴표로 묶습니다. 예 :

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

--replicate-same-server-id

슬레이브 서버에서 사용되어야합니다. 순환 복제의 원인이되는 무한 루프를 피하기 위해 일반적으로 기본 설정 0을 사용하십시오. 1로 설정하면, 슬레이브는 자신의 서버 ID를 가지는 이벤트를 스킵하지 않습니다. 일반적으로 이것은 드문 구성에서만 유용합니다. --log-slave-updates 가 사용되는 경우 1로 설정할 수 없습니다. 기본적으로 바이너리 로그 이벤트 서버 ID가 슬레이브 인 경우, 슬레이브 I / O 쓰레드는 릴레이 로그에 그들을 쓰지 않습니다 (이 최적화는 디스크 사용량을 절약 할 수 있습니다). --replicate-same-server-id 를 사용하는 경우이 옵션 슬레이브가 시작될 후 슬레이브 SQL 쓰레드가 실행하고자하는 슬레이브 자체 이벤트를 슬레이브로 읽습니다.

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

갱신되는 테이블이 지정된 데이터베이스 및 테이블 이름 패턴과 일치하는 문에 복제를 제한하도록 슬레이브 쓰레드에게 지시하여 복제 필터를 만듭니다. 패턴에는 ' % ' 및 ' _ ' 와일드 카드 문자를 포함 할 수 있습니다. 이들은 LIKE 패턴 매칭 연산자와 같은 의미를가집니다. 여러 테이블을 지정하려면이 옵션을 여러 번 (테이블 당 1 회) 사용합니다. 이것은 크로스 데이터베이스 업데이트에 도움이됩니다. 섹션 17.2.3 "서버가 복제 필터링 규칙을 어떻게 평가 하는가?" 를 참조하십시오.

이 옵션은 테이블, 뷰 및 트리거에 적용됩니다. 저장 프로 시저 및 함수 또는 이벤트에 적용되지 않습니다. 후자의 객체로 작용하는 문을 필터링하려면 하나 이상의 --replicate-*-db 옵션을 사용합니다.

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

테이블 이름 패턴이 % 의 경우 그것은 모든 테이블 이름과 일치이 옵션은 데이터베이스 수준 문 ( CREATE DATABASE , DROP DATABASE , 그리고 ALTER DATABASE )에도 적용됩니다. 예를 들어, --replicate-wild-do-table = foo %. % 를 사용하는 경우 데이터베이스 이름이 패턴 foo % 와 일치하는 경우 데이터베이스 수준 문이 복제됩니다.

리터럴 와일드 카드 문자를 데이터베이스 또는 테이블 이름 패턴에 포함하려면 백 슬래시로 그들을 탈출. 예를 들어, 이름이 my_own % db 데이터베이스의 모든 테이블을 복제하더라도, my1ownAABCdb 데이터베이스에서 테이블은 복제하지 않는 경우에는 " _ " 및 " % " 문자를 --replicate-wild-do-table = my \ _own \ % db 처럼 탈출하십시오. 이 옵션을 명령 행에서 사용하는 경우 명령 인터프리터에서는 백 슬래시를 이중으로하거나 옵션 값을 따옴표로 묶거나해야합니다. 예를 들어, bash 쉘에서는 --replicate-wild-do-table = my \\ _ own \\ % db 를 입력해야합니다.

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

어떤 테이블이 지정된 와일드 카드 패턴과 일치하는 문을 슬레이브 쓰레드가 복제를 억제하는 복제 필터를 만듭니다. 무시하는 테이블을 복수 지정하려면이 옵션을 여러 번 (테이블 당 1 회) 사용합니다. 이것은 크로스 데이터베이스 업데이트에 도움이됩니다. 섹션 17.2.3 "서버가 복제 필터링 규칙을 어떻게 평가 하는가?" 를 참조하십시오.

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

조합의 구조에 대해서는 --replicate-wild-do-table 옵션의 설명을 참조하십시오. 옵션 값에 리터럴 와일드 카드 문자를 포함하기위한 규칙은 --replicate-wild-ignore-table 경우와 동일합니다.

--report-host = host_name

슬레이브 등록 중에 마스터에보고되는 슬레이브 호스트 이름 또는 IP 주소입니다. 이 값은 마스터 서버에서 SHOW SLAVE HOSTS 의 출력에 나타납니다. 마스터 슬레이브 자신을 등록하지 않으면 값을 설정하지 않는 채로합니다.

--report-password = password

슬레이브 등록 중에 마스터에보고되는 슬레이브 계정 암호입니다. 이 값은 --show-slave-auth-info 옵션이 지정된 경우 마스터 서버에서 SHOW SLAVE HOSTS 의 출력에 나타납니다.

이 옵션의 이름은 다른 방법으로 암시되는 경우도 있지만, --report-password 는 MySQL 권한 시스템에 연결되지 않기 때문에, MySQL 복제 사용자 계정의 암호와 반드시 동일하지 않습니다 (또는 같은 일 가능성은 높지 않습니다).

--report-port = slave_port_num

슬레이브에 연결하기위한 TCP / IP 포트 번호에서 슬레이브 등록 중에 마스터에보고됩니다. 슬레이브가 비 기본 포트에서 대기하고있는 경우 또는 마스터 또는 다른 클라이언트에서 슬레이브로 특별한 터널이있는 경우에만이를 설정합니다. 확실하지 않으면이 옵션을 사용하지 마십시오.

MySQL 5.6.5 이전에는이 ​​옵션의 기본값은 3306이었습니다. MySQL 5.6.5 이후에서는 표시되는 값은 슬레이브에서 실제로 사용되는 포트 번호입니다 (Bug # 13333431). 이 변경은 SHOW SLAVE HOSTS 의해 표시되는 기본값에도 영향을줍니다.

--report-user = user_name

슬레이브 등록 중에 마스터에보고되는 슬레이브 계정 사용자 이름입니다. 이 값은 --show-slave-auth-info 옵션이 지정된 경우 마스터 서버에서 SHOW SLAVE HOSTS 의 출력에 나타납니다.

이 옵션의 이름은 다른 방법으로 암시되는 경우도 있지만, --report-user 는 MySQL 권한 시스템에 연결되지 않기 때문에, MySQL 복제 사용자 계정의 이름과 반드시 동일하지 않습니다 (또는 같은 일 가능성은 높지 않습니다).

--show-slave-auth-info

--report-user 및 --report-password 옵션으로 기동 된 슬레이브 마스터 서버에서, SHOW SLAVE HOSTS 출력 슬레이브 사용자 이름과 암호를 표시합니다.

--slave-checkpoint-group = #

SHOW SLAVE STATUS 에 의해 표시되는 멀티 스레드 노예 상태를 업데이트하기 위해 체크 포인트 작업이 호출되기 전에 슬레이브가 처리 할 수있는 최대 트랜잭션 수를 설정합니다. 이 옵션을 설정하면 멀티 스레드가 유효하지 않은 슬레이브에 영향을주지 않습니다.

이 옵션은 --slave-checkpoint-period 옵션과 함께 두 가지 제한을 초과하면 체크 포인트가 실행되고 트랜잭션의 수와 마지막 체크 포인트 이후 경과 된 시간을 모두 추적 카운터가 리셋된다는 방식으로 작동합니다.

이 옵션의 최소 허용 값은 32입니다 (서버가 -DWITH_DEBUG 를 사용하여 구축 된 경우를 제외하고 그 경우의 최소값은 1). 효과적인 값은 항상 8의 배수입니다. 그런 배수가 아닌 값으로 설정할 수 있지만 서버는 값을 저장하기 전에 다음 작은 8의 배수로 반올림합니다. ( 예외 : 이러한 반올림은 디버그 서버에서는 실행되지 않습니다.) 서버 구축 방법에 관계없이 기본값은 512이며, 최대 허용 값은 524280입니다.

--slave-checkpoint-group 은 MySQL 5.6.3에서 추가되었습니다.

--slave-checkpoint-period = #

SHOW SLAVE STATUS 에 의해 표시되는 멀티 스레드의 노예 상태를 업데이트하기 위해 체크 포인트 작업이 호출되기 전에 경과 할 수있는 최대 시간 (밀리 초)을 설정합니다. 이 옵션을 설정하면 멀티 스레드가 유효하지 않은 슬레이브에 영향을주지 않습니다.

이 옵션은 --slave-checkpoint-group 옵션과 함께 두 가지 제한을 초과하면 체크 포인트가 실행되고 트랜잭션의 수와 마지막 체크 포인트 이후 경과 된 시간을 모두 추적 카운터가 리셋된다는 방식으로 작동합니다.

이 옵션의 최소 허용 값은 1입니다 (서버가 -DWITH_DEBUG 를 사용하여 구축 된 경우를 제외하고 그 경우의 최소값은 0). 서버 구축 방법에 관계없이 기본값은 300이며, 최대 가능 값은 4294967296 (4G 바이트)입니다.

--slave-checkpoint-period 는 MySQL 5.6.3에서 추가되었습니다.

--slave-parallel-workers

복제 이벤트 (트랜잭션)을 병렬로 실행하기위한 슬레이브 작업자 스레드 수를 설정합니다. 이 변수를 0 (기본값)로 설정하면 병렬 실행이 비활성화됩니다. 최대 값은 1024입니다.

병렬 실행이 켜져있을 때 슬레이브 SQL 쓰레드는 슬레이브 작업자 스레드의 코디네이터 역할을하고 트랜잭션은 그들에게 각 데이터베이스에 분산됩니다. 그것은 노예의 작업자 스레드는 다른 데이터베이스에 업데이트가 완료 될 때까지 기다리지 않고, 소정의 데이터베이스를 기반으로 트랜잭션을 계속 처리 할 수​​있는 것을 의미합니다. 슬레이브에서 멀티 스레드의 현재 구현은 데이터가 데이터베이스마다 분할되어 있고, 소정의 데이터베이스 업데이트가 제대로 작동하도록 마스터의 경우와 마찬가지로 상대 순서로 이루어지는 것을 전제로하고 있습니다 . 그러나 두 데이터베이스 간의 트랜잭션을 조정할 필요가 없습니다.

다른 데이터베이스의 트랜잭션은 슬레이브는 마스터와 다른 순서가 수행 될 수 있다는 사실 때문에, 마지막에 실행 된 트랜잭션을 검사 한 후에도 마스터에서 이전의 모든 트랜잭션이 슬레이브에서 실행 된 보장되지 않습니다. 이것은 다중 스레드 된 슬레이브를 사용하는 경우 로깅 및 복구에 영향을줍니다. 슬레이브에서 멀티 스레드를 사용하면 바이너리 로깅 정보를 어떻게 해석해야하는지에 대해서는 섹션 13.7.5.35 "SHOW SLAVE STATUS 구문" 을 참조하십시오. 또한 START SLAVE UNTIL 가 멀티 스레드 슬레이브에서 지원되지 않는 것을 의미합니다.

멀티 스레드가 켜져있을 때, slave_transaction_retries 는 0 인으로 처리되어 변경할 수 없습니다. (현재 트랜잭션 재 시도는 멀티 스레드 슬레이브에서는 지원되지 않습니다.)

MySQL 5.6.7 이후에서는 다른 데이터베이스의 테이블 사이에 외래 키 관계를 적용하면 멀티 스레드 슬레이브가 병렬 모드가 아닌 순차을 사용하게되고, 이것이 성능에 악영향을 미칠 수 있음도 인식 하도록하십시오. (Bug # 14092635)

이 옵션은 MySQL 5.6.3에서 추가되었습니다.

--slave-pending-jobs-size-max = #

멀티 스레드 슬레이브의 경우,이 옵션은 아직 적용되지 않은 이벤트를 개최 슬레이브 작업자 큐에 사용 가능한 최대 메모리 량 (바이트 단위)을 설정합니다. 이 옵션을 설정하면 멀티 스레드가 유효하지 않은 슬레이브에 영향을주지 않습니다.

이 옵션의 최소값은 1024에서 기본은 16M 바이트입니다. 가능한 최대 값은 18446744073709551615 (16E 바이트)입니다. 1024의 정확한 배수가 아닌 값은 저장되기 전에 다음 큰 1024의 배수로 반올림됩니다.

이 옵션은 MySQL 5.6.3에서 추가되었습니다.

--skip-slave-start

서버가 시작될 때 슬레이브 쓰레드를 시작하지 않도록 슬레이브 서버에 지시합니다. 스레드를 나중에 시작하려면 START SLAVE 문을 사용합니다.

--slave_compressed_protocol = {0 | 1}

이 옵션을 1로 설정되어있는 경우, 슬레이브와 마스터 모두 지원하는 경우에는 마스터 / 슬레이브 프로토콜에 압축을 사용합니다. 기본값은 0 (압축 없음)입니다.

--slave-load-tmpdir = file_name

슬레이브가 임시 파일을 만드는 디렉토리의 이름. 이 옵션은 기본적으로 tmpdir 시스템 변수 값과 동일합니다. 슬레이브 SQL 쓰레드가 LOAD DATA INFILE 명령문을 복제 할 때 릴레이 로그에서로드되는 파일을 임시 파일로 추출하고 그들을 테이블에로드합니다. 마스터에로드 된 파일이 매우 큰 경우, 슬레이브의 임시 파일도 매우 커집니다. 따라서이 옵션을 사용하여 가능한 많은 공간을 가진 파일 시스템에있는 디렉토리에 임시 파일을 두도록 슬레이브에 지시하는 것이 좋습니다. 이 경우, 릴레이 로그도 매우 크기 때문에, --relay-log 옵션을 사용하여 파일 시스템에 릴레이 로그도 두는 것을 권장합니다.

이 옵션으로 지정한 디렉토리가 (메모리 기반 파일 시스템이 아닌) 디스크 기반 파일 시스템에 배치하십시오. LOAD DATA INFILE 의 복제에 사용되는 임시 파일이 시스템 재부팅 후에도 존속 할 필요가 있기 때문입니다. 이 디렉토리는 시스템 부팅 과정에서 OS가 제거되는 것은 안됩니다.

slave-max-allowed-packet = bytes

MySQL 5.6.6 이후에서는이 옵션이 슬레이브 SQL 쓰레드 및 I / O 스레드의 최대 패킷 크기 (바이트 단위)를 설정하기 때문에 열 기반 리플리케이션을 사용하는 큰 업데이트가 max_allowed_packet 를 초과하기 때문에 복제 가 실패하는 것은 아닙니다. (Bug # 12400221, Bug # 60926)

해당 서버 변수 slave_max_allowed_packet 는 항상 1024 양의 정수의 배수 인 값을가집니다. 이러한 배수가 아닌 값으로 설정하여도 값은 다음 큰 1024의 배수로 자동으로 반올림됩니다. (예를 들어, --slave-max-allowed-packet = 10000 에서 서버를 시작하면 사용되는 값은 9216입니다. 값을 0으로 설정하면 1024이 사용됩니다.) 이런 경우 자르기 경고가 발행됩니다.

최대 (디폴트) 값은 1073741824 (1G 바이트)에서 최소 1024입니다.

--slave-net-timeout = seconds

마스터에서 후속 데이터를 기다리는 대기 시간 (이후는 슬레이브 연결이 끊긴 것으로 간주하며 읽기를 중지하고 다시 연결을 시도). 첫 번째 시도는 시간 직후에 발생합니다. 재시도 간격은 CHANGE MASTER TO 문 MASTER_CONNECT_RETRY 옵션에서 제어되고 다시 연결 시도는 --master-retry-count 옵션에 의해 제한됩니다. 기본값은 3600 초 (1 시간)입니다.

slave-rows-search-algorithms = list

slave_allow_batching 를 사용하여 행 기반 로깅 및 복제를 위해 대량의 행을 준비 할 때이 옵션은 행의 일치가 어떻게 검색되는지, 즉, 기본 키, 고유 키 또는 어떤 다른 키 를 사용하는 검색 또는 키를 전혀 사용하지 않는 검색 해시를 사용할지 여부를 제어합니다. 이 옵션은 목록 INDEX_SCAN , TABLE_SCAN , HASH_SCAN 에서 2 개의 값 (or possibly 3)의 쉼표로 구분 된 목록을 가지고 있습니다. 목록을 따옴표로 묶을 필요는 없지만 따옴표를 사용할지 여부에 관계없이 목록에 공백을 포함해서는 안됩니다. 가능한 조합 (목록)과 그 결과를 다음 표에 나타냅니다.

목록에서 알고리즘이 지정되는 순서는 SELECT 또는 SHOW VARIABLES 문에 나타나는 순서와 차이가 없습니다 (직전에 포함 된 테이블에서 사용되는 것과 같은). 기본값은 TABLE_SCAN, INDEX_SCAN 에서이 인덱스를 사용할 수있는 모든 검색은 그들을 사용하여 인덱스없이 검색은 테이블 스캔을 사용하는 것을 의미합니다.

INDEX_SCAN, TABLE_SCAN, HASH_SCAN 을 지정하는 것은 INDEX_SCAN, HASH_SCAN 을 지정하는 경우와 같은 결과가됩니다. 기본 키 또는 고유 키를 사용하지 않는 검색 해시를 사용하려면이 옵션을 INDEX_SCAN, HASH_SCAN 로 설정합니다. 모든 검색에 해시를 강제로 사용하려면 TABLE_SCAN, HASH_SCAN 로 설정합니다.

이 옵션은 MySQL 5.6.6에서 추가되었습니다.

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

복제는 일반적으로 슬레이브에서 오류가 발생했을 때 중지합니다. 이것은 데이터의 불일치를 수동으로 해결할 수있는 기회입니다. 이 옵션은 문이 옵션 값에 나열된 오류를 반환 할 때 복제를 계속하도록 슬레이브 SQL thread에 지시합니다.

이 옵션은 오류가 발생하는 이유를 완전히 이해하지 않는 한 사용하지 마십시오. 복제 설정 및 클라이언트 프로그램에 버그가없고, MySQL 자체에 버그가없는 경우 복제를 중지 오류가 발생하지 않을 것입니다. 이 옵션을 무작정 사용하면 슬레이브와 마스터 동기화가 절망으로 빠져들고 이것이 왜 발생했는지 짐작이 붙지 않습니다.

오류 코드는 슬레이브 오류 로그 및 SHOW SLAVE STATUS 의 출력 오류 메시지에서 제공하는 값을 사용하십시오. 부록 B 오류 오류 코드 및 일반적인 문제 는 서버 오류 코드가 나열되어 있습니다.

비추천 값 all 을 사용하여 슬레이브에 모든 오류 메시지를 무시하고 무슨 일이 발생해도 계속시킬 수 있습니다 (단, 사용해서는 없습니다). 물론 all 을 사용하면 데이터 무결성에 대해 보증하지 않습니다. 슬레이브의 데이터가 마스터의 것과 상당히 차이가 불만을 말하지 마십시오 (버그 리포트를 꺼내지 마십시오). 이상의 것을 경고했습니다 .

MySQL 5.6과 MySQL Cluster NDB 7.3 이상에서는 추가 간략 판 ddl_exist_errors 이 지원되며 이것은 오류 코드 목록 1007,1008,1050,1051,1054,1060,1061,1068,1094,1146 에 해당합니다.

예 :

--slave-skip-errors = 1062,1053
--slave-skip-errors = all
--slave-skip-errors = ddl_exist_errors

--slave-sql-verify-checksum = {0 | 1}

이 옵션을 활성화하면, 슬레이브는 릴레이 로그에서 읽은 체크섬을 확인하여 불일치가있는 경우 슬레이브는 오류로 중지합니다. 기본적으로 비활성화되어 있습니다.

이 옵션은 MySQL 5.6.2에서 추가되었습니다.

--master-info-repository = {FILE | TABLE}

이 옵션을 사용하면 서버는 마스터 정보 로그 파일 또는 테이블에 기록합니다. 파일 이름은 기본적으로 master.info 됩니다. 파일 이름은 --master-info-file 서버 옵션을 사용하여 변경할 수 있습니다.

이 옵션의 기본값은 FILE 입니다. TABLE 을 사용하는 경우 로그는 mysql 데이터베이스의 slave_master_info 테이블에 기록됩니다.

--master-info-repository 옵션은 MySQL 5.6.2에서 추가되었습니다.

--relay-log-info-repository = {FILE | TABLE}

이 옵션을 사용하면 서버는 릴레이 로그 정보 로그 파일 또는 테이블에 기록합니다. 파일 이름은 기본적으로 relay-log.info 됩니다. 파일 이름은 --relay-log-info-file 서버 옵션을 사용하여 변경할 수 있습니다.

이 옵션의 기본값은 FILE 입니다. TABLE 을 사용하는 경우 로그는 mysql 데이터베이스의 slave_relay_log_info 테이블에 기록됩니다.

복제 충돌 안전하기 위해이 옵션은 TABLE 로 설정해야합니다. 또한 --relay-log-recovery 옵션을 활성화해야합니다. 자세한 내용은 충돌 안전 복제 를 참조하십시오.

--relay-log-info-repository 옵션은 MySQL 5.6.2에서 추가되었습니다.

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

init_slave

이 변수는 init_connect 와 유사하지만, SQL 쓰레드가 시작될 때마다 슬레이브 서버에서 수행되는 문자열입니다. string의 형식은 init_connect 변수의 경우와 동일합니다.

log_slow_slave_statements

슬로우 쿼리 로그가 활성화되면이 변수는 슬레이브로 실행하기 위해 long_query_time 초 이상의 시간이 걸린 쿼리 로깅을 사용합니다. 이 변수는 MySQL 5.6.11에서 추가되었다.

master_info_repository

이 변수의 설정에 따라 슬레이브가 마스터 상태 및 연결 정보의 로그를 FILE ( master.info ) 또는 TABLE ( mysql.slave_master_info ) 모두에 기록 할 것인지 결정합니다.

이 변수의 설정은 sync_master_info 시스템 변수의 설정에 의한 영향에도 직접 영향을 미칩니다. 자세한 내용은 변수의 설명을 참조하십시오.

이 변수는 MySQL 5.6.2에서 추가되었습니다.

relay_log

릴레이 로그 파일의 이름입니다.

relay_log_basename

릴레이 로그 파일의 이름과 전체 경로를 유지합니다.

relay_log_basename 시스템 변수는 MySQL 5.6.2에서 추가되었습니다.

relay_log_index

릴레이 로그 인덱스 파일의 이름입니다. 데이터 디렉토리의 기본 이름은 host_name -relay-bin.index 입니다. 여기서 host_name 은 슬레이브 서버의 이름입니다.

relay_log_info_file

슬레이브가 릴레이 로그 정보를 기록하는 파일의 이름. 데이터 디렉토리의 기본 이름은 relay-log.info 입니다.

relay_log_info_repository

이 변수는 슬레이브의 릴레이 로그 내에서의 위치가 FILE ( relay-log.info ) 또는 TABLE ( mysql.slave_relay_log_info ) 모두에 기록할지 여부를 결정합니다.

이 변수의 설정은 sync_relay_log_info 시스템 변수의 설정에 의한 영향에도 직접 영향을 미칩니다. 자세한 내용은 변수의 설명을 참조하십시오.

이 변수는 MySQL 5.6.2에서 추가되었습니다.

relay_log_recovery

서버 시작 직후의 릴레이 로그 자동 복구를 사용합니다. 복구 과정에서 새로운 릴레이 로그 파일을 만들고 SQL 스레드 위치를이 새로운 릴레이 로그에 초기화하고 I / O 스레드를 SQL 쓰레드 위치에 초기화합니다. 그 후, 마스터에서 릴레이 로그 읽기가 계속됩니다. MySQL 5.6.5 이전 버전에서는이 전역 변수를 동적으로 변경되었습니다. MySQL 5.6.6 이후는 읽기 전용입니다. (Bug # 13840948) MySQL Server 버전에 관계없이 --relay-log-recovery 옵션으로 슬레이브를 기동하여 그 값을 변경할 수 있습니다. 이것은 리플리케이션 슬레이브에서 충돌이 발생한 후에 손상된 수있는 릴레이 로그가 처리되지 않는 것을 보장하기 위해 사용되어야하며, 충돌 안전 슬레이브을 보장하기 위해 사용해야합니다. 기본값은 0 (해제)입니다.

relay_log_recovery 이 효과적이며, 슬레이브가 다중 스레드 모드에서 동작 중에 발생 된 오류로 인해 중지 된 경우에도 로그에 차이가있는 경우에는 CHANGE MASTER TO 를 실행 할 수 없습니다. MySQL 5.6.6 이후에서는 START SLAVE UNTIL SQL_AFTER_MTS_GAPS 를 사용하여 확실하게 모든 격차가 처리 된 후 단일 스레드 모드로 돌아가거나 CHANGE MASTER TO 문을 수행 할 수있게합니다.

rpl_stop_slave_timeout

MySQL 5.6.13 이후 버전에서는이 변수를 설정하여 시간 제한까지 STOP SLAVE 가 대기하는 시간 (초)을 제어 할 수 있습니다. 이것은 STOP SLAVE 문 및 슬레이브에 다양한 클라이언트 연결을 사용하는 다른 슬레이브 SQL 문 사이의 교착 상태를 방지하기 위해 사용할 수 있습니다. rpl_stop_slave_timeout 의 최대 값과 디폴트 값은 31536000 초 (1 년)입니다. 최소 2 초입니다.

slave_checkpoint_group

SHOW SLAVE STATUS 에 의해 표시되는 멀티 스레드 노예 상태를 업데이트하기 위해 체크 포인트 작업이 호출되기 전에 슬레이브가 처리 할 수있는 최대 트랜잭션 수를 설정합니다. 이 변수를 설정해도 멀티 스레드가 유효하지 슬레이브에 영향을주지 않습니다.

이 변수는 slave_checkpoint_period 시스템 변수와 함께 두 가지 제한을 초과하면 체크 포인트가 실행되고 트랜잭션의 수와 마지막 체크 포인트 이후 경과 된 시간을 모두 추적하는 카운터가 재설정 될 때 라는 방식으로 작동합니다.

이 변수의 최소 허용 값은 32입니다 (서버가 -DWITH_DEBUG 를 사용하여 구축 된 경우를 제외하고이 경우의 최소값은 1). 효과적인 값은 항상 8의 배수입니다. 그런 배수가 아닌 값으로 설정할 수 있지만 서버는 값을 저장하기 전에 다음 작은 8의 배수로 반올림합니다. ( 예외 : 이러한 반올림은 디버그 서버에서는 실행되지 않습니다.) 서버 구축 방법에 관계없이 기본값은 512이며, 최대 허용 값은 524280입니다.

slave_checkpoint_group 는 MySQL 5.6.3에서 추가되었습니다.

slave_checkpoint_period

SHOW SLAVE STATUS 에 의해 표시되는 멀티 스레드의 노예 상태를 업데이트하기 위해 체크 포인트 작업이 호출되기 전에 경과 할 수있는 최대 시간 (밀리 초)을 설정합니다. 이 변수를 설정해도 멀티 스레드가 유효하지 슬레이브에 영향을주지 않습니다.

이 변수는 slave_checkpoint_group 시스템 변수와 함께 두 가지 제한을 초과하면 체크 포인트가 실행되고 트랜잭션의 수와 마지막 체크 포인트 이후 경과 된 시간을 모두 추적하는 카운터가 재설정 될 때 라는 방식으로 작동합니다.

이 변수의 최소 허용 값은 1입니다 (서버가 -DWITH_DEBUG 를 사용하여 구축 된 경우를 제외하고이 경우 최소 0). 서버 구축 방법에 관계없이 기본값은 300이며, 최대 가능 값은 4294967296 (4G 바이트)입니다.

slave_checkpoint_period 는 MySQL 5.6.3에서 추가되었습니다.

slave_compressed_protocol

슬레이브 / 마스터 프로토콜의 압축을 사용할지 여부 (슬레이브와 마스터 모두가 지원하는 경우).

slave_exec_mode

IDEMPOTENT 또는 STRICT 모드가 복제 충돌 해결 및 오류 검사에 사용되는지 여부를 제어합니다. IDEMPOTENT 모드에서는 키가 중복되는 오류와 키를 찾을 수없는 오류가 표시됩니다.

이 모드는 MySQL Cluster 복제 다중 마스터 복제 순환 복제 및 기타 특별한 복제 시나리오에 필요합니다. (자세한 내용은 섹션 18.6.10 "MySQL Cluster 복제 : 멀티 마스터와 순환 복제 ' 및 섹션 18.6.11 "MySQL Cluster 복제 충돌 해결" 을 참조하십시오.) MySQL Cluster에서 제공되는 mysqld 는 slave_exec_mode 에 명시 적으로 설정되는 값을 무시하고이를 항상 IDEMPOTENT 로 취급합니다.

MySQL Server 5.6에서는 STRICT 모드가 기본값입니다. 이것을 변경하지 마십시오. 현재 IDEMPOTENT 모드는 NDB 에서만 지원됩니다.

slave_load_tmpdir

LOAD DATA INFILE 명령문을 복제하기 위해 슬레이브가 임시 파일을 만드는 디렉토리의 이름.

slave_max_allowed_pa​​cket

MySQL 5.6.6 이후에서는이 변수는 슬레이브 SQL 쓰레드 및 I / O 스레드의 최대 패킷 크기를 설정하기 때문에 업데이트가 max_allowed_packet 를 넘어선 것으로 인해 열 기반 리플리케이션을 사용하는 큰 업데이트가 복제에 실패 하는 것은 아닙니다.

이 전역 변수는 항상 1024 양의 정수의 배수 인 값을가집니다. 그렇지 않은 특정 값으로 설정해도 값은 다음 큰 1024의 배수로 자동으로 반올림하여 저장 또는 사용됩니다. slave_max_allowed_packet 를 0으로 설정하면 1024이 사용됩니다. (이런 경우 절단 경고가 발행됩니다.) 기본 및 최대 값은 1073741824 (1G 바이트)에서 최소 1024입니다.

slave_max_allowed_packet 은 --slave-max-allowed-packet 옵션을 사용하여 시작시 구성 할 수 있습니다.

slave_net_timeout

마스터 / 슬레이브 연결에서 후속 데이터를 기다리는 대기 시간 (이후 읽기를 중지).

slave_parallel_workers

복제 이벤트 (트랜잭션)을 병렬로 실행하기위한 슬레이브 작업자 스레드 수를 설정합니다. 이 변수를 0 (기본값)로 설정하면 병렬 실행이 비활성화됩니다. 최대 값은 1024입니다.

병렬 실행이 켜져있을 때 슬레이브 SQL 쓰레드는 슬레이브 작업자 스레드의 코디네이터 역할을하고 트랜잭션은 그들에게 각 데이터베이스에 분산됩니다. 그것은 노예의 작업자 스레드는 다른 데이터베이스에 업데이트가 완료 될 때까지 기다리지 않고, 소정의 데이터베이스를 기반으로 트랜잭션을 계속 처리 할 수​​있는 것을 의미합니다. 슬레이브에서 멀티 스레드의 현재 구현은 데이터가 데이터베이스마다 분할되어 있고, 소정의 데이터베이스 업데이트가 제대로 작동하도록 마스터의 경우와 마찬가지로 상대 순서로 이루어지는 것을 전제로하고 있습니다 . 그러나 두 데이터베이스 간의 트랜잭션을 조정할 필요가 없습니다.

다른 데이터베이스의 트랜잭션은 슬레이브는 마스터와 다른 순서가 수행 될 수 있다는 사실 때문에, 마지막에 실행 된 트랜잭션을 검사 한 후에도 마스터에서 이전의 모든 트랜잭션이 슬레이브에서 실행 된 보장되지 않습니다. 이것은 다중 스레드 된 슬레이브를 사용하는 경우 로깅 및 복구에 영향을줍니다. 슬레이브에서 멀티 스레드를 사용하면 바이너리 로깅 정보를 어떻게 해석해야하는지에 대해서는 섹션 13.7.5.35 "SHOW SLAVE STATUS 구문" 을 참조하십시오. 또한 START SLAVE UNTIL 가 멀티 스레드 슬레이브에서 지원되지 않는 것을 의미합니다.

멀티 스레드가 켜져있을 때, slave_transaction_retries 는 0 인으로 처리되어 변경할 수 없습니다. (현재 트랜잭션 재 시도는 멀티 스레드 슬레이브에서는 지원되지 않습니다.)

이 변수는 MySQL 5.6.3에서 추가되었습니다.

slave_pending_jobs_size_max

멀티 스레드 슬레이브의 경우,이 변수는 아직 적용되지 않은 이벤트를 개최 슬레이브 작업자 큐에 사용 가능한 최대 메모리 량 (바이트 단위)을 설정합니다. 이 변수를 설정해도 멀티 스레드가 유효하지 슬레이브에 영향을주지 않습니다.

이 변수의 가능한 최소 1024에서 기본은 16M 바이트입니다. 가능한 최대 값은 18446744073709551615 (16E 바이트)입니다. 1024의 정확한 배수가 아닌 값은 저장되기 전에 다음 큰 1024의 배수로 반올림됩니다.

slave_pending_jobs_size_max 는 MySQL 5.6.3에서 추가되었습니다.

slave_rows_search_algorithms

slave_allow_batching 를 사용하여 행 기반 로깅 및 복제를 위해 대량의 행을 준비 할 때 slave_rows_search_algorithms 변수는 행의 일치가 어떻게 검색되는지, 즉, 기본 키, 고유 키 또는 어떤 다른 키 를 사용하는 검색 또는 키를 전혀 사용하지 않는 검색 해시를 사용할지 여부를 제어합니다. 이 옵션은 목록 INDEX_SCAN , TABLE_SCAN , HASH_SCAN 에서 적어도 두 값의 쉼표로 구분 된 목록을 가지고 있습니다. 값은 문자열을 상정하기 때문에 값은 따옴표로 묶어야합니다. 또한 값에 공백을 포함해서는 안됩니다. 가능한 조합 (목록)과 그 결과를 다음 표에 나타냅니다.

목록에서 알고리즘이 지정되는 순서는 여기에서 같이 SELECT 또는 SHOW VARIABLES 문에 나타나는 순서와 차이가 없습니다.

mysql> SET GLOBAL slave_rows_search_algorithms = "INDEX_SCAN,TABLE_SCAN";
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE '%algorithms%';
+------------------------------+-----------------------+
| Variable_name                | Value                 |
+------------------------------+-----------------------+
| slave_rows_search_algorithms | TABLE_SCAN,INDEX_SCAN |
+------------------------------+-----------------------+
1 row in set (0.00 sec)

mysql> SET GLOBAL slave_rows_search_algorithms = "TABLE_SCAN,INDEX_SCAN";
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE '%algorithms%';
+------------------------------+-----------------------+
| Variable_name                | Value                 |
+------------------------------+-----------------------+
| slave_rows_search_algorithms | TABLE_SCAN,INDEX_SCAN |
+------------------------------+-----------------------+
1 row in set (0.00 sec)

기본값은 TABLE_SCAN, INDEX_SCAN 에서이 인덱스를 사용할 수있는 모든 검색은 그들을 사용하여 인덱스없이 검색은 테이블 스캔을 사용하는 것을 의미합니다.

INDEX_SCAN, TABLE_SCAN, HASH_SCAN 을 지정하는 것은 INDEX_SCAN, HASH_SCAN 을 지정하는 경우와 같은 결과가됩니다. 기본 키 또는 고유 키를 사용하지 않는 검색 해시를 사용하려면이 변수를 INDEX_SCAN, HASH_SCAN 로 설정합니다. 모든 검색에 해시를 강제로 사용하려면 TABLE_SCAN, HASH_SCAN 로 설정합니다.

이 변수는 MySQL 5.6.6에서 추가되었습니다.

slave_skip_errors

복제는 일반적으로 슬레이브에서 오류가 발생했을 때 중지합니다. 이것은 데이터의 불일치를 수동으로 해결할 수있는 기회입니다. 이 변수는 문이 변수 값에 나열된 오류를 반환 할 때 복제를 계속하도록 슬레이브 SQL thread에 지시합니다.

slave_sql_verify_checksum

슬레이브 SQL 쓰레드는 릴레이 로그에서 읽은 체크섬을 사용하여 데이터를 확인합니다. 불일치가있을 경우, 슬레이브는 오류로 중지합니다.

slave_sql_verify_checksum 는 MySQL 5.6.2에서 추가되었습니다.

slave_transaction_retries

InnoDB 교착 상태 또는 트랜잭션의 수행 시간이 InnoDB 의 innodb_lock_wait_timeout 또는 NDB 의 TransactionDeadlockDetectionTimeout 또는 TransactionInactiveTimeout 을 초과했기 때문에 리플리케이션 슬레이브 SQL 쓰레드가 트랜잭션의 실행에 실패하면 자동으로 slave_transaction_retries 번 다시 시도하고 오류 중지합니다. 기본값은 10입니다.

멀티 스레드 슬레이브를 사용할 때 트랜잭션을 다시 시도 할 수 없습니다. 즉, slave_parallel_workers 가 0보다 크면 slave_transaction_retries 가 0으로 처리되어 변경할 수 없습니다.

slave_type_conversions

열 기반 리플리케이션을 사용하면 슬레이브에서 유효한 유형 변환 모드를 제어합니다. MySQL 5.6.13 이후에는 그 값은 목록 ALL_LOSSY , ALL_NON_LOSSY , ALL_SIGNED , ALL_UNSIGNED 에서 0 개 이상의 요소의 쉼표로 구분 된 세트입니다. 이 변수를 빈 문자열로 설정하면 마스터와 슬레이브 사이의 유형 변환이 금지됩니다. 변경 사항을 적용하려면 슬레이브를 다시 시작해야합니다.

ALL_SIGNED 및 ALL_UNSIGNED 는 MySQL 5.6.13에서 추가되었습니다 (Bug # 15831300). 열 기반 리플리케이션에서 속성 승격과 강등에 적용 할 수있는 타입 변환 모드에 대한 자세한 내용은 열 기반 리플리케이션 : 속성 승격과 강등 을 참조하십시오.

sql_slave_skip_counter

마스터에서 이벤트 중 슬레이브 서버가 스킵해야 수.

이 옵션은 GTID 기반 복제와 호환되지 않으며, --gtid-mode = ON 의 경우 0이 아닌 값으로 설정해서는 없습니다. MySQL 5.6.10 이후에서는 그렇게하는 것은 명시 적으로 금지되어 있습니다. (Bug # 15833516) GTID을 채용 할 때 트랜잭션을 스킵 할 필요가있는 경우에는 대신 마스터에서 gtid_executed 을 사용하십시오. 이렇게 방법은 빈 트랜잭션의 주입 을 참조하십시오.

sync_master_info

리플리케이션 슬레이브에서이 변수의 영향은 다음 단락에서 설명하도록 슬레이브 master_info_repository 이 FILE 또는 TABLE 모두에 설정되어 있는지에 따라 다릅니다.

master_info_repository = FILE sync_master_info 의 값이 0보다 큰 경우, 슬레이브는 모든 sync_master_info 이벤트 이후에는 그 master.info 파일을 디스크에 동기화합니다 ( fdatasync () 를 사용). 0의 경우, MySQL 서버는 master.info 파일에서 디스크로 동기화를 수행하지 않습니다. 대신 서버는 운영 체제에 의존하여 다른 파일과 마찬가지로 그 내용을 정기적으로 플래시합니다.

master_info_repository = TABLE sync_master_info 의 값이 0보다 큰 경우, 슬레이브는 모든 sync_master_info 이벤트 이후에는 그 마스터 정보 저장소 테이블을 업데이트합니다. 0의 경우, 테이블은 업데이트되지 않습니다.

sync_master_info 의 기본값은 MySQL 5.6.6 이후에서는 10000 그 이전은 0입니다.

sync_relay_log