greenplum集群操作指令及解决方法
gp集群如何部署就不过多介绍，主要是结合一下工作中要用到的指令和遇到的一些坑
操作规范
gp集群的所有操作都是由master节点进行的,由master机器ssh到其他节点上进行自动化操作
安装部署gp集群时已经给master角色机器和standby角色机器添加了gpadmin用户.bashrc脚本
1 | echo """ |
必须在gpadmin用户下进行,登录master机器后需要切换到gpadmin用户下
su – gpadmin
下面的所有操作都是在gpadmin用户下的操作
常用命令
恢复mirror segment (primary复制到mirror)
1 | gprecoverseg -qo ./recov |
恢复到原来初始化时的角色设置
1 | gprecoverseg -r |
恢复primary segment (mirror复制到primary)
快速恢复镜像，可以多次执行，让集群中的mirror端口7000的数据同步到primary端口6000，可以用于segment节点宕机后重新启动，期间可能修复失败，多次执行修复即可。
1 | gprecoverseg -av #不会创建primary数据目录 |
强制恢复
1 | gprecoverseg -Fav #会创建primary数据目录，（相当于把mirror的整个文件目录给复制到primary目录） |
启动master节点和segment
1 | gpstart -a |
显示具有镜像状态问题的片段，如果集群正常则显示为running，可用于健康检查
1 | gpstate -e |
查看端口分配情况
1 | gpstate -p |
查看集群中的角色
1 | gpstate -b |
显示主镜像mirror映射
1 | gpstate -c |
显示镜像实例同步状态
1 | gpstate -m |
停止所有实例，然后重启系统
1 | gpstop -M fast -ar |
停止集群，包含master和segment
1 | gpstop -a |
激活standby为master，在standby机器上执行
1 | gpactivatestandby -a |
Master角色故障转移
问题场景：
Master机器故障
修复方法：
master机器故障时，无法自动故障转移，需要将standby机器升级为master角色，原有的master机器会被踢出集群master角色，此时集群中只有master角色(standby机器)，没有standby角色。
操作命令:
1 | 登录standby机器 |
要想master机器重新成为master角色，需要移除master机器的MASTER_DATA_DIRECTORY目录数据(rm -rf $MASTER_DATA_DIRECTORY)或者备份，然后在standby机器上操作命令：gpinitstandby -s master机器； 让master机器重新以standby角色加入集群：
操作命令:
1 | 登录master机器 |
操作完成后，master机器就是集群中的standby角色; 经过gpstate -b确认master机器成为了集群的standby角色，然后停止standby机器(pg_ctl stop -D $MASTER_DATA_DIRECTORY)，在master机器上执行gpactivatestandby -a命令，抢夺standby机器的master角色并踢出集群，当master机器重新成为master角色后，再移除standby机器的$MASTER_DATA_DIRECTORY目录数据
然后再master机器上执行命令：gpinitstandby -s standby机器。让其成为standby角色。
操作命令:
1 | 登录standby机器 |
Segment角色故障修复
问题场景
segment节点机器重启
修复方法：
gp集群自带segment故障转移，故障segment节点的primary业务转移其对应的mirror业务上（一般是其他的segment节点上），此时不影响集群运行。
gp提供了segment节点修复工具gprecoverseg
当整个集群正常状态下，primary提供数据读写，mirror提供备份功能，当primary异常时，mirror接替primary的工作。使用命令gpstate -c命令进行查看
例如：
1 | Status Data State Primary Datadir Port Mirror Datadir Port |
方法1：
如果发现上面的DataState不是Synchronized，可以执行自动修复命令gprecoverseg，这条命令会检测集群的运行情况，如果segment节点的服务未启动也会进行启动
操作命令:
1 | 登录master机器 |
方法2：:
查询集群中的问题节点，进行修复
操作命令:
1 | 登录master机器 |
集群无法启动
如果在执行gpstart -a时集群时，因为segment的数据目录问题导致无法启动整个集群
那么就只启动master的维护模式
1 | gpstart -m |
可以支持gpstate的命令查询，可以查询对应的primary和mirror目录（Mirror segment采用物理文件复制的方案—primary segment中数据文件I / O被复制到mirror segment上，因此mirror segment的文件与primary segment上的文件相同）
使用scp命令进行文件一致
备份segment节点上的文件夹，例如
将mirror的数据目录完整发送到primary的目录，要复制整个文件夹，不要创建目标文件夹后复制文件，不然会提示文件类型无法识别（postgresql的数据目录检测机制）
1 | mv /data/primary/gpseg2 /data/primary/gpseg2-bak |
为primary master和standby master配置一个虚拟IP地址
可以利用keepalived产生一个VIP，利用keepalived的检测进行权重增减，实现VIP漂移
备份还原
- Greenplum早期通过使用PG数据库的备份工具实现备份。但随着数据量不断增大，基于PG备份工具的串行备份模式无法满足用户对备份时效的需求。
- Greenplum开始了第二代备份工具gp_dump的研发，并在2005年左右正式发布，gp_dump通过引入并行备份解决了串行备份时效低的问题，但使用上相对比较复杂。
- 为了进一步的完善了用户使用体验，官方基于gp_dump，开发了gpcrodump备份工具。gpcrodump非常的成功，推出以来，为用户服务了10多年，当前还有大量的用户在用（GPDB 4.22以前的版本建议的备份工具）。
但gpcrodump有一个非常大的限制，就是备份时长时间锁表，因此需要用户预留相应的时间窗口。随着用户数据量的持续提升，以及HTAP混合负载应用的需求，企业对在线联机备份（备份时不需要中断业务）的需求愈发强烈。 - 因此大概2015年，Pivotal开始研究新一代的备份工具，并在2017年正式发布，这就是新一代备份工具gpbackup。
gpbackup消除了锁表（专有锁）机制，同时，创新性的把GP的原有的外部表技术（一种高效的大规模并行数据加载和卸载技术）引入，用户无需为备份预留单独的时间窗口，同时扩展了备份存储的支持，
当前可用使用本地文件系统、Dell Data Domain、NBU、以及分布式存储，也可用使用公有云对象存储（S3），同时还支持用户自定义备份的存储接口。
完整全量备份：
1 | gpbackup --dbname wyf --backup-dir /data/backup --leaf-partition-data |
创建增量备份,增量备份要确保之前的备份不呢丢失，不然无法还原：
1 | gpbackup --dbname wyf --backup-dir /data/backup --leaf-partition-data --incremental |
基于某个备份做增量备份，–from-timestamp 后面跟的是已经存在的备份时间戳（例如：/data/backup/gpseg-1/backups/备份日期/下查看）
1 | gpbackup --dbname wyf --backup-dir /mybackup --leaf-partition-data --incremental --from-timestamp 20210909145418 |
恢复（不创建库）
1 | gprestore --backup-dir /data/backup --timestamp 20210909152128 |
恢复（创建库）
1 | gprestore --backup-dir /data/backup --create-db --timestamp 20210909152128 |
wechat
alipay
