GPDB · 特性分析· Greenplum 备份架构

Greenplum是分布式数据库，这为备份带来了一些困难。其本身提供了一个工具是gpcrondump，对其二进制备份工具gp_dump做了一些封装，而gp_dump则是对pg_dump做了封装，在每个节点上执行pg_dump完成数据的备份。在其每个节点的行为上，与PG类似，但其分布式的架构，则有值得了解的地方。 ## 备份方法 GP备份的工具gpcrondump是一个Python脚本，是对gp_dump的一个封装。而gp_dump则负责整个备份过程的控制与结果处理，包括获取元数据信息、启动Segment节点备份、状态维护等动作。 ## gpcrondump gpcrondump的详细参数： ~~~ gpcrondump -x database_name [-s <schema> | -S <schema> | -t <schema>.<table> | -T <schema>.<table>] [--table-file=<filename> | --exclude-table-file=<filename>] [--schema-file=<filename> | --exclude-schema-file=<filename>] [-u backup_directory] [-R post_dump_script] [--incremental] [ -K <timestamp> [--list-backup-files] ] [--prefix <prefix_string> [--list-filter-tables] ] [-c] [-z] [-r] [-f <free_space_percent>] [-b] [-h] [-j | -k] [-g] [-G] [-C] [-d <master_data_directory>] [-B <parallel_processes>] [-a] [-q] [-y <reportfile>] [-l <logfile_directory>] [--email-file <path_to_file> ] [-v] { [-E encoding] [--inserts | --column-inserts] [--oids] [--no-owner | --use-set-session-authorization] [--no-privileges] [--rsyncable] { [--ddboost [--replicate --max-streams <max_IO_streams> [--ddboost-skip-ping] ] ] } | { [--netbackup-service-host <netbackup_server> --netbackup-policy <netbackup_policy> --netbackup-schedule <netbackup_schedule> [--netbackup-block-size <size> ] [--netbackup-keyword <keyword> ] } } ... ~~~ 更多参数请参考[官方文档](http://gpdb.docs.pivotal.io/4320/utility_guide/admin_utilities/gpcrondump.html)，或者查看命令help。对于详细的使用方法，这里不再讨论。 gpcrondump以DB为单位进行备份，当一次收到多个DB的备份请求时，则每个DB顺序依次进行备份。针对每个DB，gpcrondump会做一些预处理后，组织一个完整的gp_dump执行命令后执行。最基本的gp_dump命令如下： ~~~ "gp_dump -p %d -U %s --gp-d=%s --gp-r=%s --gp-s=p --gp-k=%s --no-lock" % (self.master_port, user_name, dump_path, report_path, timestamp_key) ~~~ gpcrondump不同的参数带来不同的gp_dump命令，比如“–table-file”等。 ## gp_dump gp_dump是真正进行数据备份的主体。其操作的主要步骤如下： 1. 参数、数据对象的处理 除了对参数处理以外，这里的行为与pg_dump相似，会对需要导出的数据对象、依赖关系等进行处理。 2. 连接Master，获取元数据信息 从这里，获取每个Segment的信息，包括主机、端口、角色等。 3. 根据元数据连接到各个Segment和Master 根据第一步获取的Segment信息，获取角色为’p’的Segment和Master，保证连到的是活跃的节点。针对每个Segment或Master，会单独启动一个线程进行连接。 在连接到节点后，会创建消息通知机制。通过不同的消息通知，对该节点的备份情况进行及时响应，并对整体的备份及时做出调整，如取消等。 之后，将gpcrondump组织的参数，组织成gp_backup_launch函数的入参，调用执行。 4. 之后调用gp_backup_launch函数，在Segment端启动一个Agent进程 根据参数的不同，gp_backup_launch函数会启动不同的独立Agent进程。默认的是gp_dump_agent，这个Agent会封装pg_dump。GP也支持备份到Data Domain Boost等外部存储，即在独立的Agent进程中调用不同的agent工具。 gp_backup_launch函数会等待gp_dump_agent执行结束后返回结果。 5. 每个Segment端启动的Agent进程会再次连接到自身 Agent的实现与PG的pg_dump基本类似。不同的是，在参数处理之后，会将这个节点的隔离级别设置为串行。因此，多少会对备份期间的事务性能产生一定影响。而如果只是查询的话则影响不大。 pg_dump和gp_dump_agent的实现都是用COPY或者FETCH语句将表的数据导出。 6. 结果返回 在gp_dump_agent执行结束后，结果返回作为每个节点上gp_backup_launch函数的执行结果。 7. 节点连接线程维护状态机 gp_dump连接到每个节点的线程启动运行状态机，检查其他并行线程的状态、监听当前线程的通知，当任何一个出现失败，即取消备份 ## 时序图  ## 总结 GP备份的机制充分利用了每个节点的并行，可以极大的提高备份速度。一方面单个节点的数据量可以控制在一定范围，另一方面不同节点之间并行互不影响。 而在分布式中，比较麻烦的是保持多节点事务一致性和异常情况的处理。其中事务一致性是通过在每个节点上开启事务并设置隔离级为串行做到；异常情况则是通过多线程之间通信和PG的消息通知来实现。 Hope you have fun.