0

我们在 EC2 上使用 Percona mysql，并为 HA 设置了主/从设置。我们观察到，随着我们不断地在主服务器中写入数据，到从服务器的复制总是在数小时甚至数天后落后，因为这是我们应用程序的本质。

这里可能有什么问题？

4

1 回答 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 回答