개념
MyISAM 및 InnoDB와 마찬가지로 BlackHole은 문자 그대로의 의미에서
블랙홀처럼 동작하며 들어오기만 하고 나가지는 않으며 들어오면 사라집니다. 즉, 여기에 기록된 모든 데이터는 Linux의 /dev/null과 유사하게 손실됩니다.
예를 들어 테이블 테스트의 엔진은 BlackHole이고 이 테이블에 대한 모든 삽입은 손실됩니다.
여기에서 선택하면 항상 반환됩니다. null 집합, 해당 데이터 디렉터리에 test.frm 파일이 하나만 있고 다른 파일은 연결되어 있지 않습니다.
사용 시나리오
데이터를 전혀 저장하지 않는 엔진이 무슨 의미가 있나요?
핵심은 데이터를 저장하지 않더라도 데이터베이스에서의 작업은 여전히 binlog 로그에 기록된다는 것입니다.
이는 마스터-슬레이브 복제의 중개자로 사용할 수 있다는 이점을 제공하며 원래 동기화 작업을 기본 데이터베이스에서 중개자로서 BlackHole 엔진 데이터베이스의 동기화로 변경합니다.
1. 의사 마스터 라이브러리로서 메인 라이브러리의 부담을 공유합니다
우리 모두 알고 있듯이 슬레이브 라이브러리가 많으면 모든 슬레이브 라이브러리가 메인 라이브러리에서 데이터를 로드하므로 메인 라이브러리의 부담이 늘어납니다. 도서관. 하지만 BlackHole의 pseudo-main 라이브러리에서 동기화하면 메인 라이브러리의 부담을 줄일 수 있습니다. 원래 마스터-슬레이브 아키텍처는 대략 다음과 같습니다.
现在，BlackHole伪主库作为中介，变成这样：
특히 의사 마스터 데이터베이스에서 복제 실행 및 복제 무시 규칙을 구성하여 필요하지 않은 테이블을 필터링할 수 있습니다. 동기화되었습니다.
2. binlog 로그 수집기로
실제 데이터를 저장하지 않고, binlog의 특성만 기록하므로, 엔진을 사용하여 binlog 로그를 수집하여 데이터베이스 분석을 용이하게 할 수 있습니다.
관련 지식: binlog 로그에는 행, 명령문, 혼합의 세 가지 형식이 있습니다.
row는 각 행의 변경된 기록을 기록합니다. 즉, 업데이트는 조건을 충족하는 모든 수정된 행을 기록합니다. Alter table은 더 나쁜데, 이는 전체 테이블을 다시 작성하고 모든 행의 변경 사항을 기록하는 것과 같습니다. 따라서 이 형식의 로그는 너무 커지기 쉽습니다.
statement 메소드는 데이터를 변경하는 SQL만 기록합니다. 행 메소드에는 문제가 없지만 SQL 실행의 컨텍스트 정보가 기록됩니다. 단점은 맥락이 다른 쪽에서 정보를 재현할 때 더 복잡한 정보로 인해 오류가 발생하기 쉽다는 것입니다.
mixed 메서드는 행 메서드와 문 메서드를 결합합니다.
Configuration
의사 라이브러리에서는 다음 구성이 필요합니다.
기본 구성 유형은 BlackHole입니다.
default_table_type = BLACKHOLE
또는
default-storage-engine = BLACKHOLE
을 사용하여 binlog를 열 수 있습니다. log-bin = ms-mysql- Bin
특별히 구성: log-slave-update = 1. 이렇게 해야 메인 라이브러리의 작업이 BlackHole의 binlog에 동기화됩니다. 그렇지 않으면 BlackHole을 직접 대상으로 하는 작업만 binlog에 기록됩니다. .
Ignore InnoDB: Skip-innodb. 테이블 생성 문에engine=innodb가 포함되어 있으면 기본 BlackHole 엔진이 사용됩니다.
이 아키텍처를 채택하면 데이터 동기화를 위한 추가 중간 계층이 있으며 지연 문제를 더 고려해야 한다는 점을 기억해야 합니다.