我们在 EC2 上使用 Percona mysql，并为 HA 设置了主/从设置。我们观察到，当我们不断在主服务器中写入数据时，到从服务器的复制总是会落后几个小时甚至几天，因为这是我们应用程序的本质。
这里可能有什么问题？
最佳答案
首先，考虑一下 MySQL Replication 是如何组织的
MySQL 复制的主要组件
从属 IO 线程:它负责维护与主设备的持续连接。已准备好从Master的binlog接收binlogs事件并收集它们FIFO从站中继日志中的样式。
Slave SQL Thread:负责读取中继日志中存储的binlog事件。事件(DML、DDL 等)在此内部线程上执行。
Seconds_Behind_Master:每个binlog事件都有该事件的时间戳(DML、DDL等)。Seconds_Behind_Master就是 NOW()从服务器的时间戳减去事件的时间戳。Seconds_Behind_Master显示在SHOW SLAVE STATUS\G中。
问题是什么？
如果Seconds_Behind_Master不断增加，请考虑以下因素:MySQL Replication的binlog事件的单线程执行路径只不过是在Master上执行的所有SQL命令的序列化平行线。想象一下:如果在 Master 上并行执行 10 个 UPDATE 命令并且每个命令需要 1 秒来处理，它们将被放置在中继日志中并执行 FIFO风格。所有更新都有相同的时间戳。减去从属设备上处理的每个更新的时间戳会导致 Seconds_Behind_Master 增加 1 秒。乘以 10，您将获得额外 10 秒的复制延迟。这表明 SQL 线程是一个瓶颈。
建议
- 主站和从站可能规范不足。也许更多的内存和/或核心，以便从站可以更快地处理二进制日志事件。 (扩大规模，最好是稍微线性改进)
- Try configuring InnoDB for accessing more cores
- 切换到 MySQL 5.6 和 implement parallel slave threads (如果您有多个数据库)
- 等待 Percona 5.6，然后升级并实现并行从属线程(如果您有多个数据库)
关于mysql - 如果我们在master上连续进行大量写操作，Mysql复制会失败吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17304355/