GaussDB-在线DN分片缩容

GaussDB-在线DN分片缩容

可获得性

本特性自GaussDB 503.1.0版本开始引入。

特性简介

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

  1. 基线数据重分布和增量数据重分布。
  2. 表切换。
  3. 删除缩容节点。

特性原理

随着客户业务的变化，原有集群在日常运行过程中存在资源富余情况，为降低使用成本需提供缩容能力，设计图如下：
图1 在线DN分片缩容示意图
在线缩容过程的本质是集群内本地表的NodeGroup之间的数据搬迁，缩容过程指较大的NodeGroup向较小的NodeGroup进行数据搬迁，反之则看成是扩容过程。对于每个缩容重分布的表而言可以看成是这三个过程：
  1. 基线数据重分布和增量数据重分布。
  2. 表切换。
  3. 删除缩容节点。

客户价值

随着客户业务的变化，原有集群在日常运行过程中存在资源富余情况，为降低使用成本需提供缩容能力，但缩容的完成需要一定的时间窗口，可能会影响业务。业务中断将给用户带来重大损失，因此需要在线缩容的特性，使得用户业务在缩容重分布过程中无需中断，平滑过渡。

特性描述

缩容以DN环为最小单元，根据用户预期缩容的DN分片数量计算出对应的DN环进行缩容，最终将DN环所包含的机器从当前集群中剔除。

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

特性约束

  • 集群状态为Normal，重分布状态为No。
  • 不支持cms少数派故障场景下和gtmFree时gtm故障场景下的normal集群缩容。
  • 集群不能处于锁定状态。
  • 集群配置文件已经生成，配置的信息正确并且和当前集群状态一致。
  • 缩容前用户需要确保default_storage_nodegroup参数值为installation。
  • 缩容前需退出创建了临时表的客户端连接，因为在缩容过程中及缩容成功后临时表会失效，操作临时表也会失败。
  • 仅支持大于等于两副本部署的集群。
  • 缩容操作不可下发在被缩容的节点上。
  • 缩容时集群不可处于read-only状态。
  • 不支持表优先重分布、部分表不重分布。
  • 不支持集群中存在list和range分布的表。
  • 存在hashbucket表或绑定过group的数据库不支持缩容。
    通过以下SQL查看是否存在hashbucket表，查询结果为0表示存在hashbucket表，否则不存在。 
    SELECT COUNT(*) FROM pg_catalog.pg_class where reloptions::text like '%%hashbucket=on%%';
     
    通过执行以下SQL语句查看数据库是否绑定group，查询结果为0表示未绑定过group，否则为绑定过group。 
    SELECT count(*) FROM pg_catalog.pg_hashbucket;
     
  • 集群缩容过程中，请勿改动$PGHOST/shrink_step/shrink_step.dat文件，否则影响缩容重入正确性。
  • 缩容时，按照当前分片部署顺序从后向前缩容，不可跳跃。
  • 缩容不支持包括CN的节点，如果包括CN，先使用增删CN工具，删除CN后再缩容。
  • 缩容数据重分布失败，不影响业务，用户可选择合适的时间尽快完成重分布，否则会导致数据长期分布不均匀。
  • 缩容的主机不能包含ETCD，GTM，CM Server。
  • 重分布前，需要保证对应数据库下的data_redis为重分布预留schema，不允许用户操作该schema和其内部表。因为在重分布过程中，会使用到data_redis并且重分布结束后会删除该schema，如果存在用户表，则可能会出现数据误删。
  • 缩容操作只支持集群中只有一个NodeGroup的缩容，不支持集群中包含多个NodeGroup的缩容。
  • 缩容过程不支持gs_cgroup操作。
  • 缩容完成以后，集群中唯一的NodeGroup名称为group_version1或者group_version2。
  • 如果缩容前的Node Group下有依赖它的Child Node Group，缩容完成后，集群中新创建的Node Group下也会创建相应数量的Child Node Group，且和缩容前的Child Node Group一一对应。
  • 缩容过程中，若因实例异常导致缩容失败，请参考《工具参考》中的“服务端工具 > gs_replace”章节内容在后台进行修复，故障修复后重入缩容。
  • 执行缩容前，建议磁盘阈值满足以下条件：

    （全部表容量/缩容后DN个数 + 最大单表容量/缩容后DN个数） < 只读阈值（85%）*磁盘容量。

  • 缩容失败后，不允许手动单独调用重分布，需要重入缩容。
  • 缩容过程中系统将关闭“自动剔除故障CN”功能，在缩容完成后系统再次打开该功能。
  • 缩容后若清理被缩容节点失败，缩容流程成功结束，此时如有需要需手动清理。
  • 多表join功能约束：
    • 不能使用read-only模式。
    • 需要用户识别出带有join关系的用户表列表，利用文件的形式传递给内核。
    • 为属于一个group的表预留足够的磁盘空间，即group中所有表（表+索引）总和的1倍；考虑到资源有限，逐个group进行重分布，因此需要预留最大group大小1倍即可。
    • 每个group中的表数量上限为5张，下限为2张。
    • 表名中如果含有特殊字符，比如空格等需要使用双引号进行转义，否则代码可能无法正确读取表名，例如会使用空格做表名切分。
    • 多表join group中的表目前只支持普通行存表（包括普通表和分区表），range/list表、外表、物化视图、hashbucket表、复制表等均不支持。
    • 多表join需要配合写报错模式和业务快速失败模式进行，因此只支持用户业务允许报错重试的场景；写报错模式时间窗口需要等group中的所有表均完成才能进行元数据切换，相较于单张表，影响窗口增大，但仍然是秒级完成，写报错模式持续时长和用户配置的last_catchup_threshold参数有关，默认值5秒；切换元数据耗时：通常场景采用cancel模式拿锁加切换元数据，单表2秒，最长10秒（最多5张表）；最坏场景：(lockwait_timeout + 2)*group中表数量。
    • 重分布开始后支持修改group信息，但是由于重分布的顺序是先单表后group，一旦表已经完成重分布就无法回退且无法指定到group中。
    • 在重分布的重入场景中，如果修改了已经开始重分布的group中的表到两个不同的group中，下次重入表占用的空间不会自动释放，直到group完成元数据切换后才能进行资源清理。如果需要释放只能手动执行。
    • 在IO、CPU资源使用较高的场景，不适合开启多表缩容功能。否则可能触发重分布工具主动资源管控，导致使用IO限制过严以及性能严重降低、追增不上的情况，使用前需谨慎评估。
    • 对于group中的表写业务量都比较大的场景，开启多表缩容功能可能出现追增不上的风险，需要谨慎评估。

特性增强

无

依赖关系

无。

 
posted @ 2024-10-29 16:05  jerrywang1983  阅读(0)  评论(0)    收藏  举报