GBase 8a节点数据迁移到其它存储盘阵的磁盘空间扩容方案

业务采用了共享盘阵,支持多个数据节点。随着业务量增加,盘阵容量已经无法承担,且盘阵自身也无法扩容,需要将部分数据节点的数据迁移到其它的盘阵。本文简单介绍GBase 8a数据库集群的几个实现方案。

环境

1、操作系统是独立的,比如3台物理机的集群,有操作系统盘,数据盘是外挂盘阵。

2、盘阵是共享的。比如3个物理机共享一个60T的盘阵,每个用20T。

3、业务数据量增加,1个盘阵已经无法承担3个物理机。需要将其中1个物理机承担的数据迁移到一个新的盘阵上。

4、后续计划在第二个盘整,新增一个物理机,整体扩容到4节点集群,每个盘阵负担2个物理机。

方案分析

本需求的核心是如何将数据从盘阵1迁移到盘阵2上,并尽量减少集群停服时间以及对日常业务的影响。

迁移数据有2个途径:
1、从盘阵1,通过操作系统级的物理文件复制的方式,直接拷贝文件到盘阵2;
2、通过数据库节点替换机制,重建新节点。

下面分别讨论2个方案的细节。

操作系统物理文件复制

整体步骤

1、将数据从盘阵1同步到盘阵2

2、切换数据库目录,节点相关文件的mount信息,从盘阵1切换到盘阵2

同步数据

如果数据量不大,建议停止数据库或者readonly数据库,然后走ftp文件复制。一直到文件复制结束。

如果数据量大,停服时间过长,可以用lftp的增量同步(mirror)方式。通过每一轮的同步减少差异量。当差异量同步耗时在允许范围内后,停下数据库或readonly,做最后一次完整同步。

提示:数据库相关数据文件,除了安装目录下的gcluster和gnode,还有/var/lib/gcware,但一般都是保存在操作系统盘上,不用同步到盘阵2.

lftp相关命令参考

lftp -u gbase,T2k@zxrc14 -e"mirror --parallel=8 --no-umask --verbose /opt/gcluster /opt/gcluster;quit;" 192.168.192.4

lftp -u gbase,T2k@zxrc14 -e"mirror --parallel=8 --no-umask --verbose /opt/gnode /opt/gnode;quit;" 192.168.192.4

一般盘阵mount的是整个安装目录,如果只mount了userdata目录,可以只同步userdata。

切换数据库目录

1、停掉数据库服务

2、umount现有的数据库安装目录或数据目录

3、mount新的盘阵到安装目录或数据目录

4、启动数据库服务

优点

1、操作思路简单,等同于物理备份还原。

2、没有回退风险(复制不成就不做切换就行了)。

3、如能一次性完成同步,整体影响时间短或可控。

缺点

1、数据量大时,整体同步或增量同步耗时较长。

2、人员操作要求高。需要频繁的监控同步状态,避免中间异常退出。增量同步更需要执行多次,并人工判断同步耗时是否已经满足要求,以便做最后的全同步。

节点替换

整体步骤

将迁移节点人工下线

造成人工故障。数据目录清理。包括安装目录和/var/lib/gcware

挂载新的盘阵

将原有的盘阵1 umont,改成新的盘阵 mount。

节点替换

这个具体操作请参考 :GBase 8a 强制节点离线和节点替换replace

优点

1、操作简单,完全按照节点替换的流程。

2、人员负担轻,数据同步由数据库内部自行完成,无需人工干预。

缺点

1、同步耗时长:同步时采用的按表的逻辑同步,性能比物理文件同步差,一般评估性能是物理的1/3。

2、中断服务的时间可能更长:如果表比较多,在执行节点同步命令是,耗时长。根据工程经验,如果由20万级别的表,预计同步操作耗时在3-6小时。主要与磁盘性能有关,性能越好耗时越少。

3、同步期间,对系统影响需要人工控制同步(gc_recovery)的并行度。但更低的并行度代表需要更长的时间。这个需要平衡。

总结

根据工程经验:

1、能够在时间窗口一次性完成数据复制的,建议用物理文件复制方案。

2、否则采用节点替换方案。并配合适当的同步并行度控制。

参考

GBase 8a 强制节点离线和节点替换replace

GBase8a V862版本节点替换前的准备工作和注意事项

GBase 8a V95版本节点替换操作手顺

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注