我们有一个postgresql数据库,它每晚都从cron作业中备份,命令如下:
su postgres -c "pg_dump our_database | gzip > /home/smb/shared/database_backup.bak.gz"
最近,我们有一个磁盘故障,开始与一些坏扇区,并在此期间pg_dump退出与以下错误
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: catalog is missing 17 attribute(s) from relid 20158
pd_dump: The command was: LOCK TABLE public.obvez IN ACCESS SHARE MODE
现在,因为它是在cron作业,没有人注意到错误消息,备份被中断,但它不是零大小,一切似乎都很好,错误被忽视,直到最后的磁盘故障时,我们意识到我们没有备份。
我们设法从旧备份中恢复数据,但现在我想知道检查pg_dump是否成功完成其工作的正确方法是什么?
2条答案
按热度按时间g6ll5ycj1#
我将结果写入日志文件,在cronjob结束时,我将日志文件的内容发送到我的电子邮件地址。那样的话,我就能知道什么时候出了问题。
附录:如果你想只在发生错误的时候发送邮件,你可以检查pg_dump的返回码:
zhte4eai2#
有些程序在类unix系统的管道中使用时表现不佳。例如,我使用的pg_dump通过gzip传输,如下所示:
破碎的脚本:错误条件从未发生
这使用检查前一个命令($?),但它不起作用。如果pg_dump由于任何原因失败,gzip不会返回任何错误响应。$?设置为0,表示成功。
幸运的是,还有更好的办法。在bash中,PIPESTATUS环境变量是一个数组,其中包含在最后一个管道中执行的所有命令的返回代码。检查整体返回状态和pg_dump的状态现在是这样完成的:
正确的脚本:单独检查pg_dump的结果
现在,我可以确定我的自动数据库备份不会悄无声息地失败。
从https://mattryall.net/blog/piped-exit-status