跳转至

扩容规划

集群扩容规划

细心的规划将帮助确保一个成功的SeaboxMPP扩容项目。

这一节中的主题将帮助确保用户已经准备好执行一次系统扩容。

系统扩容检查列表

这个检查列表摘要了一次SeaboxMPP数据库系统扩容包括的任务。

表 1. SeaboxMPP数据库系统扩容检查列表

扩容前的在线任务

系统已启动并且可用

  • 制定并执行订购，构建和联网新硬件平台或配置云资源的计划。

  • 设计一个数据库扩容计划。映射每个主机上的executor数量、安排用于性能测试和创建扩容方案所需的停机时段并且安排用于表重新分布的时段。

  • 执行一个完整的方案转储。

  • 在新主机上安装SeaboxMPP数据库的二进制文件。

  • 复制SSH密钥到新主机（scssh-exkeys）。

  • 验证新硬件或者云资源的磁盘I/O和内存带宽（sccheckperf）。

  • 验证Coordinator的数据目录中在sd_log或者scperfmon/data目录下面没有极大的文件。

扩容前的离线任务

在此处理期间系统对所有用户活动不可用。

  • 验证没有catalog问题 (sccheckcat)。

  • 验证组合的现有和新硬件或云资源的磁盘I/O和内存带宽(sccheckperf)。

在线节点实例初始化

  • 系统已启动并且可用

  • 准备扩容输入文件(scexpand)。

  • 将新节点初始化为数组并创建扩容Schema (scexpand``-i input_file)。

在线扩容和表重新分布

  • 系统已启动并且可用

  • 在用户开始表重新分布之前，停止任何自动的快照处理或者其他消耗磁盘空间的进程。

  • 在扩容后的系统中重新分布表（scexpand）。

  • 移除扩容方案(scexpand -c)。

  • 运行analyze来更新分布统计信息。

在扩容期间使用scexpand -a，在扩容之后使用analyze。

备份数据库

系统已启动并且可用

  • 使用seabox工具备份数据库。 在开始系统扩容之前创建的备份无法还原到新扩容的系统，因为seabox实用程序只能将备份还原到具有相同数量节点的SeaboxMPP数据库系统。
规划新的硬件平台

一个深思熟虑的、周密的部署兼容硬件的方法会大大地最小化扩容处理的风险。

新节点主机的硬件资源和配置应该与现有主机一致。

规划和设置新硬件平台的步骤在每一次部署中都有不同。下面是一些相关的考虑：

  • 为新硬件准备物理空间，考虑冷却、电力供应和其他物理因素。

  • 确定连接新旧硬件所需的物理网络和布线。

  • 为扩容后的系统映射现有的IP地址空间和开发中的网络规划。

  • 从现有的硬件捕捉系统配置（用户、配置文件、NIC等等），这将被用作订购新硬件时的清单。

  • 为在特定站点和环境中用期望的配置部署硬件创建一个自定义的建设计划。

在选择并且增加新硬件到网络环境中后，确保执行expand-nodes.md#topic19中描述的任务。

  • 规划新executor初始化

当系统启动并可用时，可以执行扩容SeaboxMPP数据库。 运行scexpand来初始化新节点到阵列中并创建扩容schema。

所需要的时间取决于SeaboxMPP系统中的方案对象的数量以及其他与硬件性能相关的因素。在大部分环境中，新executor的初始化不超过30分钟。

重要:在用户开始初始化新executor之后，用户就不再能用扩容系统之前创建的备份文件来恢复系统。当初始化成功完成后，扩容会被提交且不能被回滚。

  • 规划Mirror节点

如果现有的阵列有Mirror节点，新的节点也必须有Mirror配置。如果现有的节点没有配置Mirror，则不能用scexpand工具给新主机增加Mirror。有关节点Mirror的更多信息，请参考关于executor镜像。

对于带有Mirror节点的SeaboxMPP数据库阵列，确保增加了足够的新主机来容纳新的Mirror节点。

所需的新主机数量取决于Mirror策略：

散布镜像
向阵列中增加比每个主机上的节点数量至少多一台的主机。要确保平均散布，阵列中独立主机的数量必须大于每台主机上的节点实例数量。散布镜像会把每台主机的镜像散布到集群中剩余的主机上并且要求集群中的主机数量比每个主机上的Primary节点数量更多。
组镜像
增加至少两台新主机，这样第一台主机的镜像可以被放在第二台主机上，并且第二台主机的镜像可以被放在第一台上。如果在系统初始化阶段启用了节点镜像，这是默认的Mirroring策略。
块镜像
添加一个或多个主机系统块。 例如，添加一个包含四个或八个主机的块。 块镜像是一种自定义镜像配置。 关于块镜像的更多信息请参考SeaboxMPP数据库最佳实践指导中的executor镜像。
  • 对每个主机增加新节点

默认情况下，新主机上初始化后会有和现有主机上数量相同的主节点。 可以增加每台主机上的节点或者向现有主机上增加新的节点。

例如，如果现有主机当前在每台主机上有两个节点，可以使用scexpand在现有主机上初始化两个额外的节点来得到总共四个节点，这样将在新主机上有四个新的节点。

