MySQL Binlog导入日志服务最佳实践

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 本文为您介绍使用SLS导入MySQL Binlog的使用场景和最佳实践。

日志服务SLS是云原生观测和分析平台,为Log、Metric、Trace等数据提供大规模、低成本、实时的平台化服务,同时提供一站式数据采集、加工、查询与分析、可视化、告警、消费与投递等功能。本文将会重点介绍如何通过SLS主动接入将MySQL BInlog中的数据导入到SLS。

目标读者

数字化系统开发运维(DevOps)工程师、稳定性工程师(SRE)、可观测平台运维人员等。

应用场景

适用于数据量较大且性能要求较高的数据同步场景。

  • 增量订阅数据库改动进行实时查询与分析。
  • 数据库操作审计。
  • 使用日志服务对数据库更新信息进行自定义查询分析、可视化、对接下游流计算、导入MaxCompute离线计算、导入OSS长期存储等操作。

方案架构

方案架构图

SLS主动接入内部实现了MySQL Slave节点的交互协议,具体流程如下所示。

  1. SLS将自己模拟为MySQL Slave节点向MySQL master节点发送dump请求。
  2. MySQL master节点收到dump请求后,会将自身的Binlog实时发送给SLS。
  3. SLS对Binlog进行事件解析、过滤、数据解析等操作,并将解析好的数据上传到日志服务。

方案优势

使用SLS导入Binlog数据,具备如下优势:

  • 低成本,免机器成本和运维成本,直接托管到SLS。
  • 支持通过Checkpoint机制同步保存状态。
  • 支持海量数据写入,性能优越。
  • 支持Binlog数据导入过程中的在线DDL变更。
  • 提供Binlog原始顺序的全局自增ID,供消费端保序使用。

方案实施

前提条件

  • MySQL 必须开启Binlog,且Binlog必须为row模式
  • 需保证配置的用户具有需要采集的数据库读权限以及MySQL REPLICATION权限,示例如下(本示例中创建了一个账号sls_binlog,密码为sls_binlog,授予sls_binlog账号对于所有表的SELECT权限和REPLICATION权限,最后FLUSH PRIVILEGES立即生效):
CREATE USER sls_binlog IDENTIFIED BY'sls_binlog';GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON*.* TO 'sls_binlog'@'%';-- GRANT ALL PRIVILEGES ON *.* TO 'sls_binlog'@'%' ;FLUSH PRIVILEGES;
  • 如果是RDS或ECS自建MySQL需要在安全组中添加白名单。请根据数据导入任务所在Project的地域和数据库所在的网络环境,添加对应的IP地址白名单。IP地址列表请参见IP地址白名单
  • 已创建Project和Logstore。具体操作,请参见创建Project创建Logstore

配置参数说明

下表列出了Binlog导入涉及到的参数:

  • 如果是专有网络下ECS上自建的MySQL数据库,需选中使用VPC地址,ECS自建数据库,并设置如下参数。

参数

说明

VPC实例ID

ECS实例所属VPC的ID。

ECS实例IP

ECS实例的私网IP地址。

  • 如果是公网环境下的RDS MySQL数据库或其他场景下自建的MySQL数据库,取消选中使用VPC地址,并设置如下参数。

参数

说明

数据库公网IP或者域名

MySQL数据库的公网IP地址或者域名。

公共配置

参数

说明

配置名称

设置配置的名称

MySQL端口

数据库端口

用户名

需保证配置的用户具有数据库读权限以及MySQL REPLICATION权限

密码

数据库密码

高级配置

数据库表白名单

包含的表名称(包括db,例如test_db.test_table

),为正则表达式,若某表不符合IncludeTables任一条件则该表不会被采集,默认采集表.*\\..*

数据库表黑名单

忽略的表名称(包括db,例如test_db.test_table

),为正则表达式,若某表符合ExcludeTables任一条件则该表不会被采集,默认排除表"mysql\\..*"

开始的binlog文件名

