Greenplum备份恢复浅析 姓名：张文杰 邮箱：zhuodao.zwj@alibaba-inc.com 公司：阿里云 2017 年象行中国（杭州 站）第一期 Greenplum数据备份恢复： 1. 数据量较大 2. 不能完全使用Xlog日志备份 3. 需要保证数据完整性和一致性 2017 年象行中国（杭州 站）第一期 Greenplum提供了： 1. 非并行备份和恢复： --pg_ --pg_dump和pg_dumpall（pg_restore） --copy、psql 2. 并行备份和恢复 --gpcrondump（gpdbrestore） 2017 年象行中国（杭州 站）第一期 并⾏备份和恢复 gpcrondump gpdbrestore 2017 年象行中国（杭州 站）第一期 gpcrondump⽤法(1/3) gpcrondump -x database_name xxx_gp_dump_0_2_20170206160253.gz 其中XXX表示用户定义的文件前缀，0代表是非master节点，2代表该文件产生的 segment对应dbid，20170206160253是前面所说的时间戳。在恢复时，会根据这 个命名规则，找到对应的文件。 2017 年象行中国（杭州 站）第一期 gpcrondump具体实现(1/2) 2017 年象行中国（杭州 站）第一期 gpcrondump具体实现(2/2)

............................................................................ - 15 - Instance 故障切换与恢复 .................................................................................... - 17 - Master .......................... - 309 - 6 版本故障切换的恢复过程 .................................................................................. - 311 - 6 之前版本故障切换的恢复过程 .......................................... ................ - 317 - 恢复 Instance ............................................................................................................. - 317 - 主机健康时从 Mirror 恢复 ..........................

©2022 VMware, Inc. 8 Greenplum的高可用 Ø 数据存两份，Coordinator有standby Ø 自动同步数据 (WAL replication) Ø 自动灾难恢复 (FTS，主备切换) Confidential │ ©2022 VMware, Inc. 9 分布式优化器：OLAP Ø OLTP系统的SQL语句相对简单（CURD） Ø OLAP系统的

数据库管理系统组成图 Hector Garcia-Molina /Jeffrey D.Ullman/Jennifer Widom《数据库系统实现》 查询编译器/ 优化器 事务管理器 DDL编译器 执行引擎 日志和恢复 并发控制 索引/文件/ 记录管理器 缓冲区管理器 缓冲区 锁表 存储管理器 存储 查询计划 对索引、文件和 记录的请求 页命令 事务命令 查询、更新 用户/ 应用 DDL命令 保证原子性， 先把Undo Log写入日志文件。Undo Log记录修改数据对象的旧值(Before Image, BFIM) Solution: Logging 15 缓冲区管理策略和事务恢复的关系 Force No-Force Steal Undo / No-Redo Undo + Redo (performance: fastest recovery: slowest) Undo log(记录旧值) (Steal / Force) 恢复时，从后往前，对于未提 交的事务的日志做undo操 作。 日志 Redo log(记录新值) (No-Steal / No-Force) 恢复时，从前往后，对提交的事务 的日志做redo操作。 日志

gp-seg3 Primary segment Primary segment Mirror segment mirror segment standby master gp-seg4X 手动宕机恢复过程 （恢复segment） 2018年PostgreSQL中国技术大会 2018年PostgreSQL中国技术大会 2018年PostgreSQL中国技术大会 2018年PostgreSQL中国技术大会 2018年PostgreSQL中国技术大会 2018年PostgreSQL中国技术大会 gprecoverseg -r 2018年PostgreSQL中国技术大会 Standby master自动恢复 2018年PostgreSQL中国技术大会 删除文件恢复过程 2018年PostgreSQL中国技术大会 微信号：laohouzi999 Primary segment（gpseg6删除部分文件） Primary segment（gpseg7删除目录） 2018年PostgreSQL中国技术大会 开始执行恢复 2018年PostgreSQL中国技术大会 2018年PostgreSQL中国技术大会 2018年PostgreSQL中国技术大会 2018年PostgreSQL中国技术大会 2018年PostgreSQL中国技术大会 2018年PostgreSQL中国技术大会 2018年PostgreSQL中国技术大会 Standby master的恢复过程 2018年PostgreSQL中国技术大会

• 数据备份恢复 运行模式 GPDB的数据安全 用户 • 连接数据库 • 运行业务 DBA • 管理数据库 • 业务审计 System Admin • 管理集群 • 数据备份恢复 管理模式 GPDB的数据安全 用户 • 连接数据库 • 运行业务 DBA • 管理数据库 • 业务审计 System Admin • 管理集群 • 数据备份恢复 管理模式 GPDB的数据安全 System Admin • 管理集群 • 数据备份恢复 GPDB为单独数据库软件 • 非一体机 • 缺少对硬件和系统的控制 潜在风险（一） GPDB的数据安全 System Admin • 管理集群 • 数据备份恢复 需要登录到系统进行运维 • 可以访问数据库二进制文件 • 可以访问数据库数据文件 • 可以访问预写日志文件 潜在风险（二） GPDB的数据安全 GPDB的数据安全 System Admin • 管理集群 • 数据备份恢复 运维模式 • 原厂服务，主机厂或者第三方运维 数据文件为明文二进制文件 • 直接通过Linux自带工具（strings, hexdump）访问 • pg_waldump可以直接读取并显示预写日志 潜在风险（三） GPDB的数据安全 数据需要加密 • 机密数据 • 知识产权保护 • 审计要求 用户数据存在直接暴露的风险

