为什么LinkedIn放弃MySQL slowlog，转用基于网络层的慢查询分析器？ - 高可用架构 | 十条
考虑到性能问题，我们没有使用慢查询日志。 我们可以为查询时间设置一个阈值，然后将所有跨越阈值的查询记录在一个文件中，用于事后进行分析。 这种方法的缺点是它无法捕获所有的查询。 如果将阈值设置为 0 可以捕获所有查询，但实际是行不通的，数百万次查询记录进文件会导致海量 IO，并大大降低系统吞吐量。 所以使用慢查询日志是完全不行的。我们考虑的下一个选项是 MySQL Performance Schema，可以用来在低水平监控 MySQL 服务器运行状态（从MySQL 5.5.3开始提供）。 它提供了一种在运行时检查服务器的内部执行情况的方法。 然而，使用此方法的主要缺点是启用或禁用 performance_schema 需要重新启动数据库。您可以尝试启用 Performance Schema，然后关闭所有调用者，这会导致增加大约 8％ 的开销; 如果您启用所有的调用者，会增加大约 20-25％ 的开销。 分析 Performance Schema 也非常复杂，为了克服这个问题，MySQL 从 MySQL 5.7.7 版本引入了sys schema。 但是为了查看历史数据，我们仍然需要将数据从 Performance Schema 转储到其他服务器。
Read full article from 为什么LinkedIn放弃MySQL slowlog，转用基于网络层的慢查询分析器？ - 高可用架构 | 十条
No comments:
Post a Comment