GaussDB 扩展性--支持在线扩容_gaussdb是否支持支持在线扩容和动态负载均衡-CSDN博客

本文链接：https://blog.csdn.net/Cui_Yuan_666/article/details/145197997

支持在线扩容

可获得性

本特性自版本V300R002C00开始引入。

hashbucket表在线扩容特性自版本V500R002C00开始正式引入。

特性简介

在线扩容过程的本质是集群内众多本地表的NodeGroup之间的数据搬迁，扩容过程指较小的NodeGroup向较大的NodeGroup进行数据搬迁，反之则看成是缩容过程。对于每个扩容重分布的表而言可以看成是这3个过程：

基线数据扩容重分布。
增量数据重分布。
表切换。

基于hashbucket表的在线扩容的扩容整体流程主要包含3个步骤：

基线数据搬迁：生成扩容搬迁计划，根据搬迁计划中对涉及的库中的bucket文件进行跨节点文件搬迁。包含库级别的数据文件和实例级别的事务日志。
bucket日志流追增：识别bucket扩容过程中的增量修改，将对应的日志发送到目的节点并在目的端进行增量修改的日志回放。
bucket元数据切换：当bucket日志流追增完成后，原节点和目的节点的bucket数据达到一致状态，可以对原节点的bucket进行下线删除，对目的节点的bucket进行上线操作，同时修改CN上的bucket map映射使新的业务能够路由到正确的DN节点。

客户价值

随着数据量的增加，GaussDB需要进行扩容，但扩容的完成需要一定的时间窗口，可能会影响业务。业务中断将给用户带来重大损失，因此需要在线扩容的特性，使得用户业务在扩容重分布过程中无需中断，平滑过渡。

特性描述

普通表通过创建临时表和记录数据删除的增量表，在扩容过程中通过更新此轮数据重分布的范围来实现在线扩容。

扩容前提条件

集群状态必须为Normal或Degraded状态，集群Degraded状态只是实例异常引起的集群状态异常，不支持VM异常引起的集群状态异常（VM异常指非软件类异常，例如：磁盘故障、通信故障），请确保实例状态异常节点的网络正常。
实例状态：CN全部正常，GTM、CMS至少有主节点存活，ETCD实例状态满足多数正常。DN实例状态有以下三种情况：两副本集群单个分片内至少主DN实例正常（hashbucket扩容要求主备DN都正常）；两AZ集群DN实例单个分片至少存活一主一备；除了以上两种之外的其他情况DN实例单个分片异常数量小于一半。
如当前集群有异常但是不满足以上约束条件，请参见《工具参考》中的“服务端工具 > gs_replace”章节内容进行修复。
集群扩容要求整个集群没有被锁定，集群配置文件的配置信息正确并且和当前集群配置一致。
已按照扩容的集群配置文件执行过前置脚本gs_preinstall。
新增主机和现有集群之间通信已经建立，网络正常。
扩容前需保证集群所有CN可连接，在集群用户下执行gs_check -i CheckDBConnection命令检查CN是否可连接。
扩容前需做ANALYZE（保证扩容进度准确性时需要执行）。
重分布资源管控对象redisuser、redisrespool、redisclass、redisgrp不能被占用。
重分布过程中不能将其他用户绑定到重分布专用的资源池redisrespool上。不能用gs_cgroup -M等操作破坏当前Cgroups配置。若用户在Cgroups出现问题时使用gs_cgroup --revert恢复默认配置，则需重启集群才能保证新建立的redisclass和redisgrp生效。
如果当前集群有对hashbucket的表开启OLTP表压缩，需要等待全部压缩任务结束，并关闭自动调度任务，扩容期间不支持压缩调度（详情请参见《特性描述》“高性能 > 数据生命周期管理-OLTP表压缩 > 特性约束”）。
重分布前校验无效索引残留，需遍历库执行select count(*) from pg_index where indisvalid = 'f' and indisusable = 't' ，如果返回值大于1，用户需要手动效验失效索引，即执行ALTER INDEX index_name UNUSABLE。

表特性增强

扩容过程支持数据持续入库，业务不中断。
支持扩容过程中故障重入，支持表粒度的断点续传。

