一般的网站应用中，总会有部分二次数据（处理过的原始数据）展现给前台，比如，拿购物网站来说，购买进口奶粉最多的用户群体；哪类产品消费增长趋势最旺盛；用户的消费历史归类等都是二次数据。由于这部分数据通常是分析后的数据，而且实时性不强，因此这个过程通常是通过离线计算得到。为了展现给前台，需要将这部分数据回流到关系型数据库【离线计算集群一般都是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完整后，就不存在问题了。