创建扩容输入文件的交互式处理会提示这个选项，还可以在该输入配置文件中手工指定新节点的目录。更多信息请参考为系统扩容创建一个输入文件。

  • 扩容Schema说明

在初始化阶段，scexpand工具在seaboxsql数据库中创建扩容schema scexpand。

扩容Schema存储了系统中每个表的元数据，因此在扩容处理的全过程中能跟踪其状态。 扩容Schema由两个表和一个跟踪扩容操作进度的视图组成：

  • scexpand.status

  • scexpand.status_detail

  • scexpand.expansion_progress

通过修改scexpand.status_detail可以控制扩容处理的方方面面。

例如，从这个表中移除一个记录会阻止系统在新节点上扩容该表。通过更新一个记录的rank值，可以控制表在重新分布过程中被处理的顺序。更多信息请参考表重分布排名。

  • 规划表的重新分布

表重新分布会在系统在线时被执行。 对于很多SeaboxMPP系统，表重新分布会在一个安排在低利用率时期执行的单一scexpand会话中完成。更大的系统可能会要求多个会话并且设置表重新分布的顺序来最小化对性能影响。 如果可能的话，尽量在一个会话中完成表重新分布。

重要:要执行表重新分布，节点主机必须具有足够多的磁盘空间来临时地保存最大表的一份拷贝。在重新分布期间，所有的表对于读写操作都不可用。

表重新分布的性能影响取决于一个表的尺寸、存储类型以及分区设计。 对于任何给定的表，用scexpand重新分布需要消耗和一次CREATE TABLE AS SELECT操作相同的时间。在重新分布一个T级别的表时，扩容工具会使用许多可用的系统资源，这可能会影响其他数据库负载的查询性能。

重分布策略

在规划重新分布阶段时，要考虑重新分布期间在每个表上取得的ACCESS EXCLUSIVE锁的影响。一个表上的用户活动可能会延迟它的重新分布，而且表在重新分布期间对用户活动不可用。

可以通过调整ranking来控制表重分布的顺序。 参考表重分布排名。操作重分布顺序有助于调整有限的磁盘空间，并尽快恢复高优先级查询的最佳查询性能。

  • 表重分布方法选择

SeaboxMPP数据库扩容的时候有两种方法重分布数据。

rebuild
建立一个新表，把所有数据从旧表复制到新表，然后替换旧表。 这是默认行为。rebuild方法和使用CREATE TABLE AS SELECT命令创建一个新表类似。 在数据重分布期间，会在表上加ACCESS EXCLUSIVE锁。
move

扫描所有数据并做UPDATE操作来移动需要移动的行到不同节点实例上。 在数据重分布过程中，会在表上加ACCESS EXCLUSIVE锁。

一般来说，这个方法需要更少的磁盘空间，但是它在表里留下了很多被淘汰的行，可能在数据重分布后需要VACUUM操作。另外，此方法一次更新一行索引，这会使它比使用CREATE INDEX命令重建索引更慢。

  • 磁盘空间充裕的集群考量因素

如果系统由充裕的空闲磁盘空间（要求用来存储最大表的一份拷贝），可以通过首先重新分布查询使用最多的重点表来尽快恢复最优的查询性能。为这些表分配高的排名，并且在系统使用量低的时候安排重新分布操作。一次运行一个重新分布处理，直到大的或者关键的表被重新分布完。

  • 磁盘空间有限的集群考量因素

如果现有的主机磁盘空间有限，可以先重新分布较小的表（例如维度表）来腾出空间存储最大表的一份拷贝。由于每个表会被重新分布到被扩容后的阵列上，在原始节点上的可用磁盘空间会增加。当在所有节点上存在足够的空闲空间以存储最大表的一份拷贝后，就可以重新分布大的或者关键的表了。大表的重新分布要求排他锁，请把这种过程安排在非峰值时段。

  • 额外考虑的因素：

  • 在非峰值时段运行多个并行的重新分布处理以最大化可用的系统资源。

  • 在运行多个处理时，处理的数量不能高于SeaboxMPP系统的连接限制。有关限制并发连接的信息请见限制并发连接。

  • 列存表重新分布因素

scexpand以与堆表不同的速率重新分布列存表。 列存表的压缩和解压数据所需的CPU能力会导致增加对系统性能影响。对于具有类似表的集群，可以发现如下的总体性能区别：

  • 列存表重分布比堆表快10%

  • 使用数据高压缩算法的列存表以比低压缩算法的表的扩展速率更慢，可能慢80％。

  • 使用了ZFS/LZJB等数据压缩的系统需要更长时间重新分布。

重要:如果系统节点使用数据压缩，在新结点上使用相同的压缩来避免磁盘空间短缺。

  • 分区表重分布因素

因为该扩展工具可以处理一个大型表上的每个分区，一个有效的分区设计能降低表重新分布的性能影响。 只有一个分区表的子表会不被设置为随机分布策略。一次只对一个子表应用重新分布所需的读/写锁。

  • 有索引的表重分布因素

因为scexpand工具必须在重新分布之后重新索引每个被索引的表，一次高级的索引会带来很大的性能影响。在有很多索引要建立的系统中，表的重新分布要慢很多。