mysql到es的同步
mysql到es的同步
mysql到es的同步
  Elasticsearch（es）使⽤场景，正如es⼀直强调的“⼀切为了搜索”，作为⼀款分布式的搜索引擎，使⽤场景较为宽泛，可以任意查询条件组合完成数据的检索。这正是mysql等关系型数据库的痛点所在。但对于每家公司的核⼼系统（toB公司）来说，它的核⼼业务数据都是需要各种组合查询才能完成业务需求。⽽为了数据的完整性和强⼀致性等⽬的，都采⽤被验证多年的关系型数据库来存储数据，互联⽹公司⼀般是mysql。那么这就是⼀个⽭盾，使⽤了mysql就不能完成灵活的检查，且数据量⼀⼤查询就会变得越来越困难，这正是es所善长的事情。
  现在的问题就变成了，怎么保证mysql的数据和es数据实时同步的问题，数据量稍⼤的项⽬，为了提⾼并发和简单查询效率，也会来做分库分表，所以mysql到es同步也需要考虑分库分表情形。
（⼀）数据同步⽅案
罗马2:全面战争
  数据同步较为传统的⽅案是双写模式，也就是说这种⽅式有什么错，但双写模式是⼀种较强侵⼊性⽅案，有⼏个问题需要研发⼈员考虑的，⼀是事务，如何保证写mysql和写es能做到在⼀个事务中完成？特别是较复杂的mysql⼤事务（toB项⽬往往⼤概率出现）和不⽀持事务的es如何能做到兼容？下⼤量耗
资源的事务出事对⾼并发情况下的影响也需要考虑。⼆是业务写的逻辑会不会遗漏的问题，写mysql是分散到系统的各模块各功能点去了，后⾯需要变更业务逻辑和增加新的功能时，那么就得满世界去双写的点来进⾏修改。这需要⾮常了解业务，即使所有的代码是⼀个⼈开发的，也难保不会忘了某个点没改，特别是在较多ifelse逻辑情形下。
二手房 个税  ⽽duckula就是通过更底层的binlog来完成mysql到es的同步的，binlog是mysql数据库的主从同步机制，可以说是较成熟的⽅案，不会有数据丢失的问题。且它是毫秒级（10毫秒以内），对于⼈⼯完成查询是⾜够了，除⾮程序查询反应不过来。
⽅案定下来使⽤binlog，实施的时候就需要考虑如下⼏个问题：
1. binlog是实例级别的，肯定要过滤到表级别
2. 过滤的表级别数据有没有权限考虑，⾏过滤（saas系统的分租户），纵过滤（系统内部字段等不需要过滤），删除的binlog要不要执
⾏等（操作过滤）。
3. 我监听的表的数据，别的应⽤（如ETL,flink等）会不会使⽤？
4. 我的全量数据怎么做，不可能全同步到消息队列吧？
5. 在后⾯出问题了、需求变更需要修复数据，加索引字段和同义词需要重建索引，这种全量和部分全量如何实施。
6. 我的同步逻辑是写到应⽤程序⾥部署还是独⽴中间件部署？如果是中间件部署，我的HA如何做？应⽤程序⼀般会起⼏个相同的实例来
做负载的，那我的分布式锁如何做（同步2份相同的数据让费资源）？
7. 索引字段如何建？有2表关联怎么处理？甚⾄我有多表如何处理？
8. mysql添加了字段如何不停机动态⽣成es的字段？
  上⾯的问题就是duckula所关注和试图解决的问题。duckula由库名表名⽀持正则表达试的表级binlog过滤，也⽀持⾏、列过滤和操作过滤，更进⼀步的是⽀持⼦表通过⽗表的字段来做⾏过滤。索引的⾃动创建和索引字段的动态添加（mysql加字段后）,
坐月子菜谱
通过duckula，你可以⾛kafka消息再到es这条路，也可以直接到es这条路。这点在duckula的登陆页⾯会有较明确的指⽰：
  现在我们以两个例⼦来演⽰⼀下如何通过duckula3来配置监听，⼀个是mysql单表数据直接同步到ES的⼀个索引中，第⼆个例⼦是具有⽗⼦关系的两张表同步到⼀个索引中。在做这两个⽰例前呢，需要做⼀些准备⼯作
mysql配置
  在使⽤duckula前必需确认mysql是否开启了row模式的binlog和是否开启了gtid（mysql5.6以上），duckula⽀持两种模式的⾼可⽤(HA)，⼀：filename+offset模式，它是mysql5.6版本以下必须要⾛的模式，且现在⼤部分的binlog监听⽅案都是采⽤这种模式，⼆：gtid模式 ，这是mysql5.6以上新版本才
