Binlog MySQL 复制是一个“伤害包”。有什么好的选择吗？答案

【问题标题】：Binlog MySQL Replication is a "Bag of Hurt". Are there any good alternatives?Binlog MySQL 复制是一个“伤害包”。有什么好的选择吗？
【发布时间】：2010-09-21 07:46:38
【问题描述】：

我老实说tried this left and right 仍然发现我的镜像服务器设置为复制从属仍然落后。我的应用程序的用户群不断增长，现在我已经到了无法继续“关闭”以“重新同步”数据库的地步（即使在周末也不行）。

无论如何，我的问题是：是否有任何合理的、负担得起的替代二进制日志复制的方法？我有两台服务器，所以暂时不考虑购买第三台用于负载平衡，除非它是唯一的选择。

干杯，

/mp

【问题讨论】：

与其他替代方案相比，mysql 复制是一种稳定、快速和精简的解决方案。 booking.com 使用了令人难以置信的许多 mysql 实例和我所听到的级联复制设置。如果您的网站真的太大，您可能需要专业人员来帮助您进行故障排除，如果您的从站在硬件方面不是太小的话。我个人有每秒超过 10k 次查询的设置，这些设置没有从属滞后的问题。可能您的复制设置也不完美。

标签： mysql replication binlog

【解决方案1】：

您的 master 并行执行，您的 slave 串行执行。如果您的 master 可以在 1 个真实小时内处理 1.5 小时的插入/更新/执行，那么您的 slave 将落后。

如果您找不到提高从属设备写入性能的方法（更多内存、更快的磁盘、删除不必要的索引），那么您的应用程序架构就遇到了限制。最终，您会遇到一个点，即您无法像您的 master 并行执行更改一样快地实时执行更改。

许多大型网站对他们的数据库进行分片：考虑将您的主+从分成多个主+从集群。然后将您的客户群拆分到这些集群中。当一个 slave 开始落后时，是时候添加另一个集群了。

这并不便宜，但除非你能找到一种方法让 binlog 复制并行执行语句，否则你可能找不到更好的方法。

更新 (2017)：MySQL 现在支持 parallel slave worker threads。仍然有很多变量会导致从机落后，但是从机不再需要按串行顺序写入。选择保留并行从属线程的提交顺序是查看从属在任何时间点的确切状态是否至关重要的重要选项。

【讨论】：

有时候你只需要听到残酷的真相
所有应用程序都遇到了某种扩展限制。大多数数据库命中磁盘 IO。听起来你的是复制。不利的一面是，您无法购买更大的数据库服务器来完成工作。从好的方面来说，您可以购买更小的数据库服务器 :)

【解决方案2】：

您是否尝试过： 1) 设置 innodb_flush_log_at_trx_commit=0 2) SET sync_binlog=0

如果您的服务器出现故障，两者都将有助于加速您的从站，但增加的风险很小。

【讨论】：

这两个命令在性能方面会创造奇迹。请记住，如果您的主服务器崩溃，您可能会丢失尚未从 RAM 进入磁盘上的二进制日志的事务。如果没问题，你应该很高兴。

【解决方案3】：

向从站添加内存可能会有所帮助。我们从 32 到 128 兆，滞后或多或少消失了。但它既不便宜，也不适合所有情况。

虽然购买第三台服务器可能不会有太大帮助，但您很可能只会得到另一个滞后的从属服务器。

【讨论】：