MySQL二进制日志限制

Question

我有一个在AWS上运行的MySQL实例，每秒大约有5000个插入。知道如果我使用binlog (行)和binlog裁剪器会对性能产生什么影响吗？

检查这个链接

据我所知，bin日志尾流定期轮询MySQL二进制日志，以使“实时”数据连接成为可能。binlog裁剪器在NodeJS中运行。

关键是，我必须使用MySQL，我想使用Meteor实时获取数据给我的客户。因此，我想要使用这个binlog裁剪器。

由于MySQL db将被非常密集地填充(每秒5000次插入)，所以我想知道binlog/binlog尾部在什么时候会出现严重的性能问题。

Grts，Tom

Answer 1

我已经开发了具有类似功能的软件，它能够使用MySQL复制流(二进制日志、二进制日志)捕捉几乎实时的事件，以响应数据库中的插入/更新/删除。

以下是我对性能的一些观察。幸运的是，潜在的热点在很大程度上相互独立。

我将假设，因为我不熟悉您引用的Node包，而且刚刚对他们的代码进行了粗略的检查，他们实际上不是通过轮询“跟踪”二进制日志，而是在模拟从服务器/副本服务器，连接到主服务器并请求复制流。

第一个潜在的瓶颈是主编写所需的Binlog数据量的能力(I/O吞吐量是主要的cobstraint)。如果您的主人已经以ROW格式登录，那么这个问题就已经解决了。如果没有，则切换Binlog格式，并查看。无论如何，我更喜欢ROW格式，因为当查询出错或者应用程序对它不应该拥有的数据做了一些事情时，它对于数据恢复非常有用。可以(使用第三方工具)捕获并逆转所发生的事情--在默认配置中，当删除发生时(例如)，删除的数据实际上被写入二进制日志。

下一个资源消耗点是由这样一个工具与主程序建立的从连接，在主服务器中主推送数据。一个常见的误解是奴隶“投票”主人。实际上，从服务器启动连接，但主服务器推送数据。这实际上是一个对主机的负载，当连接的奴隶数量很小(例如，5个或更少)时，它对性能的影响很小。可以通过配置log_slave_updates，而不是将"binlog跟踪器“连接到主服务器，而是连接到主服务器的现有从服务器，从而从主服务器完全消除此负载。

将数据从主站传输到伪从服务器可以占用大量的网络带宽，因此您的外部实用程序应该支持MySQL客户机/服务器压缩协议，以减少该带宽。根据有效载荷的不同，启用此功能可以达到10:1的压缩比。

最后的痛点是外部效用本身。MySQL Binlog格式是一种非常紧凑的二进制格式(因此是“二进制日志”)，必须对其进行解析和解码。外部实用程序解压缩和操作此数据流的效率将决定所检测到的事件能够发出多接近实时，因为低效率的代码将导致您决定的事件流越来越落后于主服务器，尽管这个因素不会对主服务器本身产生任何性能影响。

简而言之，如果您的主程序能够处理为您期望的流量生成行格式二进制日志的工作负载，那么其余的潜在问题仍然是潜在的问题，但是它们对主服务器本身不应该有任何有意义的性能影响。