【问题标题】:When is the timestamp set in MySQL binlogsMySQL binlogs 中设置的时间戳是什么时候
【发布时间】:2017-12-04 10:55:27
【问题描述】:

我已经搜索过以前的问题,但找不到与我的问题完全匹配的问题:

在查询事务期间的什么时候设置二进制日志时间戳,然后写入二进制日志?

上下文:我一直在使用使用主/从复制的数据库。很多时候,从服务器会落后于主服务器,我敢肯定这仅仅是因为二进制日志中有很多事务共享相同的时间戳。当我说很多时,我指的是 1 小时日志中属于 9000 多个条目的 150 多个时间戳(加上返回的 9000 个条目以下的其余部分)。这是通过以下方式找到的:

mysqlbinlog bin-log.0001 | grep 'TIMESTAMP' | uniq -c | awk '{if ($1>9000){print $0}} ' | sed -e 's/\/\*\!\*\/;//g' | gawk -F '=' '{cmd="date -d @"$2; cmd | getline d; print $1"="$2"\t("d")"; close(d)}'

所以我基本上是在尝试测试共享时间戳的事务数量是否反映了主服务器上的工作量,以及这些数字是否异常。

绘制 Second_behind_master 时,它显示线性增长,然后突然下降,这似乎暗示了同样的事情。

MySQL 版本为 5.6.33。

【问题讨论】:

    标签: mysql binary-log


    【解决方案1】:

    “从属滞后”有多种可能的原因,在这里很难详细回答。二进制日志时间戳是在事务开始时写入的。

    这里有一篇有用的帖子介绍了如何确定症状的原因:https://www.percona.com/blog/2014/05/02/how-to-identify-and-cure-mysql-replication-slave-lag/ 例如,它解释了 Seconds_Behind_Master 参数如何误导,因为它只测量中继日志的时间戳之间的差异最近执行的,与最近由 IO_THREAD 下载的中继日志条目相比。

    您会在该网站上找到许多其他可能对您有所帮助的资源。这包括博文中提到的 Percona Toolkit,它与所有 Percona 软件一样完全免费且开源。

    披露:我为 Percona 工作。

    【讨论】:

    • 所以看起来主服务器上同时启动了大量事务。我想您在通过转储备份将数据导入主服务器时会期望这种行为,因为它会尽快通过转储文件爆炸?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-02-25
    • 1970-01-01
    • 2015-12-06
    • 2017-01-28
    • 2021-07-28
    相关资源
    最近更新 更多