使用kettle的数据库增量备份与全量备份

背景

冷热库备份，热库保留最近七天的原始数据，其余的数据都备份到冷库，平均每天约产生300G的原始数据。
热库采用业务上的id和时间每一天来分表，并且有一个分区的主表，冷库只按业务id来分表，天的数据都聚合在一起。
使用kettle进行数据库的数据备份转移，有对历史数据做全量备份和对增量数据做每天的增量数据的两种方案。

如下所示：
热库：
分区主表： tableName_业务id
分区子表： tableName_业务id_日期
冷库：
分区主表： tableName_业务id
分区子表： tableName_业务id_日期

对于某些数据量不是太大的表，在热库因为考虑性能的原因，依旧会按天进行分表，但是备份到冷库之后会很少用到，一般都是原始的ods表，只有项目改了方案或者其他情况，需要重跑数据或者做数据清洗，才有可能使用到冷库的数据。所以某些数据量不是太大的表可以在冷库直接做主表存储，不做按天分表（不分表或者按月分表）。天表数据达到几百万的，冷库依旧是做按天分表。

单表对主表的全量备份

由于是全量备份，需要对所有热库的数据进行备份到冷库，其中数据量会很大，可能需要很长的备份时长，备份过程可能会出现数据库报错或者连接数不足等非意料中的异常，为了方便排查未成功备份的数据，使用热库子表对冷库主表备份的方式。当备份出现问题时，直接排查log或者邮件，直接重新备份发生错误的子表就行。

使用update_time的增量备份

增量备份，如果和全量备份一样使用子表全量备份到主表的方式的话，因为热库会保留七天的数据，再加上前几天的天表，可能会有历史数据遗留的数据插入进去，那么可能就需要每一天做增量备份的时候，都将热库存在的七天的表都重新备份一次冷库中去。但是前面六天绝大部分数据是不需要再次备份的，这样会浪费比较多的性能。

一般是使用update_time这个字段来进行备份的，每次备份都会先查询冷库的表中最大的更新时间maxUpdateTime，然后根据这个时间去热库的表中查询出所有update_time > maxUpdateTime的数据，再将其备份到冷库中去，这样用作同步备份的就只有新增和修改过的这一部分数据了。

使用Kettle Spoon

1、Kettle Spoon的循环，通过一个步骤来引入要循环的变量，另外后面跟一个步骤来循环执行每一个变量

通过SQL获取表名（上图中的获取表类型）：

表循环任务：

2、Insert/Update和Table Output
备份的时候一般就是选用这两种方式备份，前面一种会插入数据或者更新数据（如果主键重复），后面一种就是直接插入数据，如果主键重复则会直接报错。

需要注意的是，Insert/Update及其消耗CPU资源，而Table Output则性能会好很多，速度也会快很多。如果确定插入的数据完全没有主键重复的数据的话，最好是使用Table Output进行备份。

3、对于容易出错的地方都应该做异常处理机制（如与数据库交互的所有操作），如果某些地方在执行的地方报错了而没有异常处理机制，那么这个任务就会直接终止。

4、使用邮件，配置错误信息
有一个Mail的组件，可以拉出来直节配置，对于邮件地址、账号密码等配置就不多说了，主要是在程序发生错误的时候，将发生的错误信息附加在邮件的附件中。


配置好上面两个步骤，当发生异常时，就会发送一个异常邮件出来，并且邮件会携带一个包含错误日志的附件过来。