人大金仓分析型数据库系统缩容（一）

目录

缩容概述

---

        随着用户业务的变化，有时需要对集群进行缩容。比如集群的一部分业务被迁出，负载降低，出现较大冗余。 此时，可以考虑通过缩容从系统删除一部分主机，节省资源，但要确保剩余主机可以满足业务负载。与要求大量停机时间来转储和恢复数据的数据仓库系统不同， 数据库系统支持在线缩容。在数据被重新分布时，管理员可以安排分布活动以适合正在进行的操作并且可以按需暂停和继续。

缩容概述

        当用户对数据库缩容时，会期待如下特性：

• 缩容期间不中断服务。常规负载不会被中断
• 事务一致性
• 容错。在缩容期间，标准的容错机制 保持活动、一致并且有效
• 复制和灾难恢复。在缩容期间，任何现有的复制机制都继续发挥作用。在失败或者灾难事件中需要的恢复机制也保持有效
• 处理透明。缩容处理利用了标准的 数据库机制，因此管理员能够诊断并且排查任何问题
• 可配置的处理。缩容可能会是一个长时间运行的处理，但它可以变成按计划执行的一系列操作。缩容Schema 的表允许管理员指定表被重新分布的优先级，而且缩容活动可以被暂停并且继续

         数据库缩容处理的软件阶段被设计为尽量少被打断、事务一致、可靠并且灵活。

• 缩容过程阶段的第一步是准备 数据库系统：标记要缩容的节点。主要执行以下任务： 

1. 缩容合法性检查
2. 连接数据库标记要缩容的节点实例
3. gpshrink schema 在 postgres 数据库里被创建。 可以使用 schema 里的表和视图来监控和管理缩容
4. 现有数据会发生倾斜。 它们集中在原节点上并且需要根据新节点总量做重分布

• 缩容过程阶段的第二步是重新分布表数据。使用 gpshrink schema 中的缩容控制表作为指导，重新分配表。 对每一个表： 

1.  gpshrink工具基于分布策略在所有剩余机器上重新分布表数据
2. 缩容控制表中的表状态会被更新
3. 在数据重分布之后，查询优化器会基于不倾斜的数据创建更高效的查询计划

        扩容过程阶段的最后一步就是清理数据： 

1. 更新节点实例的元信息
2. 停止已缩容的节点并删除其数据目录
3. 删除gpshrink schema 

         gprestore工具不能恢复在缩容之前使用gpbackup工具备份的数据。所以在缩容完成之后立即备份你的数据。重新分布数据是一个长时间运行的处理，它会创建大量的网络和磁盘活动。 可 能需要数天时间来重新分布某些非常大型的数据库。 为了最小化这些活动对业务操作的影响，系统管理员可以随意或者根据一个预定好的计划暂停并且继续缩容活动。 数据集也可以被定义优先级，这样关键的应用可以从缩容中首先获益。 

        在完整的缩容处理过程中，用户需要用不同的选项运行gpshrink工具四次。

• 创建缩容输入文件：

gpshrink -f hosts_file

•  标记要缩容的节点实例并且创建缩容schema：

gpshrink -i input_file

         gpshrink连接数据库设置缩容标记、为缩容方案中的每个表捕捉元数据用于状态跟踪。 在这个处理完成后，缩容操作会被提交并且不可撤回。

• 重新分布表数据： 

gpshrink -d duration

         在初始化时，gpshrink标记缩容节点。 必须运行gpshrink在剩余节点实例上重分布数据来完成系统缩容。 取决于系统的大小和规模，重新分布可能在一个单一会话中经过数个利用率较低的小时才会完成，或者用户可以把该处理划分成一个长时段上的批处理。 每个表或分区在缩容期间是无法进行读写操作的。 由于每一个表都会被重新分布在剩余的Segment上，数据库性能可能 会逐步降低直到低于缩容前的性能水平。在需要多个重新分布会话的大型系统中，可能需要多次运行gpshrink来完成缩容。

•  更新节点实例的元信息并移除缩容schema：

gpshrink -c