18.6.4 MySQL Cluster Replication 스키마와 테이블
MySQL Cluster에서의 복제는 복제 된 클러스터와 복제 슬레이브 (슬레이브는 단일 서버이거나 클러스터 인 경우가 있습니다) 모두에서 SQL 노드 역할을 각 MySQL Server 인스턴스의 mysql 데이터베이스 수많은 전용 테이블을 사용합니다. 이 테이블은 mysql_install_db 스크립트가 MySQL의 설치 과정에서 생성 된 바이너리 로그의 인덱스 데이터를 저장하는 테이블을 포함합니다. ndb_binlog_index 테이블은 각 MySQL 서버에 로컬이며 클러스터는 사용되지 않고, MyISAM 스토리지 엔진을 사용합니다. 즉 이것은 각 mysqld에서 개별적으로 작성된 마스터 클러스터에 참여해야합니다. (단, 바이너리 로그 자체는 복제되는 클러스터에있는 모든 MySQL 서버에서 업데이트가 포함되어 있습니다.)이 테이블은 다음과 같이 정의됩니다.
CREATE TABLE `ndb_binlog_index` (
`Position` BIGINT(20) UNSIGNED NOT NULL,
`File` VARCHAR(255) NOT NULL,
`epoch` BIGINT(20) UNSIGNED NOT NULL,
`inserts` INT(10) UNSIGNED NOT NULL,
`updates` INT(10) UNSIGNED NOT NULL,
`deletes` INT(10) UNSIGNED NOT NULL,
`schemaops` INT(10) UNSIGNED NOT NULL,
`orig_server_id` INT(10) UNSIGNED NOT NULL,
`orig_epoch` BIGINT(20) UNSIGNED NOT NULL,
`gci` INT(10) UNSIGNED NOT NULL,
`next_position` bigint(20) unsigned NOT NULL,
`next_file` varchar(255) NOT NULL,
PRIMARY KEY (`epoch`,`orig_server_id`,`orig_epoch`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
이 테이블의 크기는 바이너리 로그 파일 당 신기원 수 및 바이너리 로그 파일 수에 따라 달라집니다. 일반적으로 바이너리 로그 파일 당 신기원 수는 시대마다 생성되는 바이너리 로그의 양과 바이너리 로그 파일의 크기에 따라, 시대가 작아지면 파일 당 시대가 증가합니다. 하늘의 신기원는 --ndb-log-empty-epochs 옵션이 OFF 의 경우에도 ndb_binlog_index 테이블에 삽입되는 결과가되어, 파일 당 항목 수는 파일이 사용중인 시간의 길이에 따라 점 주의하십시오. 즉 다음과 같습니다.
[number of epochs per file] = [time spent per file] / TimeBetweenEpochs
바쁜 MySQL Cluster는 정기적으로 바이너리 로그에 기록 아마도 바쁜 아닌 MySQL Cluster보다 자주 바이너리 로그 파일을 교체합니다. 즉 --ndb-log-empty-epochs=ON 인 '바쁜 없다 "MySQL Cluster는 대량의 활동을 가진 MySQL Cluster에 비해 실제로는 파일 당 ndb_binlog_index 행수를 꽤 많이 가질 수 합니다.
mysqld가 --ndb-log-orig 옵션으로 시작되면 orig_server_id 과 orig_epoch 의 컬럼에 각각 이벤트가 발생한 서버의 ID와 이벤트가 발생하는 서버에서 행한 시대가 저장됩니다. 이것은 여러 마스터를 사용하는 MySQL Cluster 복제 설정에 도움이됩니다. 다중 마스터 설정에서 슬레이브에 적용되는 가장 높은 시대에 가장 가까운 바이너리 로그의 위치를 검출하는 데 사용되는 SELECT 문 ( 섹션 18.6.10 "MySQL Cluster 복제 : 멀티 마스터와 순환 복제" 를 참조 합니다),이 두 컬럼 (인덱싱되지 않습니다)를 사용합니다. 이는 특히 마스터가 --ndb-log-empty-epochs=ON 에서 실행하는 경우 쿼리는 테이블 스캔을 수행해야하기 때문에 페일 오버를 시도 할 때 성능 문제로 이어질 수 수 있습니다. 여기에서 같이 이러한 컬럼에 인덱스를 추가함으로써 다중 마스터 장애 조치 시간을 향상시킬 수 있습니다.
ALTER TABLE mysql.ndb_binlog_index
ADD INDEX orig_lookup USING BTREE (orig_server_id, orig_epoch);
이 인덱스를 추가해도 하나의 마스터에서 1 개의 슬레이브에 복제하는 경우 도움이되지 않습니다. 이것은 이러한 경우에 바이너리 로그의 위치를 가져 오는 데 사용하는 쿼리는 orig_server_id 또는 orig_epoch 을 이용하지 않기 때문입니다.
next_position 및 next_file 컬럼 사용에 대한 자세한 내용은 섹션 18.6.8 "MySQL Cluster 복제를 사용한 장애 조치 구현" 을 참조하십시오.
다음 그림은 MySQL Cluster 복제 마스터 서버의 바이너리 로그의 인젝터 스레드 및 mysql.ndb_binlog_index 테이블의 관계를 보여줍니다.
ndb_apply_status 라는 추가 테이블은 마스터에서 슬레이브에 복제 된 작업의 기록을 위해 사용됩니다. ndb_binlog_index 의 경우와 달리,이 테이블의 데이터는 (슬레이브) 클러스터의 모든 SQL 노드에 특정되어 있지 않기 때문에, 여기에 같이 ndb_apply_status 는 NDBCLUSTER 스토리지 엔진을 사용할 수 있습니다.
CREATE TABLE `ndb_apply_status` (
`server_id` INT(10) UNSIGNED NOT NULL,
`epoch` BIGINT(20) UNSIGNED NOT NULL,
`log_name` VARCHAR(255) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
`start_pos` BIGINT(20) UNSIGNED NOT NULL,
`end_pos` BIGINT(20) UNSIGNED NOT NULL,
PRIMARY KEY (`server_id`) USING HASH
) ENGINE=NDBCLUSTER DEFAULT CHARSET=latin1;
ndb_apply_status 테이블은 슬레이브로만 채워집니다. 이것은 마스터는이 테이블에 행이 포함되지 않는 것을 의미합니다. 따라서 여기에서 ndb_apply_status 에 할당 DataMemory 또는 IndexMemory 을 고려해야합니다.
이 테이블은 마스터에서 데이터로부터 이입되기 때문에 복제는 허용됩니다. 그러나 복제 필터링 규칙 또는 바이너리 로그 필터링 규칙은 의도하지 않고 노예가 ndb_apply_status 를 업데이트하지 않거나 마스터가 바이너리 로그에 기록하지 않거나하면 클러스터 간의 복제가 제대로 작동하지 않을 수 있습니다. 이러한 필터링 규칙에 의한 잠재적 인 문제의 자세한 내용은 MySQL Cluster 간 복제에 사용하는 복제 및 바이너리 로깅 필터링 규칙 을 참조하십시오.
ndb_binlog_index 과 ndb_apply_status 테이블은 사용자가 명시 적으로 복제되지 않기 때문에 mysql 데이터베이스에 만들어집니다. 일반적으로 이러한 테이블 중 하나를 만들거나 유지하려면 사용자 개입이 필요하지 않습니다. ndb_binlog_index 과 ndb_apply_status 의 모두 NDB 바이너리 로그 (binlog)의 인젝터 스레드에 의해 유지되기 때문입니다. 그러면 마스터 mysqld 프로세스는 NDB 스토리지 엔진에 의해 수행 된 변경에 대한 업데이트가 유지됩니다. NDB binlog 인젝터 쓰레드는 NDB 스토리지 엔진에서 직접 이벤트를받습니다. NDB 인젝터는 클러스터의 모든 데이터 이벤트를 취득하는 역할을하고, 데이터를 수정, 삽입 또는 삭제하는 모든 이벤트가 ndb_binlog_index 테이블에 기록되었는지 확인합니다. 슬레이브 I / O 쓰레드는 마스터의 바이너리 로그에서 슬레이브 릴레이 로그에 이벤트를 전송합니다.
그러나 복제를 위해 MySQL Cluster를 준비하는 초기 단계에서 이러한 테이블의 존재와 완전성을 확인하는 것이 좋습니다. 마스터 mysql.ndb_binlog_index 테이블에 직접 쿼리를 발행하여 바이너리 로그에 기록 된 이벤트 데이터를 볼 수 있습니다. 이것은 복제 마스터 또는 슬레이브 MySQL 서버 중 하나에서 SHOW BINLOG EVENTS 문을 사용하여 수행 할 수 있습니다. ( 섹션 13.7.5.3 "SHOW BINLOG EVENTS 구문" 을 참조하십시오.)
SHOW ENGINE NDB STATUS 출력에서 유용한 정보를 얻을 수 있습니다.
ndb_schema 테이블은 NDB 테이블에 열린 스키마 변경을 추적하는 데 사용됩니다. 여기서 같이 정의됩니다.
CREATE TABLE ndb_schema (
`db` VARBINARY(63) NOT NULL,
`name` VARBINARY(63) NOT NULL,
`slock` BINARY(32) NOT NULL,
`query` BLOB NOT NULL,
`node_id` INT UNSIGNED NOT NULL,
`epoch` BIGINT UNSIGNED NOT NULL,
`id` INT UNSIGNED NOT NULL,
`version` INT UNSIGNED NOT NULL,
`type` INT UNSIGNED NOT NULL,
PRIMARY KEY USING HASH (db,name)
) ENGINE=NDB DEFAULT CHARSET=latin1;
이 섹션에서는 앞에서 언급 한 두 테이블과 달리 ndb_schema 테이블은 MySQL SHOW 명령문은 INFORMATION_SCHEMA 테이블에서 볼 수 없습니다. 그러나 여기에서 같이 ndb_show_tables의 출력에서 볼 수 있습니다.
shell> ndb_show_tables -t 2
id type state logging database schema name
4 UserTable Online Yes mysql def ndb_apply_status
5 UserTable Online Yes ndbworld def City
6 UserTable Online Yes ndbworld def Country
3 UserTable Online Yes mysql def NDB$BLOB_2_3
7 UserTable Online Yes ndbworld def CountryLanguage
2 UserTable Online Yes mysql def ndb_schema
NDBT_ProgramExit: 0 - OK
여기에서 같이 mysql 및 기타 MySQL 클라이언트 응용 프로그램이 테이블의 SELECT 를 발행 할 수 있습니다.
mysql> SELECT * FROM mysql.ndb_schema WHERE name='City' \G
*************************** 1. row ***************************
db: ndbworld
name: City
slock:
query: alter table City engine=ndb
node_id: 4
epoch: 0
id: 0
version: 0
type: 7
1 row in set (0.00 sec)
이 응용 프로그램의 디버깅에 사용되는 경우가 있습니다.
NDB 테이블에서 스키마 변경을 할 경우 응용 프로그램은 ALTER TABLE 문을 사용하는 MySQL 클라이언트 연결이 문이 돌아올 때까지 기다린 후 업데이트 된 테이블 정의의 사용을 시도합니다.
ndb_apply_status 테이블 또는 ndb_schema 테이블이 슬레이브에 존재하지 않는 경우, ndb_restore는 존재하지 않는 테이블 (또는 여러 테이블)을 다시 만듭니다 (Bug # 14612).
MySQL Cluster 복제 충돌 해결에 추가 mysql.ndb_replication 테이블이 필요합니다. 현재이 테이블을 수동으로 작성해야합니다. 이렇게하는 방법에 대한 자세한 내용은 섹션 18.6.11 "MySQL Cluster 복제 충돌 해결" 을 참조하십시오.