能使⽤的模式，它⽐旧的模式好的地⽅就是精准的做HA定位。duckula 默认的HA⽅案为gtid模式。
查看配置
我们可以通过如下命令来看是否配置成功了。
show variables like'binlog_format';#ROW
show variables like'log_bin';#ON
show variables like'gtid_mode';#ON
后⾯的注解是这些变量配置正确的情况下的结果。
mysql5.6配置
#开启binlog⽇志
log_bin=mysql-bin
binlog_format=ROW
server_id = 1
#开启gtid
gtid-mode=on
enforce-gtid-consistency=1
log-slave-updates=1
mysql8配置
mysql8默认开启了binlog，所以配置好gtid配置：
#开启gtid
server_id=1
gtid_mode=on
enforce_gtid_consistency=on
log_slave_updates=on
duckula3的配置
duckula3的任何配置都有界⾯⽀持配置，需要安装好⼀个控制台(ops)，可以参考，“安装”⼀节。同步配置前准备
在配置监听任务前需要配置好⼀些资源，⽤于辅助监听任务，需要配置的资源有：布署管理：⽤于⽀持任务的发布环境。
实例管理：⽤于配置需要进⾏监听的数据库
存储中间件管理：⽤于任务的数据流向的⽬的地
版本管理：⽤于配置duckula的版本，在安装ops时会有初始化的脚本。对它进⾏配置。
检查点服务管理：⽤于做HA的元数据存储的配置
具体的配置可以参考的第⼋节资源配置章节。
（三）⽗⼦两表join关联直连ES⽰例配置吸血鬼电影大全
附加了⼏条⽰例数据，建表语句如下：
DROP TABLE IF EXISTS`user_info`;
CREATE TABLE`user_info`(
`id`int(11)NOT NULL,
`name`varchar(255)CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL,
`age`int(11)NULL DEFAULT NULL,
`birthday`date NULL DEFAULT NULL,
`money`double NULL DEFAULT NULL,
`update_time`datetime(0)NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP(0),
`create_time`timestamp(3)NULL DEFAULT NULL,
PRIMARY KEY(`id`)USING BTREE
)
;
-- ----------------------------
-- Records of user_info
-- ----------------------------
INSERT INTO`user_info`VALUES(1,'张三',13,'2020-05-26',3000,'2021-02-18 16:24:35','2020-08-27 19:28:13.000');
INSERT INTO`user_info`VALUES(2,'李四',14,'2020-05-27',4000,'2021-02-19 16:24:53',NULL);
INSERT INTO`user_info`VALUES(3,'王五',15,'2020-05-27',5000,'2021-02-20 16:24:58',NULL);
INSERT INTO`user_info`VALUES(4,'刘六',16,'2020-05-27',6000,'2021-02-21 16:25:02',NULL);
INSERT INTO`user_info`VALUES(5,'周七',17,'2020-05-27',7000,'2021-03-01 16:25:05',NULL);
INSERT INTO`user_info`VALUES(6,'李太保',18,'2020-05-27',8000,'2021-03-02 16:25:09',NULL);
INSERT INTO`user_info`VALUES(7,'andy.zhou',NULL,'2020-05-27',9000,'2021-02-03 16:25:13',NULL);
INSERT INTO`user_info`VALUES(8,'rjzjh',NULL,'2020-05-27',10000,'2021-02-04 16:25:22',NULL);
DROP TABLE IF EXISTS`user_addr`;
CREATE TABLE`user_addr`(
`id`int(11)NOT NULL,
`user_id`int(11)NULL DEFAULT NULL,
`addr`varchar(255)CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL,
`postNo`varchar(20)CHARACTER SET latin1 COLLATE latin1_swedish_ci NULL DEFAULT NULL,
泰坦尼克号电影简介PRIMARY KEY(`id`)USING BTREE
);
-- ----------------------------
-- Records of user_addr
-- ----------------------------
INSERT INTO`user_addr`VALUES(1,1,'上海市徐汇区桂箐路7号','344125');
INSERT INTO`user_addr`VALUES(2,2,'上海市宝⼭区聚丰园路34号','344000');
INSERT INTO`user_addr`VALUES(3,2,'上海市徐汇区桂箐路8号','344520');
INSERT INTO`user_addr`VALUES(4,1,'上海市宝⼭区聚丰园路35号','344140');
为了测试各种数据的兼容情况，创建如上⽤户表，不同字段的类型都不同样。随意填写⼀些测试数据。
win7 64位旗舰版激活码注意：user_addr表是⼦表，它的“user_id”字段指向user_info表的主键“id”字段，这两张表就是最常见的⽗⼦join关系。监听任务配置
具体配置说明需要查看，第五节监听任务章节。
上⾯这些配置都是“同步配置前准备”这个章节准备好， 需要说明的⼏个字段有：
附加配置：主要完成任务监听的其它配置，此类是为了⾃动⽣成es的索引：
{'common.ate.index_join.demo':'db:test|tb:user_info|db1:test|tb1:user_addr|rela1:user_id|shardsNum:12'}
common.ate是固定值，index_join表⽰要创建join类型的索引，index_noJoin表⽰要创建单表索引， “demo”是索引名，它的值是⽤"|"分隔，db：是主表所在的库名，tb：是主表表名，db1：从表所在库名，tb1：是从表的表名，rela1是指从表的哪个字段将关联主表的主键，shardsNum：指表⽰创建⼏个分区，复制份数为默认值0，因为设置为0同步的性能最⾼，但只能⽤于测试环境或demo环境，在⽣产环境还需要在做完全量同步后通过相关⼯具设置⼀下复制份数。
版本：这个在初始化ops时，将⾃动把duckula的最新版本设置好，在此界⾯，只需下拉选择就可以了，但后⾯duckula如果有新版本，则需要⼿⼯去ops界⾯“系统配置”->“版本管理”界⾯进⾏配置。
注意点：⾃动创建的索引名要与规则⾥所配置的es索引名相同。
全量任务配置
具体配置说明需要查看，第七节全量任务章节
上⾯的配置说明点：
监听实例、⽬的中间件、布署环境与前⾯的“任务配置”相关字段⼀样的。
规则编辑和过滤规则的配置，详细说明见，第九节规则配置章节
（四）⽗⼦两表join关联通过kafka同步ES⽰例配置
监听任务配置
与第三节的“直接ES”监听配置⼤同⼩异

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。