ITPub博客

首页 > 数据库 > 数据库开发技术 > pg主从修复

pg主从修复

原创 数据库开发技术 作者:hotdog04 时间:2016-01-06 15:03:27 0 删除 编辑
今天早上收到pg主从异常和延迟报警,赶紧登陆查看,发现确实断开了,
登陆从库查看日志:
2016-01-06 02:28:51.122 UTC,,,83039,,568c7be3.1445f,1,,2016-01-06 02:28:51 UTC,,0,LOG,00000,"started streaming WAL from primary at 318/34000000 on timeline 1",,,,,,,,,""
2016-01-06 02:28:51.122 UTC,,,83039,,568c7be3.1445f,2,,2016-01-06 02:28:51 UTC,,0,FATAL,XX000,"could not receive data from WAL stream: ERROR:  requested WAL segment 00000001000003180000000D has already been removed
",,,,,,,,,""
2016-01-06 02:28:56.131 UTC,,,83042,,568c7be8.14462,1,,2016-01-06 02:28:56 UTC,,0,LOG,00000,"started streaming WAL from primary at 318/34000000 on timeline 1",,,,,,,,,""
2016-01-06 02:28:56.132 UTC,,,83042,,568c7be8.14462,2,,2016-01-06 02:28:56 UTC,,0,FATAL,XX000,"could not receive data from WAL stream: ERROR:  requested WAL segment 00000001000003180000000D has already been removed


咨询业务早上确实做了大批量数据导入,再加上从库还在执行着备份原因清晰了:
大量数据导入和从库备份导致了大量的主从延迟,延迟的wal日志超过(wal_keep_segments=128)
造成了主库上的xlog目录被清理,从库需要的日志被清理掉了,最终复制中断。




问题清楚了,但是恢复过程却折腾好久,这也跟自己新用PG有关。
根据日志提示: 请求00000001000003180000000D的时候报错,那就从归档目录把这个文件之后归档目录的文件拷贝过去就行了,
拷贝过去应用了一段发现又不动了,日志报错:
2016-01-06 03:27:50.447 UTC,,,84642,,568c89b6.14aa2,1,,2016-01-06 03:27:50 UTC,,0,LOG,00000,"started streaming WAL from primary at 319/FC000000 on timeline 1",,,,,,,,,""
2016-01-06 03:27:50.447 UTC,,,84642,,568c89b6.14aa2,2,,2016-01-06 03:27:50 UTC,,0,FATAL,XX000,"could not receive data from WAL stream: ERROR:  requested WAL segment 00000001000003190000003F has already been removed


这个文件明明存在:00000001000003190000003F,却一直提示报错卡在这里。
文件损坏了?
两边(原端归档和目标端xlog)md5校验没有问题。
如果归档过程损坏了就悲剧了,近2T的库要重做。
尝试使用pg_xlogdump解析还是没异常。


正想着要把库给从做了,再做最后一次操作尝试:
把从库上报错位置的那个wal日志给drop掉了,
再看日志变化了:
提示报错的地方换成了上一个文件!
2016-01-06 03:27:50.447 UTC,,,84642,,568c89b6.14aa2,2,,2016-01-06 03:27:50 UTC,,0,FATAL,XX000,"could not receive data from WAL stream: ERROR:  requested WAL segment 00000001000003190000003E has already been removed


终于搞清楚了,原来日志提示的位置不是recoverying中的那个文件,而是replay后的最后那个文件


再次返回到主库的归档目录,原来自己在copy日志的时候忘了wal使用的是16进制命名的
0000000100000319*后面应该是000000010000031[A-F]* 拷贝的时候把这一段的日志文件给漏掉了。。
于是把它们再拷贝过去,终于正常恢复了。


PS:  直接ps看recovery进程更直接能看到恢复的进度。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/20625855/viewspace-1972597/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2013-03-11

  • 博文量
    59
  • 访问量
    404028