注册 登录
  • 欢迎访问"运维那点事",推荐使用Google浏览器访问,可以扫码关注本站的"微信公众号"。
  • 如果您觉得本站对你有帮助,那么可以扫码捐助以帮助本站更好地发展。

GH-OST:分析输出信息

MySQL Tools 彭东稳 754次浏览 已收录 0个评论

了解GH-OST输出

GH-OST会尽量让你知道自己在做什么,会输出一些关键详细信息,让你了解整个迁移过程。当然,你可以控制输出级别。

–verbose:常用,有用的输出,而不是一切。

–debug:输出所有一切。

当开始执行GH-OST时,初始输出行可能如下所示:

这些信息是GH-OST相对自我解释,他们大多表示一切顺利。你将主要关注迁移并了解其是否顺利进行。一旦迁移实际开始,你将看到如下输出。

在上面的一段时间主要花在了统计表格行上,可以看到第一次行输出Time: 29s表示在实际的行复制开始之前已经过了29s。另外,GH-OST在复制行完成1%之前是不会提供ETA信息。

在上述迁移中有时会受到节流(throttled)处理。

  • 检测到副本复制有延迟时会触发节流,延迟时间可自定义,支持毫秒。
  • 检测到max-load超过定义的值(Threads_running=26 >= 25)。

Progress

Copy: 595700/752865 79.1%,指复制到gh-ost表上的现有表行数,以及百分比。

Applied: 0,指在二进制日志中处理的SQL条目数量,并将其应用到gh-ost表上。在上面的例子中,迁移表没有流量,因此没有被处理SQL条目。

在密集使用的表上迁移,输出信息可能如下所示:

关键信息说明:

Applied: 381910,显示自迁移开始以来gh-ost表应用(Applied)binlog event语句的数量,由于是ROW格式,一个event中会有多个SQL语句。这里就是统计所有SQL语句的累积值。

Backlog: 0/1000,表示我们在读取二进制日志方面表现良好,在二进制日志队列中没有任何积压(Backlog)事件。

Backlog: 7/1000,当复制行时,在二进制日志中积压了一些事件,并且需要应用。

Backlog: 1000/1000,表示我们的1000个事件的缓冲区已满(程序写死的1000个事件缓冲区,低版本是100个),此时就可能需要暂停binlog读取,需要优先应用缓冲区的事件。

Copy: 31291200/43138418, Copy: 31389700/43138432,此迁移使用–exact-rowcount执行, gh-ost在迁移过程中不断地更新预期行副本的总数,因此从43138418变为43138432。

streamer: mysql-bin.006793:179473435,告诉我们此时哪个二进制日志条目是gh-ost正在处理的。

状态提示

此外,每10分钟打印一次友好提醒,格式如下:

以上大多打印出当前配置。请记住,你可以动态控制其中的大部分。

GH-OST注意到通过打印postpone-cut-over-flag-file文件实际存在延迟切割标志[set]。


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (1)or分享 (0)
关于作者:

您必须 登录 才能发表评论!