대역폭 문제를 해결하기 위해 MySQL 5.0 Replication에서 무엇을 할 수 있습니까?

원격 마스터에 대한 읽기 전용 슬레이브로 작동하는 MySQL 서버 5.1 인스턴스로 구성된 클라이언트 PC (Win)에서 실행할 응용 프로그램을 개발 중입니다. 원격 마스터에는 수십 개의 스키마가 있지만 클라이언트 당 하나만 필요하므로 클라이언트에 필요한 스키마 만 복제하기 위해 my.ini에 replication-do-db 설정을 제공합니다. 복제는 작동하지만 고객이 데이터 사용량에 따라 요금을 부과하는 3G 무선을 통해서만 인터넷에 액세스 할 수있는 전세계 지역에 도착하면 데이터 계획 한계를 빠르게 초과하여 고비용의 문제가 발생합니다.

내가 이해하는 것처럼 MySQL은 모든 스키마에 대한 모든 트랜잭션을 단일 binlog 파일에 기록합니다. 즉, 각 클라이언트는 마스터의 모든 스키마에서 수행되는 모든 트랜잭션을 다운로드 한 다음 다운로드되면 복제 당 데이터베이스 필터를 적용해야 합니다. 클라이언트의 my.ini 파일에서 do-db 설정.

이 비 효율성을 최소화하기 위해 slave_compressed_protocol = 1 설정을 사용했는데, 이는 전송 된 데이터를 50 % 줄인 것처럼 보이지만 고객의 데이터 한도를 빠르게 초과하여 3G 요금을 청구합니다.

나는 이것이 직면 한 유일한 사람이라고 상상할 수 없으므로 x = y를 설정하여이를 달성하는 방법에 대한 많은 답변을 얻을 것이라고 확신합니다. 그러나 그러한 설정에 대한 문서 나 권장되는 접근 방법을 찾을 수 없습니다.

지금까지 가능한 해결책에 대한 나의 생각은 다음과 같습니다. 피드백 또는 대체 경로를 제공하십시오.

1. 각 스키마에 대해 "프록시"슬레이브 설정 (다른 박스 또는 다른 MySQL 인스턴스 / 포트가있는 동일한 박스)
2. 클라이언트가 복제하려는 데이터베이스 하나만 replicate-do-db로 프록시 슬레이브를 구성하십시오.
3. 클라이언트의 MySQL 인스턴스를 적절한 프록시 슬레이브의 슬레이브로 구성하십시오.

이렇게 해야 클라이언트는 자신의 스키마에 대한 바이너리 로그 데이터를 끌어 초래한다. 단점은 (내가 알 수있는 한) 설정의 복잡성을 극적으로 증가시켜 더 깨지기 쉽다는 것입니다.

생각? 이 접근법은 효과가 있습니까?

RedHat에서 MySQL 5.0 서버를 실행하고 있지만 솔루션이 생성되면 5.5로 업그레이드 할 수 있습니다.

제안 # 1 : 분배 마스터 사용

Distribution Master는 log-bin이 활성화되고 log-slave-updates가 활성화 된 mysql 슬레이브이며 BLACKHOLE Storage Engine 이있는 테이블 만 포함합니다 . 복제 마스터에 replicate-do-db를 적용하고 배포 마스터에서 이진 로그를 생성하여 이진 로그를 생성하려는 DB 스키마 만 포함 할 수 있습니다. 이런 식으로 배포 마스터에서 나가는 binlog의 크기를 줄입니다.

다음과 같이 배포 마스터를 설정할 수 있습니다.

1. mysqldump --no-data 옵션을 사용하여 스키마 전용 덤프를 생성하여 데이터베이스를 덤프하십시오.
2. 스키마 전용 덤프를 배포 마스터에로드하십시오.
3. Distribution Master의 모든 테이블을 BLACKHOLE 스토리지 엔진으로 변환하십시오.
4. 실제 데이터가있는 마스터에서 배포 마스터로 복제를 설정합니다.
5. Distribution Master의 /etc/my.cnf에 replicate-do-db 옵션을 추가하십시오.

