本文介绍如何通过日志服务控制台创建Logtail采集配置来采集MySQL Binlog。
前提条件
原理
- Logtail将自己伪装为MySQL Slave节点向MySQL master节点发送dump请求。
- MySQL master节点收到dump请求后,会将自身的Binlog实时发送给Logtail。
- Logtail对Binlog进行事件解析、过滤、数据解析等操作,并将解析好的数据上传到日志服务。

功能特点
- 通过Binlog增量采集数据库的更新操作数据,性能优越。支持RDS等MySQL协议的数据库。
- 支持多种数据库过滤方式。
- 支持设置Binlog位点。
- 支持通过Checkpoint机制同步保存状态。
使用限制
- Logtail 1.0.31及以上版本支持MySQL 8.0。
- MySQL必须开启Binlog,且Binlog必须为row模式(RDS默认已开启Binlog)。
# 查看是否开启Binlog mysql> show variables like "log_bin"; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | ON | +---------------+-------+ 1 row in set (0.02 sec) # 查看Binlog类型 mysql> show variables like "binlog_format"; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | binlog_format | ROW | +---------------+-------+ 1 row in set (0.03 sec)
- ServerID唯一,即需要同步的MySQL的Slave ID唯一。
- RDS限制
- 无法直接在RDS服务器上安装Logtail,您需要将Logtail安装在能连通RDS实例的服务器上。
- RDS备库不支持Binlog采集,您需要配置RDS主库进行采集。
应用场景
- 增量订阅数据库改动进行实时查询与分析。
- 数据库操作审计。
- 使用日志服务对数据库更新信息进行自定义查询分析、可视化、对接下游流计算、导入MaxCompute离线计算、导入OSS长期存储等操作。
注意事项
建议您适当放开对Logtail的资源限制以应对流量突增等情况,避免Logtail因为资源超限被强制重启,对您的数据造成不必要的风险。
您可以通过/usr/local/ilogtail/ilogtail_config.json文件修改相关参数。更多信息,请参见设置Logtail启动参数。
{
...
"cpu_usage_limit":2,
"mem_usage_limit":2048,
...
}
数据可靠性
- 数据漏采集:Logtail与MySQL服务器之间的网络长时间中断时,可能会产生数据漏采集情况。
如果Logtail和MySQL master节点之间的网络发生中断,MySQL master节点仍会不断地产生新的Binlog数据并且回收旧的Binlog数据。当网络恢复,Logtail与MySQL master节点重连成功后,Logtail会使用自身的checkpoint向MySQL master节点请求更多的Binlog数据。但由于长时间的网络中断,它所需要的数据很可能已经被回收,这时会触发Logtail的异常恢复机制。在异常恢复机制中,Logtail会从MySQL master节点获取最近的Binlog位置,以它为起点继续采集,这样就会跳过checkpoint和最近的Binlog位置之间的数据,导致数据漏采集。
- 数据重复采集:当MySQL master节点和slave节点之间的Binlog序号不同步时,发生了主备切换事件,可能会产生数据重复采集情况。
在MySQL主备同步的设置下,MySQL master节点会将产生的Binlog同步给MySQL slave节点,MySQL slave节点收到后存储到本地的Binlog文件中。当MySQL master节点和slave节点之间的Binlog序号不同步时,发生了主备切换事件,以Binlog文件名和文件大小偏移量作为checkpoint的机制将导致数据重复采集。
例如,有一段数据在MySQL master节点上位于
(binlog.100, 4)
到(binlog.105, 4)
之间,而在MySQL slave节点上位于(binlog.1000, 4)
到(binlog.1005, 4)
之间,并且Logtail已经从MySQL master节点获取了这部分数据,将本地checkpoint更新到了(binlog.105, 4)
。如果此时发生了主备切换且无任何异常发生,Logtail将会继续使用本地checkpoint(binlog.105, 4)
去向新的MySQL master节点采集binlog。但是因为新的MySQL master上的(binlog.1000, 4)
到(binlog.1005, 4)
这部分数据的序号都大于Logtail所请求的序号,MySQL master将它们返回给Logtail,导致重复采集。
操作步骤
修改本地配置
如果您没有在插件配置中输入真实的Host、User、Password等信息,可以在插件配置下发到本地后进行手动修改。
后续步骤
Logtail采集Binlog到日志服务后,您可以在日志服务控制台上查看日志。例如:对user_info
数据库下的SpecialAlarm
表分别执行INSERT
、UPDATE
、DELETE
操作,数据库表结构、数据库操作及日志样例如下所示。
- 表结构
CREATE TABLE `SpecialAlarm` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `time` datetime NOT NULL, `alarmtype` varchar(64) NOT NULL, `ip` varchar(16) NOT NULL, `count` int(11) unsigned NOT NULL, PRIMARY KEY (`id`), KEY `time` (`time`) USING BTREE, KEY `alarmtype` (`alarmtype`) USING BTREE ) ENGINE=MyISAM AUTO_INCREMENT=1;
- 数据库操作
执行INSERT、DELETE和UPDATE三种操作。
insert into specialalarm (`time`, `alarmType`, `ip`, `count`) values(now(), "NO_ALARM", "10.10.**.***", 55); delete from specialalarm where id = 4829235 ; update specialalarm set ip = "10.11.***.**" where id = "4829234";
为zc.specialalarm
创建一个索引。ALTER TABLE `zc`.`specialalarm` ADD INDEX `time_index` (`time` ASC);
- 日志样例
在查询分析页面,查看每种操作对应的日志,日志样例如下所示。
- INSERT语句
__source__: 10.30.**.** __tag__:__hostname__: iZbp145dd9fccu***** __topic__: _db_: zc _event_: row_insert _gtid_: 7d2ea78d-b631-11e7-8afb-00163e0eef52:536 _host_: *********.mysql.rds.aliyuncs.com _id_: 113 _table_: specialalarm alarmtype: NO_ALARM count: 55 id: 4829235 ip: 10.10.***.*** time: 2017-11-01 12:31:41
- DELETE语句
__source__: 10.30.**.** __tag__:__hostname__: iZbp145dd9fccu**** __topic__: _db_: zc _event_: row_delete _gtid_: 7d2ea78d-b631-11e7-8afb-00163e0eef52:537 _host_: *********.mysql.rds.aliyuncs.com _id_: 114 _table_: specialalarm alarmtype: NO_ALARM count: 55 id: 4829235 ip: 10.10.**.*** time: 2017-11-01 12:31:41
- UPDATE语句
__source__: 10.30.**.** __tag__:__hostname__: iZbp145dd9fccu**** __topic__: _db_: zc _event_: row_update _gtid_: 7d2ea78d-b631-11e7-8afb-00163e0eef52:538 _host_: *********.mysql.rds.aliyuncs.com _id_: 115 _old_alarmtype: NO_ALARM _old_count: 55 _old_id: 4829234 _old_ip: 10.10.22.133 _old_time: 2017-10-31 12:04:54 _table_: specialalarm alarmtype: NO_ALARM count: 55 id: 4829234 ip: 10.11.***.*** time: 2017-10-31 12:04:54
- DDL(data definition language)语句
__source__: 10.30.**.** __tag__:__hostname__: iZbp145dd9fccu**** __topic__: _db_: zc _event_: row_update _gtid_: 7d2ea78d-b631-11e7-8afb-00163e0eef52:539 _host_: *********.mysql.rds.aliyuncs.com ErrorCode: 0 ExecutionTime: 0 Query: ALTER TABLE `zc`.`specialalarm` ADD INDEX `time_index` (`time` ASC) StatusVars:
字段 说明 _host_
数据库host名称。 _db_
数据库名称。 _table_
表的名称。 _event_
事件类型。 _id_
本次采集的自增ID,从0开始,每次采集一个binlog事件后加1。 _gtid_
全局事务ID。 _filename_
Binlog文件名。 _offset_
Binlog文件大小偏移量,该值只会在每次commit后更新。 - INSERT语句