提升企业级数据处理效率!3.0 系列版本的四个集群优化点详解
为了帮助企业更好地进行大数据处理,我们在此前 TDengine 3.x 系列版本中进行了几项与集群相关的优化和新功能开发,以提升集群的稳定性和在异常情况下的恢复能力。这些优化包括 clusterID 隔离、leader rebalance、raft learner 和 restore dnode。本文将对这几项重要优化进行详细阐述,以解答企业在此领域的疑问,并帮助大家更好地应对相关挑战。
clusterID 隔离
问题
firstEp 节点挂掉后,磁盘挂载错误,挂载了一个空白磁盘启动,或者 firstEp 数据被意外删除;
firstEp 再次重启。严重点是这个出错的节点,导致其他节点也无法工作,整个集群都挂掉,集群失去了高可用特性。
造成的后果
firstEp 节点在无数据的情况下重新启动,相当于新创建了一个集群,它重新初始化为一个新集群(重新生成了 clusterid),但此时原集群(旧的 clusterId)中的其它 N-1 个节点仍然向它们所保存的 firstEp 发送心跳,而收到心跳消息的 firstEp 已经是一个新的集群了,所以会拒绝心跳消息,返回节点不存在,要求心跳发送方下线,这些节点收到下线通知后会主动下线,直接导致原集群中的所有节点都不可用。
解决办法
为节点心跳、raft 心跳增加对 clusterid 的判断,即对 clusterid 进行隔离,让具有不同 clusterid 的节点可以独立运行。这种解决办法可以应对节点已经在空白数据上重启的情况。
解决后的效果
在出现磁盘故障后,firstEp 节点启动后,会形成两个集群,一个是 firstEp 节点形成的单节点新集群,另一个是所有其他节点保持旧 clusterid 的旧集群。两个集群可以独立且互不干扰的正常运行。
RAFT Leader Rebalance(TDengine Enterprise 企业版)
问题
比较常见的使用场景,在滚动升级后,所有的 leader 都被赶到一个节点上,整个集群严重失衡。
解决办法
增加 balance vgroup leader;
的 SQL 命令,由 DBA 人工触发集群再平衡,该命令会依次顺序对每个 vgroup 强制重新选举 RAFT leader。因为选举是随机的,所以我们可以通过选举让 leader 迁移到其他的节点上。
解决后的效果
选举理论上随机选出 leader,导致 leader 散开的结果。理论上会均匀,实际上不会绝对均匀。
Raft Learner
问题
在副本变更时(create mnode, alter db replia),如果存量数据(元数据或时序数据)量比较大时,相应操作会执行很长时间,要等待存量数据同步完成后命令才能执行完成,并且在此期间会阻塞数据写入。
解决办法
在 Leader/Follower/Candidate 之外引入第四种 Raft 角色——Raft learner。Raft Learner 只同步数据不参与选主,也不参与数据写入时的一致性协议。当 Raft Learner 的数据同步进度被追上后才会变身为 Follower,成为 Raft 集群的一部分。这样命令虽然执行很长时间,但不会阻塞写入。
受影响的命令
解决后的效果
副本变更时,不会再阻塞写入。相应的命令执行可以很快返回。
Restore dnode(TDengine Enterprise 企业版)
问题
数据盘出现问题,重新挂载新数据盘,这个节点上所有数据目录都丢失。
解决办法
增加命令:
该命令,从 mnode 读取节点中关于 mndoe、vnode、qnode 的信息,按照这些在节点重建 mnode、vnode、qnode,在重建结束后,会开始从其他副本复制数据。
解决后的效果
按照原有的 taos.cfg 的配置启动 taosd,该节点会自动加入群,并且 dnode 显示为 ready,即 online 状态。在节点变为 online 后,通过命令可恢复全部 mnode、vnode、qnode,也可以分别恢复。
功能限制
该功能是基于已有的复制功能的恢复,不是灾难恢复或者备份恢复,所以对于 mnode 和 vnode 来说,使用该命令一定是还存在其他 mnode 和 vnode 的其他副本。该命令不能修复数据目录中个别文件的损坏或者丢失,是整体的恢复一个 mnode 或者 vnode。
写在最后
通过本文,相信大家已经初步了解了上述几项功能优化。如果你对这些功能有进一步的了解需求,或者希望进一步讨论在应用中遇到的问题,欢迎添加小 T vx:tdengine,与我们专业的解决方案架构师直接沟通。
评论 (1 条评论)