Mycat生产实践---数据迁移与扩容实践

1 离线扩容缩容

工具目前从mycat1.6开始支持。
一、准备工作
1、mycat所在环境安装mysql客户端程序
2、mycat的lib目录下添加mysql的jdbc驱动包
3、对扩容缩容的表所有节点数据进行备份，以便迁移失败后的数据恢复
二、扩容缩容步骤
1、复制schema.xml、rule.xml并重命名为newSchema.xml、newRule.xml放于conf目录下

2、修改newSchema.xml和newRule.xml配置文件为扩容缩容后的mycat配置参数（表的节点数、数据源、路由规则）
3、修改conf目录下的migrateTables.properties配置文件，告诉工具哪些表需要进行扩容或缩容,没有出现在此配置文件的schema表不会进行数据迁移，格式：

4、修改bin目录下的dataMigrate.sh脚本文件，参数如下：

tempFileDir 临时文件路径,目录不存在将自动创建
isAwaysUseMaster默认true:不论是否发生主备切换，都使用主数据源数据，false：使用当前数据源
mysqlBin：mysql bin路径
cmdLength mysqldump命令行长度限制 默认110k 110*1024。在LINUX操作系统有限制单条命令行的长度是128KB，也就是131072字节，这个值可能不同操作系统不同内核都不一样，如果执行迁移时报Cannot run program "sh": error=7, Argument list too long 说明这个值设置大了，需要调小此值。
charset导入导出数据所用字符集 默认utf8
deleteTempFileDir完成扩容缩容后是否删除临时文件 默认为true
threadCount并行线程数（涉及生成中间文件和导入导出数据）默认为迁移程序所在主机环境的cpu核数*2
delThreadCount每个数据库主机上清理冗余数据的并发线程数，默认为当前脚本程序所在主机cpu核数/2
queryPageSize 读取迁移节点全部数据时一次加载的数据量 默认10w条

5、停止mycat服务（如果可以确保扩容缩容过程中不会有写操作，也可以不停止mycat服务）
6、通过crt等工具进入mycat根目录，执行bin/ dataMigrate.sh脚本，开始扩容/缩容过程：

7、扩容缩容成功后，将newSchema.xml和newRule.xml重命名为schema.xml和rule.xml并替换掉原文件，重启mycat服务，整个扩容缩容过程完成。
三、注意事项：
1) 保证拆分表迁移数据前后路由规则一致
2) 保证拆分表迁移数据前后拆分字段一致
3) 全局表将被忽略
4) 不要将非拆分表配置到migrateTables.properties文件中
5) 暂时只支持拆分表使用mysql作为数据源的扩容缩容
四、优化
dataMigrate.sh脚本中影响数据迁移速度的有4个参数，正式迁移数据前可以先进行一次测试，通过调整以下参数进行优化获得一个最快的参数组合

threadCount脚本执行所在主机的并行线程数（涉及生成中间文件和导入导出数据）默认为迁移程序所在主机环境的cpu核数*2
delThreadCount每个数据库主机上清理冗余数据的并发线程数，默认为当前脚本程序所在主机cpu核数/2，同一主机上并发删除数据操作线程数过多可能会导致性能严重下降，可以逐步提高并发数，获取执行最快的线程个数。
queryPageSize 读取迁移节点全部数据时一次加载的数据量 默认10w条
cmdLength mysqldump命令行长度限制 默认110k 110*1024。尽量让这个值跟操作系统命令长度最大值一致，可以通过以下过程确定操作系统命令行最大长度限制：
逐步减少100000，直到不再报错
/bin/sh -c "/bin/true $(seq 1 100000)"
获取不报错的值，通过wc –c统计字节数，结果即操作系统命令行最大长度限制（可能稍微小一些）

2 案例一：使用一致性Hash进行分片

当使用一致性Hash进行路由分片时，假设存在节点宕机/新增节点这种情况，那么相对于使用其他分片算法(如mod)，就能够尽可能小的改变已存在key映射关系，尽可能的减少数据迁移操作。当然一致性hash也有一个明显的不足，假设当前存在三个节点A,B,C，且是使用一致性hash进行分片，如果你想对当前的B节点进行扩容，扩容后节点为A,B,C,D，那么扩容完成后数据分布就会变得不均匀。A,C节点的数据量是大于B,D节点的。
据测试，分布最均匀的是mod，一致性哈希只是大致均匀。数据迁移也是，迁移量最小的做法是mod，每次扩容后节点数都是2的N次方，这样的迁移量最小。但是mod需要对每个节点都进行迁移，这也是mod的不足之处。总之，还得酌情使用，根据业务选择最适合自己系统的方案。
2.1 配置使用
rule.xml：定义分片规则

<tableRule name="sharding-by-murmur"> 
<rule> 
<columns>SERIAL_NUMBER</columns> <algorithm>murmur</algorithm> 
</rule> </tableRule> 
<function name="murmur" class="org.opencloudb.route.function.PartitionByMurmurHash"> 
<property name="seed">0</property> 
<property name="count">2</property> 
<property name="virtualBucketTimes">160</property> 
</function>

tableRule定义分片规则

• name：分片规则的名字。在schema.xml文件中调用。
• columns：根据数据库中此字段进行分片。
• algorithm：值是分片算法定义处的name属性。比如：murmur。

function定义一致性Hash的参数

• seed：计算一致性哈希的对象使用的数值，默认是0。
• count：待分片的数据库节点数量，必须指定，否则没法分片。
• virtualBucketTimes：虚拟节点。默认是160倍，也就是虚拟节点数是物理节点数的160倍。指定virtualBucketTimes可以使一致性hash分片更加均匀。
• bucketMapPath：用于测试时观察各物理节点与虚拟节点的分布情况，如果指定了这个属性，会把虚拟节点的murmur
  hash值与物理节点的映射按行输出到这个文件，没有默认值，如果不指定，就不会输出任何东西。必须是绝对路径，且可读写。
  schema.xml：定义逻辑库，表、分片节点等内容

<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE mycat:schema SYSTEM "schema.dtd">
<mycat:schema xmlns:mycat="http://org.opencloudb/">