Instance) – preferred_role：实例原本应作为primary还是mirror运行 – role：实例目前作为primary或者mirror在运行  查看实例宕机历史和恢复历史信息  select * from gp_configuration_history order by 1 ;  查看Tablespace对应的文件系统位置 select 目录  Greenplum运维常见问题  Greenplum运维常用命令  Greenplum日常检查和故障处理  Greenplum项目经验分享 个性化备份恢复 备份恢复命令  备份文件gz压缩  按表备份 – 每个表每个实例备单个文件  将分区表分别备成单独文件  缺省备份目录在db_dumps下建立日期路径，与缺省备份一致；也可指定备份路径  乐观锁设计——单表尝试加锁失败即认为该表本次备份失败  命令简单易用——单命令无需部署，参数基本保持与gpcrondump一致，自劢完成全部必要的准备工作  恢复可选表清单，可指定条件恢复部分数据，可恢复到指定增备日期 Greenplum集群之间数据传输 Transfer命令  基于gpfdist和外部表实现，比基于命名管道的gptransfer更稳定高效

库仍然可以继续工作。但由于segment的primary与 mirror端的数据不同步了，所以恢复的时候需要花比较 长的时间。对于Greenplum 3.X的版本，恢复时，需要 把好的节点上的所有数据都copy到坏的机器上。而 Greenplum4.0版本增加了功能，当备份节点坏的时 候，主节点可以把增量数据记下来，这样当备份节点的 主机恢复时，只需要恢复增量数据就可以了。 要让原先已offline的节点再加入集群中，需要重启集 的primary与 mirror之间是做的逻辑同步，mirror端的数据库实际上 也是可以读写的。而Greenplum4.0版本后，primary与 mirror实际上是物理同步，这时mirror一直处于恢复状 态，不能读也不能写。 高可用之Master Mirroring 对于Greenplum Master的primary与mirror之间的同步 就是使用PostgreSQL的日志同步方案。master的

功能设计的方方 面面： 外部表数据加载是并行的、 查询计划执行是并行的、索 引的建立和使用是并行的， 统计信息收集是并行的、表 关联（包括其中的重分布或 广播及关联计算）是并行的，排序和分组聚合都是并行的，备份恢复 也是并行的，甚而数据库启停和元数据检查等维护工具也按照并行方 式来设计。得益于这种无所不在的并行，Greenplum 在数据加载和数 据计算中表现出强悍的性能，某行业客户对此深有体会 : 同样 2TB 开放性的特性给客户带来的好处，不只是硬件厂商和型号的选择范围， 也包含工程实施过程的便利性。2014 年，该客户大数据平台需要进行 数据搬迁，Greenplum 采用了旧环境数据备份、传输、新环境恢复的 方案，停机时间实际只花了不到 4 天。 相比较而言，其他封闭式系统，需要压缩并备份数据，倒腾出整套设 备搬迁到新数据中心，然后再导入新数据，影响或暂停业务几十天。 两种方案从工程复杂度、人力投入、业务影响来说，开放式架构所带 实例与 mirror 实例之间实现同步的重要参考数据。 在 Greenplum 集群出现故障时，会有可能导致系统表数据有问题。 系统表出现问题会导致很多种故障产生，如：某些数据库对象不可 用，实例恢复不成功，实例启动不成功等。针对系统表相关的问题， 我们应该结合各个实例的日志信息，系统表的检查结果一起定位问 题，本文将介绍一些定位、分析及解决问题的方法和技巧。 1. 检查工具 Greenplum

容器化Greenplum部署策略 ○ Master部署策略 ○ Primary Segment部署策略 ○ Mirror Segment部署策略 ● 容器化Greenplum运维管理 ○ 故障检测及恢复 ○ 升级扩容 ● 容器化Greenplum存储管理 ○ 容器本地存储易失性 容器化Greenplum ● 容器粒度 ○ Segment主机 VS. Segment实例 ● 容器资源分配 容器化Greenplum部署策略 ○ Master部署策略 ○ Primary Segment部署策略 ○ Mirror Segment部署策略 ● 容器化Greenplum运维管理 ○ 故障检测及恢复 ○ 升级扩容 ● 容器化Greenplum存储管理 ○ 容器本地存储易失性 ○ 容器外部存储关联性 容器化分布式应用程序公共问题 容器网络管理 容器资源管理 容器镜像管理 容器调度 容器化Greenplum部署策略 ○ Master部署策略 ○ Primary Segment部署策略 ○ Mirror Segment部署策略 ● 容器化Greenplum运维管理 ○ 故障检测及恢复 ○ 升级扩容 ● 容器化Greenplum存储管理 ○ 容器本地存储易失性 ○ 容器外部存储关联性 Kubernetes 容器网络管理 容器资源管理 容器镜像管理 容器调度 容器监控及自