性能影响MySQL复制与表同步脚本

Question

目前，我正在考虑为客户端实现一个MySQL表复制解决方案，这个客户端有2个服务器，位于两个不同的位置：

• 服务器1使用mysql数据库运行应用程序(运行Ubuntu14.04LTS)
• 服务器2有一个PHP and服务器前端，可以通过网站和客户面板(也是Ubuntu，相同版本)为其客户提供服务。

服务器1上的数据库总容量约为2.5GB。服务器位于不同的数据中心，但在5ms的延迟内，无论是千兆字节的上行，还是繁重的数据计划，都是如此。

目前，the服务器(2)完全依赖于应用服务器(1)的可用性。尽管这一点至关重要，但这确实意味着，在维护或非计划停机时，not服务器实际上是无用的，但客户端不希望将数据库同步到两个位置，而是允许同步单个帐户登录数据表(只是一个表，而不是同一个数据库中的其他表)，以至少保持网站完整的功能。

现在我正在考虑的两个选项是: A.使用“智能/高效”表同步脚本(https://www.percona.com/doc/percona-toolkit/2.1/pt-table-sync.html)为表B设置MySQL复制主->从设置。

我还考虑到，应用程序mysql服务器的二进制日志每天大约为8.5Gb，而我无法找到它对复制的确切性能影响。我可以说，我发言的表是88 is，大约有250.000行。我希望同步的account表的每日更改非常小，预计每天少于1000行)。

我目前倾向于选择B，因为

• 这样可以避免未来mysql服务器之间版本冲突的问题(我并不都为客户端管理这些问题)。
• 对于我希望同步的特定表，数据更改的数量相当少。
• MySQL提供的只同步特定表的方法似乎还不够完善，因为复制技术更加强调将其用作完整的复制解决方案(在这里，我担心大型二进制日志会对mysql论坛/文章的评论产生负面影响)。
• “到第二步”数据的准确性并不是客户端所关心的问题，每小时同步就足够了(他的话)。

那么，我的问题当然是，如果有人可以提供信息，如果选择A或B(或另一个)在这种情况下，更重要的是，为什么？

请注意:我的目标是保持核心设置，客户端运行完整，应用程序或web服务器不能切换到另一个数据库引擎。

Answer 1

首先，关于备选案文A：

1. 如果只使用筛选器复制选定的表，并且即使要复制所有的表，那么bin-log的大小不会影响性能--这通常也不是问题。为了比较，我们在实时加载(电信)的数据中心之间复制了20 we (以及更多)。
2. 保持源代码和目标服务器的版本相同--即使您选择了变体B，也是很好的实践--它避免了许多其他问题

关于变体B-我个人寻找的工具，类似的pt表同步，作为优秀的，但偶尔工具，在您的工具箱，而不是永久的解决方案。我无法解释缺点，这只是个人的眼光。

变体C:类似于- SymmetricDS的工具

变体D:我现在亲自使用CDC变体，当您解析bin-日志并通过消息队列将它们发送到订阅者时。

我已经在加载至少两个工作解决方案下进行了测试(目前确实更多)：

1. StreamSets
2. 麦克斯韦 + 塔伦德
3. 出于一些原因，非常有趣-- MariaDB MaxScale，但是没有时间让它工作。

我个人喜欢这个是因为：

1. 有很多集成项目
2. 并不总是来源和目标系统相同。最不满的是我的例子- MySQL to Redshift，DB2
3. 它还允许在特定数据更改时实现“基于事件的”集成-火子作业。
4. 同一个生产者有超过一个订阅者。

编辑以便在

注释中添加问题答案

奖牌的问题有两个(甚至更多)方面：

1. 二进制日志的大小-这是客观的，但与良好的网络，它不是一个问题。为了使运输更快，可以启用压缩- 查看更多信息。
2. 时间奴隶需要什么应用所有的改变从大师。即使您启用了多线程从机，它仍然比主线程慢，而且默认情况下，单线程也可能会出现大量更改的问题。

但是，正如我所写的，您可以在从服务器端启用筛选器，以减少受监视对象的数量-- 复制表和Slave将忽略所有其他更改，只适用于此表(更宽的筛选器- 复制-do-db)，您可以对多个表重复此设置，或使用通配符。

滤波逻辑图

任何解决方案的优缺点，我将更喜欢复制，因为它将应用更新“动态”，但不只是在我运行外部程序。