环境
公司系统是为多个餐饮集团服务，目前多个餐饮集团的数据量扩增，所以需要将几个数量量大的集团单独拆开。目前的业务为报表数据查询ES，mysql已应付不了报表的性能要求。ES里的数据务必要保证与mysql一致（目前增量同步ES基于canal实现）。本次拆库由运维负责mysql按集团拆库，开发方负责ES的全量同步。
方案
-
使用DataX针对某个集团，复制数据到新mysql库中，同时调整zk动态数据源，新集团的请求路由到新库（集团ID始终是系统每个接口必有属性）。
-
检查新库数据是否与老库一致，由于存在路由关系，老库数据可以保留。
-
检查集团数据是否可以路由到新集团上。
-
创建集团的新ES索引，预先设置好index的模板。
-
使用 go-mysql-elasticsearch全量同步mysql数据，检查ES数据与mysql数据是否一致。
-
开启canal的增量同步监听binlog。
-
建立ES别名与索引的映射关系。
-
测试报表功能数据是否正确，并且是双份。
-
删除原index内对应集团的数据
go-mysql-elasticsearch
go-mysql-elasticsearch也是一款解析binlog到es的go语言开发的插件工具：github地址
官方的使用注意事项：
- binlog format must be row.
- binlog row image must be full for MySQL, you may lost some field data if you update PK data in MySQL with minimal or noblob binlog row image. MariaDB only supports full row image.
- Can not alter table format at runtime.
- MySQL table which will be synced should have a PK(primary key), multi columns PK is allowed now, e,g, if the PKs is (a, b), we will use "a:b" as the key. The PK data will be used as "id" in Elasticsearch. And you can also config the id's constituent part with other column.
- You should create the associated mappings in Elasticsearch first, I don't think using the default mapping is a wise decision, you must know how to search accurately.
- mysqldump must exist in the same node with go-mysql-elasticsearch, if not, go-mysql-elasticsearch will try to sync binlog only.
- Don't change too many rows at same time in one SQL.
不仅支持全量同步，还支持少量的增量同步。
基于binlog实现，需要开启mysql的binlog，并设置为行级。
支持多库多表同时进行同步，需配置好对应的数据源信息、索引与表的映射关系。
开始
2018-05-24 23:30
运维通知mysql数据导入完毕。开始检查源库与新库的数据，比较顺利，数据一致。
2018-05-25 00:25
测试集团是否路由到新库中，添加订货单，检查新库是否存在新增的数据，测试通过。
2018-05-25 00:40
PUT新索引，开启全量同步插件同步到ES。数据量比较多，这个过程比较缓慢，一边同步一边检查是否有数据遗漏。不过还真有个表的数据少同步了2条。删除了整个索引，重新建索引，配置go-mysql-elasticsearch针对此表进行全量同步。需要注意的是，go-mysql-elasticsearch每次会记录mysql的binlog的位置，重新同步后，需要把位置清零，才能全量同步。
2018-05-25 01:55
待命的canal增量同步软件登场，同时建立好别名与索引的映射关系。
中间也出现了个小插曲，index的模板的一个字段的类型设置错误了，canal增量同步报错。删除索引重新全量同步。
2018-05-25 02:15
测试报表功能的数据，查询到的数据都是双份，正是所期待的效果。
2018-05-25 02:30
好了，到此，可以删除原索引内的对应集团的数据了，晚上还算比较顺利。
总结
本次数据迁移涉及到三方部门：开发、测试、运维。数据迁移本身并不复杂，需要的是各部门之间的配合以及细心。
网友评论