业务采用了共享盘阵，支持多个数据节点。随着业务量增加，盘阵容量已经无法承担，且盘阵自身也无法扩容，需要将部分数据节点的数据迁移到其它的盘阵。本文简单介绍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、否则采用节点替换方案。并配合适当的同步并行度控制。