我們可以在 MySQL 5.0 Replication 中做些什麼來解決頻寬問題？
我正在開發一個在客戶端 PC (Win) 上執行的應用程序，該 PC 配置了 MySQL 伺服器 5.1 實例，該實例將充當遠端主機的只讀從屬。遠端主機有幾十個模式，但我每個客戶端只需要一個，所以我在 my.ini 中提供了replication-do-db設置，只複製客戶端需要的模式。複製是有效的，但是當我們的客戶進入世界上只能通過 3G 無線訪問網際網路的地區時，他們很快就會超過他們的數據計劃限制並遇到昂貴的問題。
據我了解，MySQL 將所有模式的所有事務寫入單個二進制日誌文件，這意味著每個客戶端都必須下載在主節點上的每個模式上執行的所有事務，然後一旦下載，對每個複制應用數據庫過濾器-客戶端的 my.ini 文件中的do-db設置。
為了盡量減少這種低效率，我使用了slave_compressed_protocol = 1設置，這似乎將傳輸的數據減少了 50%，但仍然導致我們的客戶快速超過他們的數據限制，從而增加 3G 費用。
我無法想像我是唯一一個面臨這個問題的人，所以我相信我會得到很多關於如何通過設置 x = y 來實現這一點的答案。但是，我找不到這種設置的任何文件，也找不到推薦的方法。
到目前為止，這是我對可能解決方案的想法，請提供回饋或替代路線：
- 為每個模式設置一個“代理”從屬設備（在不同的盒子上，或具有不同 MySQL 實例/埠的同一個盒子上）
- 將代理從伺服器配置為僅複製客戶端希望複製的一個數據庫。
- 將客戶端的 MySQL 實例配置為相應代理從站的從站。
這應該會導致客戶端僅提取其架構的 binlog 數據。不利的一面（據我所知）是它極大地增加了我們設置的複雜性，可能使其更加脆弱。
想法？這種方法甚至會奏效嗎？
注意，我們在 RedHat 上執行 MySQL 5.0 伺服器，但如果它產生解決方案，我們可以升級到 5.5。
建議 #1：使用分發大師
Distribution Master 是一個啟用了 log-bin 和 log-slave-updates 的 mysql 從站，並且只包含帶有BLACKHOLE Storage Engine的表。您可以將 replicate-do-db 應用到 Distribution Master 並在 Distribution Master 上創建二進制日誌，其中僅包含您想要 binlogged 的 DB 模式。通過這種方式，您可以減少從 Distribution Master 傳出的二進制日誌的大小。
您可以按如下方式設置分發主機：
- mysqldump 您的數據庫使用 –no-data 選項生成僅模式轉儲。
- 將僅模式轉儲載入到分發主機。
- 將 Distribution Master 中的每個表都轉換為 BLACKHOLE 儲存引擎。
- 設置從具有真實數據的主控複製到分發主控。
- 將 replicate-do-db 選項添加到 Distribution Master 的 /etc/my.cnf。
對於步驟 2 和 3，您還可以編輯僅模式轉儲並將 ENGINE=MyISAM 和 ENGINE=InnoDB 替換為 ENGINE=BLACKHOLE，然後將已編輯的僅模式轉儲載入到分發主機中。
僅在第 3 步中，如果您想在 Distribution Master 中編寫將所有 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 發送到 Distribution Master，您就可以在讓客戶端僅複製他們想要的 DB 資訊之前傳輸您想要的任何 DML（插入、更新、刪除）。
我已經在另一個 StackExchange 站點上寫了一篇文章，討論了使用 Distribution Master。
建議 #2：使用較小的二進制日誌和中繼日誌
如果您將max_binlog_size設置為小得離譜的值，則可以收集 binlogs 並以較小的塊發送出去。還有一個單獨的選項來設置中繼日誌的大小，max_relay_log_size。如果 max_relay_log_size = 0，它將預設為 max_binlog_size 設置的值。
建議 #3：使用半同步複製（僅限 MySQL 5.5）
將您的主數據庫和多個 Distribution Master 設置為 MySQL 5.5。啟用半同步複製，以便主數據庫可以快速將 binlog 發送到 Distribution Master。如果您的所有從屬伺服器都是分發主機，您可能不需要半同步複製或 MySQL 5.5。如果除 Distribution Master 之外的任何從屬伺服器具有用於報告、高可用性、被動備用或備份目的的真實數據，則將 MySQL 5.5 與半同步複製結合使用。
建議 #4：使用基於語句的二進制日誌記錄而不是基於行的
如果 SQL 語句更新表中的多行，則基於語句的二進制日誌 (SBBL) 僅儲存 SQL 語句。使用基於行的二進制日誌 (RBBL) 的同一 SQL 語句將實際記錄每一行的行更改。這很明顯，傳輸 SQL 語句將在執行 SBBL 而不是 RBBL 的二進制日誌上節省空間。
另一個問題是將 RBBL 與 replicate-do-db 結合使用，其中表名具有數據庫前置。這對奴隸來說不是一件好事，尤其是對分配主人來說。因此，請確保所有 DML 沒有數據庫和任何表名前面的句點。