支持多表并行扩容，扩容性能高。

重分布过程中支持数据持续入库，业务不中断。
重分布过程按database，表按顺序进行重分布（-j指定多线程并发时可以多个表同时进行）。重分布过程中区分外表和普通表。由于外表不涉及数据迁移，只涉及节点信息的更新，所有外表放在一个事务里，先进行重分布。重分布执行过程中，需要采用execute direct的形式在其他节点（其他CN、DN）上更新pgxc_class、pg_class等系统表里的元信息，主要包括表的重分布状态，交换relfilenode，变更nodegroup等相关信息。对于不涉及正在重分布表的DDL、DML等相关操作不受影响，用户可并发执行。对于正在重分布的表用户可以并发执行select、insert、insert/select操作。同时重分布的进度状态查询和表顺序设置都可通过直接连接CN查询。

扩容过程中，数据库支持DDL和DCL操作，如果用户并发事务块中包含DDL操作，用户DDL操作会报错，事务回滚。

重分布过程中，支持用户进行本地表的DROP、TRUNCATE、TRUNCATE-PARTITION业务，正在重分布的表支持更新、插入和删除数据，重分布阶段不允许执行性能统计查询。

重分布过程中用户可进行正在重分布的本地表跨节点组的关联查询业务，性能可能受到一定影响。
支持内核自适应等锁：即对于业务持续高峰且业务允许正常报错的场景，内核通过自动取消业务保证重分布线程顺利拿锁推进流程。
数据收敛到最后支持写报错模式完成追增。
支持重分布过程中对关键参数进行动态实时调整。

表特性约束

重分布过程，存在用户业务与重分布资源的争抢，不适合大业务背景下做在线数据重分布。对于资源有限的场景，需要对数据重分布做资源管控来降低对用户业务的影响，目前粗粒度的资源管控可能导致重分布无法正常结束，因此使用在线扩容前需要对资源使用情况进行评估，需要为重分布预留足够的资源。
数据重分布过程中，以表为粒度进行数据搬迁，在数据搬迁过程中需要拿高级别表锁来阻塞用户写业务，从而获取数据在页面上准确的起始位置。由于当前表锁采用排队机制，一旦遇到慢SQL导致重分布线程处于等锁状态，会阻塞用户业务，此时会造成用户业务时延上涨，对于不停重试的业务模型出现线程池满无法对外提供服务的严重影响，因此使用在线扩容前需要谨慎评估业务模型对等锁的容忍程度以及是否存在慢SQL情况来评估是否能够进行在线扩容。
对于用户业务有多表关联查询的场景（表间使用分布列join并且分布列的分布方式相同），在数据重分布过程中可能出现跨node group join导致性能劣化，对于有大量join查询的场景不能做在线扩容。

扩容过程中，不支持用户并发事务块中包含Temp表创建使用。
重分布过程，目前不适用于单表大数据量数据持续入库（频繁增删改）场景（用户单表系统资源占用，超过重分布追增系统资源使用），数据追增阶段会影响用户持续导入与查询失败。
重分布过程中，用户应当避免执行长时间的查询场景，否则可能导致重分布出现等待加锁超时失败。
重分布过程中，对于大分区表，重分布阶段时间较长，用户周期性删除分区操作会打断重分布。
Unlogged表无xLog，在线数据重分布阶段，有数据少量丢失风险。
数据重分布开始后不支持回退，因此需要在进行在线扩容前做好风险评估。
多表扩容模式约束：
- 为属于一个group的表预留足够的磁盘空间，即group中所有表（表+索引）总和的1倍；考虑到资源有限，逐个group进行重分布，因此需要预留最大group大小1倍即可。
- 多表扩容需要配合写报错模式和业务快速失败模式进行，因此只支持用户业务允许报错重试的场景。写报错模式时间窗口需要等group中的所有表均完成才能进行元数据切换，相较于单张表，影响窗口增大，但仍然是秒级完成。写报错模式持续时长和用户配置的last_catchup_threshold参数有关，默认值5秒。切换元数据耗时：通常场景采用cancel模式拿锁加切换元数据，单表2秒，最长10秒（最多5张表）；最坏场景：(lockwait_timeout + 2)*group中表数量。