Loading...
MySQL 9.5 Reference Manual 9.5의 19.1.6 Replication and Binary Logging Options and Variables의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
19.1.6.1 Replication and Binary Logging Option and Variable Reference 19.1.6.2 Replication Source Options and Variables 19.1.6.3 Replica Server Options and Variables 19.1.6.4 Binary Logging Options and Variables 19.1.6.5 Global Transaction ID System Variables
다음 섹션에는 복제에서 사용되고 바이너리 로그를 제어하는 데 사용되는 mysqld 옵션과 서버 변수에 대한 정보가 포함되어 있습니다. 소스와 레플리카에서 사용할 옵션과 변수는 별도로 다루며, 바이너리 로깅 및 글로벌 트랜잭션 식별자(GTID)에 관련된 옵션과 변수 또한 별도로 다룹니다. 이들 옵션과 변수에 대한 기본 정보를 제공하는 퀵 레퍼런스 테이블 집합도 포함되어 있습니다.
특히 중요한 것은 server_id 시스템 변수입니다.
| Property | Value |
|---|---|
| Command-Line Format | --server-id=# |
| System Variable | server_id |
| Scope | Global |
| Dynamic | Yes |
SET_VAR Hint Applies | No |
| Type | Integer |
| Default Value | 1 |
| Minimum Value | 0 |
| Maximum Value | 4294967295 |
이 변수는 서버 ID를 지정합니다. 기본적으로 server_id는 1로 설정됩니다. 서버는 이 기본 ID로 시작할 수 있지만, 바이너리 로깅이 활성화된 경우 서버 ID를 지정하기 위해 server_id를 명시적으로 설정하지 않았다면 정보 메시지가 출력됩니다.
복제 토폴로지에서 사용되는 서버의 경우, 각 복제 서버마다 1에서 2^32 − 1 범위 내에서 고유한 서버 ID를 지정해야 합니다. “고유”하다는 것은, 해당 토폴로지에서 사용 중인 다른 어떤 소스나 레플리카의 ID와도 서로 달라야 함을 의미합니다. 추가 정보는 Section 19.1.6.2, “Replication Source Options and Variables” 및 Section 19.1.6.3, “Replica Server Options and Variables”를 참조하십시오.
서버 ID가 0으로 설정된 경우에도 바이너리 로깅은 수행되지만, 서버 ID가 0인 소스는 레플리카의 모든 연결을 거부하며, 서버 ID가 0인 레플리카는 소스에 연결하기를 거부합니다. 서버 ID를 동적으로 0이 아닌 값으로 변경할 수는 있으나, 그렇게 한다고 해서 복제가 즉시 시작되지는 않는다는 점에 유의하십시오. 레플리카를 초기화하려면 서버 ID를 변경한 다음 서버를 재시작해야 합니다.
자세한 내용은 Section 19.1.2.2, “Setting the Replica Configuration”를 참조하십시오.
MySQL 서버는 server_id 시스템 변수에 설정된 기본 또는 사용자가 지정한 서버 ID와는 별도로 실제 UUID를 생성합니다. 이는 전역(global), 읽기 전용 변수인 server_uuid로 제공됩니다.
참고
server_uuid 시스템 변수가 존재한다고 해서, 이 섹션 앞부분에서 설명한 것처럼 MySQL 복제를 준비하고 실행하는 과정에서 각 MySQL 서버마다 고유한 server_id 값을 설정해야 하는 요구 사항이 변경되는 것은 아닙니다.
| Property | Value |
|---|---|
| System Variable | server_uuid |
| Scope | Global |
| Dynamic | No |
SET_VAR Hint Applies | No |
| Type | String |
시작 시 MySQL 서버는 다음과 같이 자동으로 UUID를 얻습니다:
data_dir/auto.cnf 파일(여기서 _data_dir_는 서버의 데이터 디렉터리)의 UUID를 읽어 사용하려고 시도합니다.
data_dir/auto.cnf가 없으면, 새 UUID를 생성하여 필요한 경우 이 파일을 생성하며 그 안에 저장합니다.
auto.cnf 파일은 my.cnf 또는 my.ini 파일에 사용되는 형식과 유사한 형식을 가집니다. auto.cnf에는 단 하나의 [auto] 섹션과 하나의 server_uuid 설정 및 값만 포함되며, 파일 내용은 다음과 유사하게 표시됩니다:
1[auto] 2server_uuid=8a94f357-aab4-11df-86ab-c80aa9429562
주의
auto.cnf 파일은 자동으로 생성되므로, 이 파일을 직접 작성하거나 수정하려고 시도하지 마십시오.
MySQL 복제를 사용할 때, 소스와 레플리카는 서로의 UUID를 알고 있습니다. 레플리카의 UUID 값은 SHOW REPLICAS의 출력에서 확인할 수 있습니다. START REPLICA가 실행된 후에는, 레플리카에서 SHOW REPLICA STATUS 출력을 통해 소스의 UUID 값을 확인할 수 있습니다.
참고
STOP REPLICA 또는 RESET REPLICA 스테이트먼트를 실행해도 레플리카에서 사용되는 소스의 UUID는 reset되지 않습니다.
서버의 server_uuid는 해당 서버에서 시작된 트랜잭션의 GTID에서도 사용됩니다. 자세한 내용은 Section 19.1.3, “Replication with Global Transaction Identifiers”를 참조하십시오.
시작 시 복제 I/O(리시버) 스레드는 소스의 UUID가 자신의 UUID와 동일한 경우, --replicate-same-server-id 옵션이 설정되어 있지 않다면 에러를 생성하고 중단합니다. 추가로, 다음 둘 중 하나에 해당하는 경우 복제 리시버 스레드는 경고를 생성합니다:
예상되는 server_uuid를 가진 소스가 존재하지 않는 경우.
CHANGE REPLICATION SOURCE TO 스테이트먼트가 한 번도 실행된 적이 없음에도 불구하고 소스의 server_uuid가 변경된 경우.
19.1.5 MySQL Multi-Source Replication
19.1.7 Common Replication Administration Tasks
