pg主从修复
2016-01-06 15:03
260 查看
今天早上收到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进程更直接能看到恢复的进度。
登陆从库查看日志:
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/
相关文章推荐
- MySQL主从的一致性校验及修复 推荐
- pg 修复
- mysql生产环境___主从同步修复案例
- 使用pt-online-schema-change 修复主从数据表数据不一致
- mysql 主从同步出问题,重新修复从库(转)
- MySQL主从复制报错处理和数据一致性校验及修复方法
- pt-table-checksum检查主从数据一致性,及修复主从数据完整性
- MySQL主从服务器数据一致性的核对与修复
- mysql行模式(ROW)主从同步测试及错误修复
- MySQL中主从复制重复键问题修复方法
- MySQL GTID 主从复制错误修复方法
- percona-toolkit之pt-table-sync修复Mysql主从数据一致性
- shell脚本监控mysql主从同步状态并自动修复
- 主从数据一致性检查修复工具pt-table-checksum,pt-table-sync使用
- MySQL 主从同步失败,数据表修复
- 主从GTID复制修复
- MySQL主从故障修复
- 用pt-table-sync修复主从数据不同
- 利用percona-toolkit工具检查MySQL数据库主从一致性并修复
- pt-table-checksum MySQL主从服务器数据一致性的核对与修复