首次采集的Binlog文件名。不设置时,默认从当前时间点开始采集。
如果想从指定位置开始采集,可以查看当前的Binlog文件以及文件大小偏移量,并将StartBinName、StartBinlogPos设置成对应的值,示例如下。
mysql> show binary logs;
+---------------+-----------+-----------+
| Log_name      | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000001 |     37196 | No        |
+---------------+-----------+-----------+
1 row in set (0.00 sec)

当指定StartBinName时,第一次采集会产生较大流量。

开始的binlog位置

首次采集的Binlog文件的偏移量,不设置时,默认为0。

开始的GTID

不设置时,默认从最新位置开始监听。

采集DDL

是否采集DDL(data definition language)事件数据。不设置时, 默认为false,表示不收集DDL事件数据。

该选项不支持IncludeTables和ExcludeTables过滤。

采集Insert

是否采集insert事件的数据。不设置时,默认为true。设置为false时,表示将不采集insert事件数据。

采集Update

是否采集update事件的数据。不设置时,默认为true。设置为false时,表示不采集update事件数据。

采集Delete

是否采集delete事件的数据。不设置时,默认为true。设置为false时,表示不采集delete事件数据。

采集Event元数据

是否采集Event元数据,默认为false,不采集。包含字段event_size、event_server_id。

使用event_time作为日志时间

默认false,使用系统时间。为true时,使用binlog日志上的even_time作为日志时间

控制台配置流程

以下是主要的配置步骤:

  1. 登录SLS控制台,在Project列表页面,选择已有的Project或者创建新的Project
  2. 日志库标签页,选择已有时序库或者单击+图标创建新的时序库
  3. 在日志库的数据接入 > 数据导入,单击+图标,然后选择MySQL Binlog-数据导入

  1. 在数据源配置页面,配置相关信息 (参考配置参数说明)

  1. 点击预览按钮,确保配置符合预期。如果配置有问题,则预览操作会返回具体的错误信息。预览时,如果Binlog没有实时更新,会出现预览超时。
  2. 点击下一步按钮,完成Binlog导入配置。
  3. 到对应的日志库数据是否正确接入(大约需要等待1分钟左右,数据会写入到日志库中)。

数据字段

DML数据字段

需要说明的是,将Binlog数据导入到SLS的过程中,后台服务会自动添加5个相关的元数据字段,它们分别是_db_、_event_、_event_time_、_host_、_sid_以及_table_,具体含义如下表所示:

元数据字段名称

具体含义

_db_

数据库名

_event_

数据操作名,包括row_update、row_insert、row_delete和ddl

_event_time_

数据操作时间

_host_

数据源地址

_sid_

全局自增ID,在导入开始执行后,从1开始自增

_table_

数据库表名

DDL数据字段

DDL的元数据字段相比DDL字段缺少了_table_字段

查看任务状态

在完成配置后,可以在对应日志库的数据接入>数据导入下,看找到对应的任务配置名称,点击该配置后,可以看到对应配置的概览信息以及可以进行的相关操作(支持修改、停止以及删除),如下图所示。其中,配置概览中,包含了基础信息以及统计报表两个部分。

基础信息

基础信息部分相对简单,主要包含了任务的配置内容以及当前任务的状态。配置内容无需具体介绍,这里详细说明下任务的状态及其对应的操作。

任务的状态可以是运行中、已停止、成功以及失败,其中成功和失败状态是任务的终态(对于Binlog导入而言,这两个状态不应该发生)。当任务处于运行中时,可以选择停止任务;而当任务已停止时,则可以选择启动任务,此时从之前中断的位置继续读取BInlog数据。

统计报表

统计报表部分,展示了任务运行过程中的核心指标数据,用户可以清楚地看到云监控数据导入的细节,比如数据读取速率、是否出现非预期的错误、数据延迟等。分为以下几类:

1.读写总量

2.处理速率

3.运行异常

任务运行过程中,出现的异常都会记录在运行异常报表中,结合告警(用户可以按需自定义告警),用户可以实时地了解任务异常的发生并及时进行处理。比如,下图中展示的异常来自用户配置了错误的启动位置,导致BInlog读取异常,默认从最新位置开始读取。

