mysql同步数据到hive---binlog方式

mysql同步数据到hive大部分公司目前都是走的jdbc的方式。 这种方式有两个好处： 也有不好的地方： 这一步最主要的细节是将mysql库的所有binlog数据全部打入一个kafka topic，格式使用json。格式如下： 这一步的主要的细节在于写入到hdfs的结构，以及为什么不直接写入hive。 不写入到hive表的原因在于，binlog的数据结构是不固定的，而hive的结构相对是比较固定的。如果要写入到hive的话，就需要将不同的表的binlog写入到不同的hive表中，这个维护成本太高了。而且spark其实可以直接读取hdfs的json文件，因此直接放hdfs就好了。 写入到hdfs的话，考虑到后续读这个数据是要按照表去读增量数据，所以写入的目录一定是要带日期和表名称的。我这边用的目录结构是这样的： 也就是说要在flink根据数据所属的db、table_name、和日期将数据写入到不同的目录里。 在这一步的处理的过程中遇到了一些比较重要的参数问题。 2.如上所述checkpoint的时间间隔。不仅仅会影响checkpoint的频率，而且会影响hdfs文件的大小，而hdfs文件的大小可能会对hdfs的性能有很大影响。这个值如果太大，就会造成数据延迟太高，如果太小就会造成小文件过多。我这边设置的是5分钟。 细心的看官，这个时候会问了，既然你的目录是分table的，那么每个table每5分钟的binlog数据量是不一样的。对于某些大的mysql表，我们可能每5分钟生成一个文件还能接受。对于一些比较小的表，每五分钟生成一个文件那么文件就会非常小。所以我这边又做了一层的筛选，我把mysql的大的表筛选出来，只同步大的表到hdfs，用以binlog的数据同步。因为本身binlog的方式同步mysql数据为的就是节约mysql的读取压力，而小的表对于不会有太大压力，这些表可以直接通过jdbc的方式去同步。 这个是整个环节里面最复杂的一部分，涉及的细节也比较多。 首先，我们要明确一下总体的思路是什么。总体的思路就是要读取hdfs上的老的历史数据，然后和新的binlog数据合并生成新的快照。 其实这中间还涉及到一些其他的细节，比如mysql表结构变更，或者mysql和hive的数据结构不一致的情况。 另外我们这边还存在多个db的相同的表导入到hive的一张表中的其他问题，我就不赘述了。

在MySQL服务器1中，添加如下配置：

在MySQL服务器2中，添加如下设置：

在这里两台MySQL的配置文件，需要对auto_increment_offset字段，设定不同值。因为如果mysql中有自增长字段，不设定这个参数会起冲突，会报duplicate....的报错。

auto_increment_offset表示自增长字段从那个数开始，他的取值范围是1 .. 65535

auto_increment_increment表示自增长字段每次递增的量，其默认值是1，取值范围是1 .. 65535

做主主同步配置时，需要将两台服务器的auto_increment_increment增长量都配置为2，而要把auto_increment_offset分别配置为1和2，这样可以避免两台服务器同时做更新时,自增长字段的值之间发生冲突。

配置好两台mysql的my.cnf配置文件后，service mysqld restart 重启mysql服务。

在Mysql服务器1中，

在MySQL服务器2中，做如上同样的 *** 作，然后将服务器1的file和position值设定到服务器2中，服务器2的file和position值输入到服务器1中。

在MySQL服务器1中，输如下命令：

在MySQL服务器2中，输如下命令：

范例如下图：

配置完后，分别在两台服务器上输show slave status

如果出现如下两个字段都是on的状态，则主主备份搭建完成。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

在实际测试配置中，由于MySQL服务器2是克隆的MySQL服务器1的，所以start slave 后，show slave status 出现了Slave_IO_Running: No ,然后有如下报错信息。告知是因为两个MySQL服务器的UUID相重复了。

只需要，将basedir,即/use/local/mysql/data中的auto.cnf文件删掉后，重启mysql，就会出现新的auto.cnf文件，里面有新的UUID

主从同步主要是以binlog日志作为文件同步机制，具体如下

主从同步使得数据可以从一个数据库服务器复制到其他服务器上，在复制数据时，一个服务器充当主服务器（master），其余的服务器充当从服务器（slave）。因为复制是异步进行的，所以从服务器不需要一直连接着主服务器，从服务器甚至可以通过拨号断断续续地连接主服务器。通过配置文件，可以指定复制所有的数据库，某个数据库，甚至是某个数据库上的某个表。

使用主从同步的好处：

通过增加从服务器来提高数据库的性能，在主服务器上执行写入和更新，在从服务器上向外提供读功能，可以动态地调整从服务器的数量，从而调整整个数据库的性能。

提高数据安全-因为数据已复制到从服务器，从服务器可以终止复制进程，所以，可以在从服务器上备份而不破坏主服务器相应数据

在主服务器上生成实时数据，而在从服务器上分析这些数据，从而提高主服务器的性能

注意，mysql是异步复制的，而MySQL Cluster是同步复制的。有很多种主从同步的方法，但核心的方法有两种，Statement Based Replication（SBR）基于SQL语句的复制，另一种是Row Based Replication（RBR）基于行的复制，也可以使用Mixed Based Replication（MBR）。在mysql5.6中，默认使用的是SBR。而mysql 5.6.5和往后的版本是基于global transaction identifiers(GTIDs)来进行事务复制。当使用GTIDs时可以大大简化复制过程，因为GTIDs完全基于事务，只要在主服务器上提交了事务，那么从服务器就一定会执行该事务。

---