MySQL 5.6 한글메뉴얼

15.6 BLACKHOLE 스토리지 엔진

BLACKHOLE 스토리지 엔진은 데이터를 수신하더라도 무시하고 저장하지 않는 '블랙홀'역할을합니다. 검색은 항상 빈 결과를 반환합니다.

 mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;
 Query OK, 0 rows affected (0.03 sec)

 mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');
 Query OK, 2 rows affected (0.00 sec)
 Records : 2 Duplicates : 0 Warnings : 0

 mysql> SELECT * FROM test;
 Empty set (0.00 sec)

소스에서 MySQL을 구축하는 경우 BLACKHOLE 스토리지 엔진을 사용하려면 CMake를 -DWITH_BLACKHOLE_STORAGE_ENGINE 옵션으로 호출합니다.

BLACKHOLE 엔진의 소스를 확인하려면 MySQL 소스 배포판의 sql 디렉토리를 검색합니다.

BLACKHOLE 테이블을 만들 때 서버는 데이터베이스 디렉토리에 테이블 포맷 파일을 만듭니다. 파일은 테이블 이름에서 시작 .frm 확장자가 붙습니다. 테이블 관련 파일 외에 없습니다.

BLACKHOLE 스토리지 엔진은 모든 종류의 인덱스를 지원하고 있습니다. 즉, 테이블 정의에 인덱스 선언을 포함 할 수 있습니다.

BLACKHOLE 스토리지 엔진이 SHOW ENGINES 명령문에서 사용할 수 있는지 여부를 확인할 수 있습니다.

BLACKHOLE 테이블에 삽입 데이터를 저장하지 않지만 명령문 기반 바이너리 로깅이 활성화되어있는 경우, SQL 문은 로그가 기록되고 슬레이브 서버에 복제됩니다. 이것은 반복 또는 필터 메커니즘으로 도움이 될 수 있습니다.

참고

바이너리 로그에 행 기반 포맷을 사용하면 업데이트 및 삭제는 무시되고 로그도 적용되지 않습니다. 따라서 바이너리 로깅 형식으로 ROW와 MIXED 대신 STATEMENT를 사용하십시오.

응용 프로그램이 슬레이브 필터링 규칙을 요구하더라도 모든 바이너리 로그 데이터를 먼저 슬레이브로 전송하면 트래픽이 너무 많이합니다. 그런 경우는 다음과 같이 마스터 호스트에 기본 스토리지 엔진이 BLACKHOLE 인 "dummy"슬레이브 프로세스를 설정할 수 있습니다.

마스터 바이너리 로그에 기록합니다. "dummy"mysqld 프로세스는 슬레이브로 작동하고 replicate-do-* 와 replicate-ignore-* 규칙의 적절한 조합을 적용하여 자체 필터링 된 새로운 바이너리 로그를 기록합니다. 섹션 17.1.4 "복제 및 바이너리 로깅 옵션과 변수" 를 참조하십시오. 필터링 된 로그는 슬레이브에 제공됩니다.

더미 프로세스는 실제로 데이터를 저장하지 않기 때문에 복제 마스터 호스트에서 추가 mysqld 프로세스를 실행해서 처리 오버 헤드가 거의 없습니다. 이 유형의 설치는 다른 리플리케이션 슬레이브에서 반복 할 수 있습니다.

BLACKHOLE 테이블의 INSERT 트리거는 예상대로 작동합니다. 그러나 실제로는 BLACKHOLE 테이블 데이터를 저장하지 않기 때문에 UPDATE 및 DELETE 트리거는 유효하지 않습니다. 트리거 정의 FOR EACH ROW 절은 행이 없기 때문에 적용되지 않습니다.

BLACKHOLE 스토리지 엔진 기타 이용 방법은 다음과 같습니다.

