我们在 EC2 上使用 Percona mysql，并为 HA 设置了主/从设置。我们观察到，随着我们不断地在主服务器中写入数据，到从服务器的复制总是在数小时甚至数天后落后，因为这是我们应用程序的本质。
这里可能有什么问题？
问问题
214 次
1 回答
1
首先，想想 MySQL Replication 是如何组织的
MySQL 复制的主要组件
Slave IO Thread：它负责保持与 Master 的持续连接。它准备好从 Master 的 binlogs 接收 binlogs 事件，并在 Slave 的中继日志中以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样式。所有更新都具有相同的时间戳。减去 Slave 上处理的每个 UPDATE 的时间戳会产生 1 秒的Seconds_Behind_Master. 乘以 10，您将获得 10 秒的复制延迟。这揭示了 SQL 线程是一个瓶颈。
建议
- Master 和 Slave 可能被低估了。也许更多的内存和/或核心，以便从站可以更快地处理二进制日志事件。（放大，最好是稍微线性的改进）
- 尝试配置 InnoDB 以访问更多内核
- 切换到 MySQL 5.6 并实现并行从线程（如果您有多个数据库）
- 等待 Percona 5.6，然后升级并实现并行从线程（如果你有多个数据库）
于 2013-06-25T20:44:11.053 回答