南大通用GBase 8a在进行扩容操作时,会检查所有节点的状态,如果节点离线,因无法登录,会有Check login 类错误,无法进行扩容操作。
标签: 扩容
GBase 8a MPP数据库集群和扩容有关的经验分享和问题处理
南大通用GBase 8a重分布日志各个阶段耗时情况
南大通用GBase 8a通过重分布Rebalance进行扩缩容等操作,在集群层的express.log里记录了执行情况,包括各个阶段的耗时。
南大通用GBase 扩容操作重分布完成后清理旧的distribution时报错FCan not drop nodedatamap EventLog is using distribution
南大通用GBase 8a在扩容操作中,当所有表已经全部重分布到新的分布策略distribution以后,老的distribution就可以用refreshnodedatamap drop删除了。 但如果此时有些表存在event,且使用的老的策略,则会出现这个错误:Can not drop nodedatamap EventLog is using distribution。此时需要将原有的event处理完成才可以继续操作。
南大通用GBase 8a里通过rsync加速调度coor节点的扩容和替换效率
在GBase 8a的早期版本里,扩容或者节点替换调度节点(coordinator)时,是通过本地tar打包,然后scp传输到新节点来实现的,而tar本身不支持并行,所以代码上是将打包任务按表名字分解成多个任务,发到多个调度节点执行(并行打包)。新版本支持通过rsync的方式进行更快速的高效同步。本文介绍与此有关的内容。
南大通用GBase 8a运维案例:一次操作系统用户安全加固导致的扩容失败
南大通用GBase 8a集群上线项目扩容操作,最终用户出于安全考虑,都会做安全加固,结果就是一些命令表面看着很正常,可是一旦远程运行,或者多几次用户su切换,就会出问题。
南大通用GBase 8a运维案例分析:扩容重分布期间,某节点性能极差,其它10分钟,其需要2-3个小时
某客户反馈,扩容操作重分布已经快1个月了,发现每天就完成十几个表,按照这个速度,需要半年以上。经过排查,发现客户是在云环境,部分计算节点之间,出现严重的网络问题,上行和下行速度都极差(500K-2MB),正常的至少150MB。
南大通用GBase 8a扩容缩容时重分布进度查询rebalancing_status
南大通用GBase 8a扩容缩容时重分布进度查询rebalancing_status
南大通用GBase 8a通过扩容的方式达到节点替换的目的
南大通用GBase 8a支持节点替换,当某些服务器出现不可恢复的故障时,比如磁盘损坏,可以在修复后替换,或者用新节点做节点替换。在V8版本里,默认节点替换必须用老的IP,在V95版本的多VC模式,支持了集群空闲的备用节点freenode节点替换模式。本文介绍一种通过扩容的方式,采用新节点做数据计算节点替换的方案。
南大通用GBase 8a在扩容操作报ImportError No module named pexpect错误
南大通用GBase 8a集群在执行扩容时,要在各个节点执行python的脚本,使用了pexpect的库。如果节点不存在pexpect.py库,则会报这个错误ImportError No module named pexpect
南大通用GBase 8a 扩容重分布报错ERROR 1707 (HY000): gcluster command error: table can't be rebalanced when only one distribution rule.
南大通用GBase 8a数据库集群支持在线扩容,用户根据新的硬件情况,创建新的主备策略后,必须要初始化分布规则,initnodedatamap,如果忘记初始化直接rebalance 操作,则会报这个错误,因为系统元数据里,只有1份分布规则。