我们可以在 MySQL 5.0 复制中做些什么来解决带宽问题？

Question

我正在开发一个在客户端 PC (Win) 上运行的应用程序，该客户端配置了 MySQL 服务器 5.1 实例，该实例将充当远程主服务器的只读从属服务器。远程主服务器有几十个模式，但我每个客户端只需要一个，所以我提供了 复制-do-db my.ini 中的设置仅复制客户端需要的架构。复制是有效的，但当我们的客户进入世界上只能通过 3G 无线访问互联网并按数据使用量收费的地区时，他们很快就会超出其数据计划限制并遇到昂贵的问题。

据我了解，MySQL 将所有模式的所有事务写入单个 binlog 文件，这意味着每个客户端必须下载在主服务器上的每个模式上执行的所有事务，然后下载后，应用每个模式的数据库过滤器。 复制-do-db 客户端的 my.ini 文件中的设置。

为了最大限度地减少这种低效率，我采用了 从属压缩协议 = 1 设置，这似乎减少了 50% 的传输数据，但仍然导致我们的客户很快超出其数据限制，增加了 3G 账单。

我无法想象我是唯一面临这个问题的人，所以我确信我会得到大量关于如何通过设置 x = y 来实现这一目标的答案。但是，我找不到此类设置的任何文档，也找不到推荐的方法。

到目前为止，这是我对可能的解决方案的想法，请提供反馈或替代路线：

---

1. 为每个模式设置一个“代理”从属设备（在不同的机器上，或具有不同 MySQL 实例/端口的同一机器上）
2. 将代理从服务器配置为仅复制-do-db 客户端希望复制的一个数据库。
3. 将客户端的 MySQL 实例配置为相应代理从属的从属实例。

这 应该 导致客户端仅提取其模式的二进制日志数据。缺点（据我所知）是它极大地增加了我们设置的复杂性，可能使其更加脆弱。

想法？这种方法会起作用吗？

请注意，我们在 RedHat 上运行 MySQL 5.0 服务器，但如果它能提供解决方案，我们可以升级到 5.5。

Answer 1

建议#1：使用分发大师

分发主机是一个启用了 log-bin、启用了 log-slave-updates 的 mysql 从机，并且仅包含具有 黑洞存储引擎. 。您可以将replicate-do-db应用于分发主机，并在分发主机上创建仅包含您想要进行二进制记录的数据库模式的二进制日志。 通过这种方式，您可以减少来自 Distribution Master 的传出二进制日志的大小。

您可以按如下方式设置分发主机：

1. mysqldump 使用 --no-data 选项生成仅模式转储的数据库。
2. 将仅架构转储加载到分发主机。
3. 将 Distribution Master 中的每个表转换为 BLACKHOLE 存储引擎。
4. 设置从具有真实数据的主服务器到分发主服务器的复制。
5. 将replicate-do-db 选项添加到Distribution Master 的/etc/my.cnf 中。

对于步骤 2 和 3，您还可以编辑仅架构转储并将 ENGINE=MyISAM 和 ENGINE=InnoDB 替换为 ENGINE=BLACKHOLE，然后将编辑后的仅架构转储加载到分发主机中。

仅在步骤 3 中，如果您想要编写将所有 MyISAM 和 InnoDB 表转换为 Distribution Master 中的 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，您就可以在让客户端仅复制他们想要的数据库信息之前传输您想要的任何 DML（插入、更新、删除）。

我已经在另一个 StackExchange 站点上写了一篇文章，讨论如何使用 Distribution Master.

建议#2：使用较小的二进制日志和中继日志

如果你设置 最大二进制日志大小 到小得离谱的东西，然后可以收集二进制日志并以较小的块发送出去。还有一个单独的选项来设置中继日志的大小， 最大中继日志大小. 。如果 max_relay_log_size = 0，它将默认为 max_binlog_size 设置的值。

建议#3： 使用半同步复制 （仅限 MySQL 5.5）

将您的主数据库和多个 Distribution Master 设置为 MySQL 5.5。启用半同步复制，以便主数据库可以快速将binlog发送到Distribution Master。如果您的所有从属服务器都是分发主服务器，则您可能不需要半同步复制或 MySQL 5.5。如果除分发主机之外的任何从机具有用于报告、高可用性、被动待机或备份目的的真实数据，则将 MySQL 5.5 与半同步复制结合使用。

建议#4：使用基于语句的二进制日志记录而不是基于行的

如果 SQL 语句更新表中的多行，则基于语句的二进制日志记录 (SBBL) 仅存储 SQL 语句。使用基于行的二进制日志记录 (RBBL) 的相同 SQL 语句将实际记录每行的行更改。这表明传输 SQL 语句将通过 RBBL 执行 SBBL 来节省二进制日志的空间。

另一个问题是将 RBBL 与replicate-do-db 结合使用，其中表名前面带有数据库. 。这对于奴隶来说并不是一件好事，尤其是对于分配大师来说。因此，请确保所有 DML 都没有数据库且任何表名前面都没有句点。

Answer 2

max_binlog_size应该是无关紧要的 - binlog数据被连续流出。

警告“分销主” - 这是“单点失败”。也就是说，如果它死了，那么所有的奴隶都不会接收数据，重建继电器将需要工作。

sbr vs rbr-取决于查询。要么比其他更好或更糟。

将分销大师与真正的主机或“接近”主机的机器放在同一台机器上。使用单独的端口将实例分开。