pg主从修复

今天早上收到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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/20625855/viewspace-1972597/