덤프 파일 구문을 확인합니다.
바이너리 로깅의 오버 헤드를 측정 (바이너리 로깅이 활성화 된 경우와 유효하지 않은 경우의 성능을 BLACKHOLE 을 이용하여 비교함으로써).
BLACKHOLE 는 본질적으로 "no-op"스토리지 엔진이기 때문에 스토리지 엔진 자체와 관련이없는 성능 병목 현상의 검출에 사용되는 경우가 있습니다.

커밋 된 트랜잭션은 바이너리 로그에 기록되고 롤백 된 트랜잭션은 기록되지 않는다는 의미에서 BLACKHOLE 엔진은 트랜잭션 지원입니다.

Blackhole 엔진과 자동 증가 컬럼

Blackhole 엔진은 no-op 엔진입니다. Blackhole을 사용하여 테이블에서 수행되는 작업은 효과가 없습니다. 이것은 자동으로 증가하는 프라이 머리 키 컬럼의 동작을 고려할 때 염두에 두도록하십시오. 이 엔진은 필드 값을 자동으로 증가하지 않고 자동 증가 필드의 상태를 유지하지 않습니다. 이것은 복제에서 중요한 의미를 갖습니다.

다음 세 가지 조건이 모두 적용되는 다음 복제 시나리오를 고려합니다.

마스터 서버는 기본 키 자동 증가 필드를 가진 블랙홀 테이블이 있습니다.
슬레이브는 같은 테이블이 존재하지만, MyISAM 엔진을 사용합니다.
INSERT 문 자신에 자동 증가 값을 명시 적으로 설정하지 않고, 즉 SET INSERT_ID 문을 사용하여 마스터 테이블에 삽입이 수행됩니다.

이 시나리오에서는 복제는 프라이 머리 키 컬럼에서 중복 항목 오류로 실패합니다.

문 기반 복제는 컨텍스트 이벤트 INSERT_ID 값은 항상 동일합니다. 따라서 프라이 머리 키 컬럼에 중복 값이있는 행을 삽입하려고하면 복제가 실패합니다.

행 기반 복제는 엔진에서 리턴되는 행의 값은 각 삽입에 항상 동일합니다. 따라서 슬레이브는 프라이 머리 키 컬럼에 동일한 값을 사용하는 2 개의 삽입 로그 항목을 재생하려고 복제가 실패합니다.

열 필터링

행 기반 복제 ( binlog_format=ROW )를 사용하면 섹션 17.4.1.9 "테이블 정의가 다른 마스터와 슬레이브로 복제" 섹션에서 설명 된 바와 같이, 마지막 컬럼이 테이블에서 잃어버린 슬레이브 지원 합니다.

이 필터는 슬레이브로 작동합니다. 즉 열은 필터링되기 전에 슬레이브에 복사됩니다. 슬레이브에 열을 복사 할 바람직하지 않은 케이스가 두 개 이상 있습니다.

데이터가 민감한 경우, 슬레이브 서버는 액세스해서는 없습니다.
마스터가 많은 노예를 가지는 경우, 슬레이브에 쓰기 전에 필터링하면 네트워크 트래픽이 감소 될 가능성이 있습니다.

마스터 컬럼의 필터링은 BLACKHOLE 엔진을 사용하여 얻을 수 있습니다. 이것은 마스터 테이블 필터링의 실현 방법 ( BLACKHOLE 엔진과 --replicate-do-table 또는 --replicate-ignore-table 옵션을 사용)과 유사한 방법으로 실행됩니다.

마스터 설정은 다음과 같습니다.

 CREATE TABLE t1 (public_col_1, ..., public_col_N,
                  secret_col_1, ..., secret_col_M) ENGINE = MyISAM;

신뢰할 수있는 슬레이브 설정은 다음과 같습니다.

 CREATE TABLE t1 (public_col_1, ..., public_col_N) ENGINE = BLACKHOLE;

신뢰되지 않는 슬레이브 설정은 다음과 같습니다.

  CREATE TABLE t1 (public_col_1, ..., public_col_N) ENGINE = MyISAM;