一般的网站应用中,总会有部分二次数据(处理过的原始数据)展现给前台,比如,拿购物网站来说,购买进口奶粉最多的用户群体;哪类产品消费增长趋势最旺盛;用户的消费历史归类等都是二次数据。由于这部分数据通常是分析后的数据,而且实时性不强,因此这个过程通常是通过离线计算得到。为了展现给前台,需要将这部分数据回流到关系型数据库【离线计算集群一般都是KV存储,不支持SQL】,供前端用户查询。
对于MYSQL而言,数据回流实质就是通过mysqlimport或load data infile语句将离线计算的结果导入到数据库中。mysqlimport实质是对load data infile的封装,所以搞清楚load data infile的原理,和使用过程中需要注意的事项,就搞清楚了mysql数据回流。
load data infile语法,大家可以通过mysql官方手册查看,这里就不copy-paste了,这里主要介绍下原理和流程,下面所描述的都是针对innodb存储引擎,复制采用行级复制的情况。流程如下:
(1)主数据库进行 ‘Load’ 操作
(2)主数据库操作完成后,才开始向slave传输 load.txt文件,
(3)slave接受文件,并在 slave_load_tmpdir 目录下生成 load.txt 文件,接受并生成完整的load.txt 后,才开始读取该文件,并将数据插入到本地表中。
备注:由于innodb是事务型的,所以会把load文件的整个操作当作一个事务来处理,中途中断load操作,会导致回滚。
load data infile 结构图【来自网络】
在执行load data infile前,一定要根据实际情况设置好以下几个参数,否则很有可能因为参数设置不对,导致load失败。
slave_load_tmpdir
含义:load data infile 存放临时文件的目录
建议:这个目录所在磁盘空间应该足够大,防止因为目录空间不足,导致失败的情况。
max_allowed_packet
含义:客户端/服务器之间通信的缓存区的最大大小。
最大值:1G
建议:因此对于含有大字段(BLOB,TEXT)的表操作,或主备之间含有大事务传递时,需要调大该值,否则会出现max_allowed_packet不够大的错误。
max_binlog_cache_size
含义:用来限制用来缓存多语句事务的缓冲区总大小。如果某个事务大于该值,将会失败并回滚。
最大值:4G(32位),16PB(64位)
建议:对于load data infile,或mysqlimport导入大文件时,由于是作为一个事务,很可能导致max_binlog_cache_size不够,而出现错误导致回滚的情况。
max_binlog_size
含义:事务以一个块写入二进制日志,当超过max_binlog_size时,文件进行切换。
于max_binlog_size。
最大值:1G
建议:这个值设置不会导致执行报错的情况。但是,有一点要注意,单个事务的binlog不会跨binlog文件,因此大事务可能导致binlog文件超出max_binlog_size值。
本人在使用mysql进行load时,遇到过好几个问题,都是与以上几个参数有关。
1.max_binlog_cache_size不够大,主库导入出错,或从库复制出错;
解决方法:调大该值
2.max_allowed_packet不够大,导致从库io_thread拉binlog失败,主备复制中断。
解决方法:
1.调大该值
2.重新建立复制关系
(1).记录目前复制的位置(Relay_Master_Log_File, Exec_Master_Log_Pos);
(2).reset slave [清理掉无效的relay-log,和master-info信息]
(3).执行change master to 命令
(4).start slave
大部分情况下,执行第一步后,start slave应该就可以了;但我碰到过,重启复制后依然报错的情况,主要原因是max_allowed_packet不够大,relay-log只记录了事务的一部分,复制报错。那么,通过重建复制关系,则会重新开始拉事务的binlog,relay-log完整后,就不存在问题了。