所说的时间戳。在恢复时，会根据这个命名规则，找到对应的文件。 ## gpcrondump具体实现(1/2) Master segment gpcrondump.py segment gp_dump segment segment gp backup launch → gp dump agent gp_backup_launch → gp_dump_agent gp_backup_launch gpcrondump实际是对gp_dump的封装，具体步骤如下： 1. 读取参数，检测合理性 2. master执行对pg class加锁操作 3. 封装并执行 $ gp\_dump $ 命令 4. 检测每个segment备份状态 5. 其他操作，例如备份全局对象（角色和表空间）、备份config文件、清理旧备份集以及VACCUM等 ## gp_dump具体实现 ![Image](/

做恢复，数据库就和这个时间点的状态完全一样，因为，备份是在线的，为了尽可能的降低对业务的影响，不可能做到绝对的一致性保证，如果要这么做，会付出极大的代价。 在实现gpbackup之前，不管是gp_dump命令还是gpcrondump命令，都是先对所有业务表进行显式的LOCK，之后再进行并行数据COPY OUT，这是为了确保在备份期间，数据不会被其他事务修改，然而，即便如此，在逐个表LOCK期间， EXCLUSIVE锁，或者开启可重复读事务隔离级别，然而，如果这样做，注定会和其他任意的操作产生冲突。 并行系统的备份，总是要在可用性和一致性之间做出平衡，经过多年的摸索，终于有了gpbackup，相比之前的gp_dump或者gpcrondump，有了极大的改善，降低了锁级别的要求，同时，允许每个表备份为单独的文件，从而可以隔离单个表的备份失败。 ## 备份与恢复概述 GP支持并行备份恢复，同时，仍支持串行备 。可以参见如下参数来修改缺省行为： gp_create_table_random_default_distribution gp_default_storage_options 对于以前的gp_dump和gpcrondump并行备份出来的文件，如果确有必要，可以拷贝到Master上来串行恢复，当然恢复的方式不一定是pg_restore，可能是psql直接执行备份文件，对于压缩文件，也可以边解压