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

        随着额外的数据被收集以及现有数据的保留时间增加，数据仓库会随着时间而增大。 有时，可能需要额外的计算能力（CPU）来适应新增加的分析项目。 尽管在系统被初 始定义时就留出增长的空间是最为明智的，但是通常不太可能在提前太多在资源上准备。 因此，用户应该定期地执行一次数据库扩容项目。在用户增加资源到系统时，得到的容量和性能就好像该系统一开始就用增加后的资源实现一样。 和要求大量停机时间来转储和恢复数据的数据仓库系统不同，扩容一个数据库系统是一种最小化停机时间的分阶段处理。 在数据被重新分布时，常规和特别负载可以继续并且事务一致性也能被维护。 管理员可以安排分布活动以适合正在进行的操作并且可以按需暂停 和继续。 表可以被排名，这样数据集可以以一种优先序列的方式被重新分布，从而确保关键性的负载能很快从扩容后的能力受益，或者释放所需的磁盘空间来重新分布非常大的表。

扩容概述

        通过增加节点实例和节点主机来扩容数据库，用户可以最小化停机时间。当用户扩容数据库时，会期待如下特性：

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

        在准备好新的硬件平台并且设置好它们的网络之后，配置它们的操作系统并且使用的工具运行性能测试。 数据库软件发布包括一些工具，这些工具有助于在开始扩容的软件阶段之前对新的服务器进行测试和拷贝。一旦新服务器被安装并且测试，数据库扩容处理的软件阶段就开始了。 

        扩容过程的第一步是准备数据库系统： 添加新节点的主机并初始化新的节点实例。 此阶段可以安排在低活动期间进行，以避免中断正在进行的业务运营。 在初始化过程中，执行以下任务：

• 数据库软件已被安装
• 在新的主机的新节点实例上创建了数据库和数据库对象
• gpexpand schema在postgres数据库里被创建。 可以使用schema里的表和视图来监控和管理扩容

        在系统被更新后，新节点主机上的新节点实例已经可以使用：

• 新节点立即生效并参与到新查询和数据加载里。 但是现有数据会发生倾斜。 它们集中在原节点上并且需要根据新节点总量做重分布
• 因为有些表的数据已经倾斜了，所以部分查询性能会下降，因为可能需要更多的Motion操作了

         最后一步就是重新分布表数据。 使用gpexpand schema中的扩容控制表作为指导，重新分配表。 对每一个表完成重分布，扩容也就完成：

• gpexand工具基于分布策略在所有新老机器上重新分布表数据
• 扩容控制表中的表状态会被更新
• 在数据重分布之后，查询优化器会基于不倾斜的数据创建更高效的查询计划

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

        在典型的扩容操作中，用户需要用不同的选项运行gpexpand工具四次：

• 创建扩容输入文件

 

gpexpand -f hosts_file

• 初始化实例并且创建扩容schema

gpexpand -i input_file

•  重新分布表数据

gpexpand -d duration

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

• 移除扩容schema

gpexpand -c