4.运行状态

典型场景

黑白名单过滤

数据库表黑白名单采用正则化的方式进行过滤,多个table采用;分开。默认情况下,Binlog的导入会过滤掉mysql库中的所有消息(RDS的ha_health心跳包会影响数据采集)。

自定义起始位置

默认情况下,Binlog的数据导入会从当前Binlog的最新位置开始采集。创建任务时,我们也允许用户使用自定义的起始采集位置。需要注意的是,如果新建任务时自定义的起始位置无法被找到或者位置错误,会从最新位置开始采集。如果在修改配置时自定义起始位置无法被找到或者位置错误,会清空checkpoint并从最新位置开始采集。

固定类型数据采集

默认情况下,在导入Binlog数据时采集所有的DML和DDL消息。在创建导入任务或者更新已有任务时,我们也允许用户通过高级配置自定义需要采集的消息类型,如下图所示。

自定义时间戳

默认情况下,在导入Binlog数据时会使用消费端接受到消息的时间。在创建导入任务或者更新已有任务时,我们也允许用户通过使用event_time作为日志时间配置Binlog时间戳(即元数据中的even_time字段)作为SLS消息的时间戳,如下图所示。

参考

  • SLS(日志服务)云原生观测分析平台:https://www.aliyun.com/product/sls
  • 欢迎扫群加入阿里云-日志服务(SLS)技术交流或关注公众号, 获得第一手资料与支持:

相关实践学习
2分钟自动化部署人生模拟器
本场景将带你借助云效流水线Flow实现人生模拟器小游戏的自动化部署
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
20天前
|
SQL 关系型数据库 MySQL
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
MySQL事务日志-Undo Log工作原理分析
|
1月前
|
SQL 存储 关系型数据库
Mysql并发控制和日志
通过深入理解和应用 MySQL 的并发控制和日志管理技术,您可以显著提升数据库系统的效率和稳定性。
124 10
|
1月前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
79 3
|
1月前
|
SQL 关系型数据库 MySQL
数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog
《数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog》介绍了如何利用MySQL的二进制日志(Binlog)恢复误删除的数据。主要内容包括: 1. **启用二进制日志**:在`my.cnf`中配置`log-bin`并重启MySQL服务。 2. **查看二进制日志文件**:使用`SHOW VARIABLES LIKE 'log_%';`和`SHOW MASTER STATUS;`命令获取当前日志文件及位置。 3. **创建数据备份**:确保在恢复前已有备份,以防意外。 4. **导出二进制日志为SQL语句**:使用`mysqlbinlog`
94 2
|
1月前
|
SQL 存储 缓存
MySQL进阶突击系列(02)一条更新SQL执行过程 | 讲透undoLog、redoLog、binLog日志三宝
本文详细介绍了MySQL中update SQL执行过程涉及的undoLog、redoLog和binLog三种日志的作用及其工作原理,包括它们如何确保数据的一致性和完整性,以及在事务提交过程中各自的角色。同时,文章还探讨了这些日志在故障恢复中的重要性,强调了合理配置相关参数对于提高系统稳定性的必要性。
|
2月前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
774 31
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
1月前
|
监控 安全 Apache
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
|
3月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
418 3
|
1月前
|
存储 监控 安全
什么是事件日志管理系统?事件日志管理系统有哪些用处?
事件日志管理系统是IT安全的重要工具,用于集中收集、分析和解释来自组织IT基础设施各组件的事件日志,如防火墙、路由器、交换机等,帮助提升网络安全、实现主动威胁检测和促进合规性。系统支持多种日志类型,包括Windows事件日志、Syslog日志和应用程序日志,通过实时监测、告警及可视化分析,为企业提供强大的安全保障。然而,实施过程中也面临数据量大、日志管理和分析复杂等挑战。EventLog Analyzer作为一款高效工具,不仅提供实时监测与告警、可视化分析和报告功能,还支持多种合规性报告,帮助企业克服挑战,提升网络安全水平。
|
3月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1791 14
MySQL事务日志-Redo Log工作原理分析