2 단계와 3 단계의 경우 스키마 전용 덤프를 편집하고 ENGINE = MyISAM 및 ENGINE = InnoDB를 ENGINE = BLACKHOLE로 바꾼 다음 편집 된 스키마 전용 덤프를 배포 마스터에로드 할 수 있습니다.

3 단계에서만 배포 마스터에서 모든 MyISAM 및 InnoDB 테이블을 BLACKHOLE로 변환하는 스크립트를 작성하려면 다음 쿼리를 실행하여 텍스트 파일로 출력하십시오.

mysql -h... -u... -p... -A --skip-column-names -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name', ENGINE=BLACKHOLE;') BlackholeConversion FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine <> 'BLACKHOLE'" > BlackholeMaker.sql

테이블을 BLACKHOLE 스토리지 엔진으로 변환하는 스크립트를 추가하면 MEMORY 스토리지 엔진 테이블도 변환됩니다. MEMORY 스토리지 엔진 테이블은 데이터 스토리지를위한 디스크 공간을 차지하지 않지만 메모리를 차지합니다. MEMORY 테이블을 BLACKHOLE로 변환하면 Distribution Master의 메모리가 깔끔하게 유지됩니다.

DDL을 배포 마스터로 보내지 않는 한 클라이언트가 원하는 DB 정보 만 복제하도록하기 전에 원하는 DML (INSERT, UPDATE, DELETE)을 전송할 수 있습니다.

이미 다른 StackExchange 사이트에 배포 마스터 사용에 대한 게시물을 작성했습니다 .

제안 # 2 : 작은 이진 로그 및 릴레이 로그 사용

max_binlog_size 를 엄청나게 작은 것으로 설정하면 binlog 를 수집하여 더 작은 청크로 나갈 수 있습니다. 릴레이 로그의 크기를 설정하는 별도의 옵션 인 max_relay_log_size도 있습니다. max_relay_log_size = 0이면 기본적으로 max_binlog_size가 설정된 값으로 설정됩니다.

제안 # 3 : 반 동기식 복제 사용 (MySQL 5.5 만 해당)

기본 데이터베이스와 여러 배포 마스터를 MySQL 5.5로 설정하십시오. 기본 데이터베이스가 binlog를 신속하게 배포 마스터에 제공 할 수 있도록 Semisynchronous Replication을 활성화하십시오. 모든 슬레이브가 배포 마스터 인 경우 반 동기식 복제 또는 MySQL 5.5가 필요하지 않을 수 있습니다. Distribution Masters 이외의 슬레이브 중 하나에보고, 고 가용성, 수동 대기 또는 백업 목적으로 실제 데이터가있는 경우 Semisynchronous Replication과 함께 MySQL 5.5를 사용하십시오.

제안 # 4 : 행 기반 NOT 문 기반 이진 로깅 사용

SQL 문이 테이블에서 여러 행을 업데이트하는 경우 SBBL (Statement-Based Binary Logging)은 SQL 문만 저장합니다. RBBL (Row-Based Binary Logging)을 사용하는 동일한 SQL 문은 각 행의 행 변경 사항을 실제로 기록합니다. 따라서 SQL 문을 전송하면 RBBL을 통해 SBBL을 수행하는 이진 로그의 공간이 절약됩니다.

또 다른 문제점은 테이블 이름에 데이터베이스가 추가 된 replicate-do-db와 함께 RBBL을 사용하는 것입니다 . 슬레이브, 특히 배포 마스터에는 적합하지 않습니다. 따라서 모든 DML에 데이터베이스와 테이블 이름 앞에 마침표가 없는지 확인하십시오.

max_binlog_size는 관련이 없어야합니다. binlog 데이터는 지속적으로 스트리밍됩니다.

"배포 마스터"에 대한주의- "단일 실패 지점"입니다. 즉, 그것이 죽으면, 그 이후의 모든 슬레이브 (들)는 데이터를 수신하지 않을 것이며, 릴레이를 재 구축하는 것이 작동 할 것입니다.

SBR 대 RBR-쿼리에 따라 다릅니다. 다른 것보다 낫거나 나쁠 수 있습니다.

배포 마스터를 실제 마스터와 동일한 컴퓨터 또는 마스터 근처의 컴퓨터에 배치하십시오. 별도의 포트를 사용하여 인스턴스를 분리하십시오.