Nice programing

MySQL의 BLACKHOLE Engine의 목적은 무엇입니까?

nicepro 2020. 12. 25. 22:54
반응형

MySQL의 BLACKHOLE Engine의 목적은 무엇입니까?


나중에 검색 할 수없는 것을 저장하는 이유는 무엇입니까? 점은 무엇인가?


모든 SQL 문이 모든 노드에서 실행되지만 일부 노드 만 실제로 결과를 저장하는 복제 된 환경에서 유용합니다. 이것은 문서에 제공된 사용 사례입니다. http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html

문서에 제공된 다른 용도는 다음과 같습니다.

  • 덤프 파일 구문 확인.
  • 이진 로깅을 활성화하거나 활성화하지 않은 상태에서 BLACKHOLE을 사용하여 성능을 비교하여 이진 로깅의 오버 헤드를 측정합니다.
  • BLACKHOLE은 본질적으로 "no-op"스토리지 엔진이므로 스토리지 엔진 자체와 관련이없는 성능 병목 현상을 찾는 데 사용할 수 있습니다.

각각 MySQL 서버를 실행하는 두 대의 컴퓨터가 있다고 가정합니다. 한 컴퓨터는 기본 데이터베이스를 호스팅하고 두 번째 컴퓨터 는 백업으로 사용 하는 복제 슬레이브호스팅합니다 .

또한 기본 서버에 백업하지 않을 데이터베이스 나 테이블이 있다고 가정합니다. 이탈률이 높은 캐시 테이블 일 수 있으며 콘텐츠를 잃어도 문제가되지 않습니다. 따라서 디스크 공간을 절약하고 CPU, 메모리 및 디스크 IO를 불필요하게 사용하지 않으려면 복제 옵션사용하여 백업하지 않을 테이블에 영향을주는 문을 무시하도록 슬레이브를 구성합니다.

그러나 복제 필터 는 슬레이브 서버 에만 적용 되므로 마스터 서버에서 실행되는 모든 명령문 의 binlog 는 네트워크를 통해 전송되어야합니다. 여기서 낭비되는 대역폭이 있습니다. 마스터 서버는 슬레이브가 수신 즉시 버릴 트랜잭션에 대한 binlog를 전송합니다. 더 잘하고 불필요한 대역폭 사용을 피할 수 있습니까?

예, 가능합니다. 여기에 BLACKHOLE 엔진이 있습니다. 마스터 서버가 실행 되는 동일한 컴퓨터 에서 두 번째 더미를 실행합니다.mysqld이 프로세스는 BLACKHOLE 데이터베이스를 호스팅합니다. 실제 슬레이브와 동일한 복제 옵션을 사용하여 마스터 프로세스의 binlog에서 복제하고 자체 binlog를 생성하도록이 더미 프로세스를 구성합니다. 더미 프로세스의 binlog는 이제 실제 슬레이브가 필요로하는 명령문 만 포함하고 있으며 (BLACKHOLE 엔진을 사용하기 때문에) binlog에서 원하지 않는 명령문을 필터링하는 것 이상의 실제 작업을 수행하지 않았습니다. 마지막으로 원본 마스터 프로세스의 binlog가 아닌 더미 프로세스의 binlog에서 복제하도록 실제 슬레이브를 구성합니다. 이제 마스터 서버와 슬레이브 서버를 호스팅하는 두 컴퓨터 사이의 불필요한 네트워크 트래픽을 제거했습니다.

이 설정은 BLACKHOLE 문서 의이 단락과 다이어그램에 의해 설명되고 설명되는 것입니다 (훨씬 더 간결하게) .

애플리케이션에 슬레이브 측 필터링 규칙이 필요하지만 먼저 모든 이진 로그 데이터를 슬레이브로 전송하면 트래픽이 너무 많이 발생한다고 가정합니다. 이러한 경우 기본 스토리지 엔진이 BLACKHOLE 인 "더미"슬레이브 프로세스를 마스터 호스트에 설정할 수 있습니다.

위에서 설명한 시나리오의 다이어그램

필터링 외에도 문서는 binlogging이 활성화 된 BLACKHOLE 서버를 사용하는 것이 "리피터 ... 메커니즘으로 유용 할 수 있음" 을 암호화하여 암시합니다 . 이 사용 사례는 문서에서 덜 구체화되지만 이것이 의미가있는 시나리오를 상상할 수 있습니다. 예를 들어, 서로 빠른 로컬 연결을 사용하는 로컬 네트워크의 컴퓨터에 많은 슬레이브 서버가 있고 모두 인터넷을 통해서만 연결할 수있는 원격 슬레이브에서 대량의 데이터를 복제해야한다고 가정합니다. 동일한 데이터를 여러 번 가져오고 필요한 것보다 몇 배 더 많은 인터넷 대역폭을 사용하기 때문에 마스터 박스에서 모두 직접 복제하는 것은 원하지 않습니다. 하지만 당신 기존 슬레이브 중 하나만 마스터에서 복제하고 다른 슬레이브는 해당 슬레이브에서 복제하는 것을 원하지 않습니다. 아마도 슬레이브가 마스터보다 훨씬 덜 신뢰할 수있는 시스템에서 실행 중이거나 상자를 죽일 수있는 다른 프로세스를 실행하고 있기 때문일 수 있습니다. CPU 또는 메모리를 모두 먹음으로써 전체 슬레이브 네트워크를 무너 뜨리는 중간 슬레이브에서 소프트웨어 또는 하드웨어 오류가 발생할 위험이 없습니다. 너 뭐하니?

한 가지 가능한 타협은 스토리지가 아닌 안정성과 성능에 최적화 된 중개자 역할을하는 추가 상자를 슬레이브 네트워크에 도입하는 것입니다. 작고 안정적인 SSD 드라이브 mysqld를 제공하고 원격 마스터에서 복제 하는 프로세스 외에는 아무것도 실행하지 않고 다른 슬레이브가 구독 할 수있는 binlog를 생성하도록합니다. 그리고 물론이 중간 슬레이브는 BLACKHOLE 엔진을 사용하도록 설정하여 저장 공간이 필요하지 않습니다.

문서에 자세히 설명 된이 슬레이브와 중간 필터링 슬레이브는 모두 에지 케이스입니다. 대부분의 MySQL 사용자는 이러한 전략 중 하나를 사용하여 이익을 얻을 수있는 상황에 처하지 않으며 실제로 설정하는 작업을 수행하는 것을 정당화 할 수있는 충분한 이점을 얻습니다. 그러나 적어도 이론적으로는 BLACKHOLE 엔진을 사용하여 노드가 실제로 디스크에 데이터를 저장할 필요없이 대역폭 보존 전략으로 복제 슬레이브 네트워크에서 중간 노드를 만들 수 있습니다.

참조 URL : https://stackoverflow.com/questions/4593496/what-is-the-purpose-of-mysqls-blackhole-engine

반응형