Loading...
MySQL 9.5 Reference Manual 9.5의 25.7.6 Starting NDB Cluster Replication (Single Replication Channel)의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
이 섹션에서는 단일 replication channel을 사용하여 NDB Cluster replication을 시작하는 절차를 개략적으로 설명합니다.
id 는 이 서버의 고유 ID입니다(자세한 내용은
Section 25.7.2, “General Requirements for NDB Cluster Replication”을
참조하십시오):1shellS> mysqld --ndbcluster --server-id=id \ 2 --log-bin --ndb-log-bin &
이 명령은 적절한 로깅 포맷을 사용하여 바이너리 로깅이
활성화된 상태로 서버의 [**mysqld**](https://dev.mysql.com/doc/refman/9.5/en/mysqld.html "6.3.1 mysqld — The MySQL Server")
프로세스를 시작합니다. 또한
`NDB` 테이블에 대한 업데이트 로깅을
[`--ndb-log-bin`](https://dev.mysql.com/doc/refman/9.5/en/mysql-cluster-options-variables.html#sysvar_ndb_log_bin) 옵션을 사용하여
명시적으로 활성화해야 합니다.
참고
--binlog-format=MIXED로
source를 시작할 수도 있으며, 이 경우 클러스터 간 replication을
수행할 때 row 기반 replication이 자동으로 사용됩니다.
Statement 기반 바이너리 로깅은 NDB Cluster Replication에서는
지원되지 않습니다(자세한 내용은
Section 25.7.2, “General Requirements for NDB Cluster Replication”을
참조하십시오).
1shellR> mysqld --ndbcluster --server-id=id &
위 명령에서 _`id`_ 는 replica 서버의 고유 ID입니다.
replica에서 로깅을 활성화할 필요는 없습니다.
참고
replication이 즉시 시작되기를 원하지 않는다면, 아래 Step 4에서
설명하는 대로 적절한
START REPLICA statement가 실행될
때까지 replication 스레드의 시작을 지연시키십시오. 이는 replica를
다음 옵션으로 시작함으로써 수행할 수 있습니다:
--skip-replica-start.
1mysqlR> CHANGE REPLICATION SOURCE TO 2 -> SOURCE_LOG_FILE='', 3 -> SOURCE_LOG_POS=4;
이 명령은 replica에게 source server의 바이너리 로그를 로그의 시작점부터
읽기 시작하도록 지시합니다. 그렇지 않은 경우—즉, 백업을 사용하여
source에서 데이터를 로드하고 있는 경우—이러한 상황에서 사용할
`SOURCE_LOG_FILE` 및
`SOURCE_LOG_POS`의 올바른 값을 얻는 방법에 대한 정보는
[Section 25.7.8, “Implementing Failover with NDB Cluster Replication”](https://dev.mysql.com/doc/refman/9.5/en/mysql-cluster-replication-failover.html "25.7.8 Implementing Failover with NDB Cluster Replication")을
참조하십시오.
4. 마지막으로, replica에서 mysql 클라이언트를 사용하여 다음 명령을 실행함으로써 replica가 replication을 적용하기 시작하도록 지시합니다:
1mysqlR> START REPLICA;
이 명령은 source에서 replica로의 데이터 및 변경 사항 전송도 시작합니다.
또한, 다음 섹션에 설명된 절차와 유사한 방식으로 두 개의 replication channel을 사용할 수도 있습니다. 이 방식과 단일 replication channel 사용 간의 차이점은 Section 25.7.7, “Using Two Replication Channels for NDB Cluster Replication”에서 다룹니다.
또한 batched update를 활성화하여 클러스터 replication 성능을
향상시킬 수 있습니다.
이는 replica의 mysqld 프로세스에서 시스템 변수
replica_allow_batching을
설정함으로써 수행할 수 있습니다. 일반적으로 업데이트는 수신되는 즉시
적용됩니다. 그러나 batching을 사용하면 업데이트가 각각 32 KB 크기의
배치로 적용됩니다. 이는 특히 개별 업데이트가 상대적으로 작은 경우
더 높은 처리량과 더 적은 CPU 사용량을 가져올 수 있습니다.
참고
Batching은 epoch 단위로 동작합니다. 둘 이상의 트랜잭션에 속하는 업데이트가 동일 배치의 일부로 전송될 수 있습니다.
epoch의 끝에 도달하면, 누적된 업데이트의 총량이 32 KB보다 적더라도 모든 미처리 업데이트가 적용됩니다.
Batching은 런타임에 켜거나 끌 수 있습니다. 런타임에 이를 활성화하려면 다음 두 statement 중 하나를 사용할 수 있습니다:
1SET GLOBAL replica_allow_batching = 1; 2SET GLOBAL replica_allow_batching = ON;
특정 배치가 문제를 일으키는 경우(예를 들어, 그 효과가 올바르게 replicate되지 않는 것으로 보이는 statement가 있는 경우) batching은 다음 statement 중 하나를 사용하여 비활성화할 수 있습니다:
1SET GLOBAL replica_allow_batching = 0; 2SET GLOBAL replica_allow_batching = OFF;
적절한 SHOW VARIABLES
statement를 사용하여 현재 batching이 사용 중인지 확인할 수 있습니다.
예를 들면 다음과 같습니다:
1mysql> SHOW VARIABLES LIKE 'replica%';
25.7.5 Preparing the NDB Cluster for Replication
25.7.7 Using Two Replication Channels for NDB Cluster Replication