IP的设置:A主机 IP:10.10.0.119;Mask:255.255.0.0;B主机 IP:10.10.8.112;Mask:255.255.0.0
在IP设置完成以后,需要确定两主机的防火墙确实已经关闭。可以使用命令service iptables status查看防火墙状态。如果防火墙状态。
为仍在运行。使用service iptables stop来停用防火墙。如果想启动关闭防火墙,可以使用setup命令来禁用或定制。最终以两台主机可以相互ping通为佳。
3.2 配置A主(master) B从(slave)模式;3.2.1 配置A 为master。
增加一个用户同步使用的帐号:
GRANT FILE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’
GRANTREPLICATION SLAVE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’。
赋予10.10.8.112也就是Slave机器有File权限,只赋予Slave机器有File权限还不行,还要给它REPLICATION SLAVE的权限才可以。
增加一个数据库作为同步数据库:create database test
创建一个表结构:create table mytest (username varchar(20),password varchar(20))
修改配置文件:修改A的/etc/my.cnf文件。
在my.cnf配置项中加入下面配置:
server-id = 1 #Server标识
log-bin
binlog-do-db=test #指定需要日志的数据库
重起数据库服务:
service mysqld restart
查看server-id:
show variable like ‘server_id’。
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的一张表中的其他问题,我就不赘述了。欢迎分享,转载请注明来源:内存溢出
评论列表(0条)