深入理解MySQL流模式
作者：老王笔记
核心概念一句话总结
MySQL Binlog 流模式是指一种实时、持续不断地读取二进制日志（Binary Log）的技术方法，而不是一次性下载整个日志文件。 它允许下游系统（如从库、数据同步工具）像打开一个“水龙头”一样，几乎无延迟地获取数据库的每一个数据变更事件。
1. 背景知识：什么是 Binlog？
首先，要理解流模式，必须先了解 Binlog 本身。
Binlog (Binary Log)： 是 MySQL 服务器层面的一种逻辑日志，它忠实地记录了所有对数据库结构和内容进行修改的操作（DDL & DML），例如
INSERT、UPDATE、DELETE、CREATE TABLE等。它的核心用途： 数据复制 (Replication) 和 数据恢复 (Point-in-Time Recovery)。
在主从复制中，主库将 Binlog 发送给从库，从库重放这些操作，从而保持数据一致。
你可以用全量备份 + Binlog 来将数据库恢复到过去的任意时间点。
默认情况下，Binlog 是以文件形式存储在磁盘上的（例如 mysql-bin.000001, mysql-bin.000002）。
2. 传统方式 vs. 流模式
传统文件方式 (非流式)
- 等待文件写完： 主库会先将日志写入一个完整的文件（例如
mysql-bin.000001），达到一定大小后（由max_binlog_size控制）才切换到下一个文件。 - 从库拉取： 从库的 I/O Thread 会定期检查主库上是否有新的 Binlog 文件或新的内容。
- 批量传输： 当发现新内容时，从库会请求整个文件或文件的一部分，通过网络传输过来。
- 问题： 这种方式存在延迟。从库必须等待主库完成一个文件的写入后才能开始拉取，这在需要极低延迟复制的场景下是不可接受的。
流模式 (Streaming)
- 实时事件流： 主库不再等待整个文件写完。只要事务被提交（Commit），记录该事务的 Binlog 事件（Event） 会立即被放入一个网络流中。
- 持续推送： 主库的 Binlog Dump Thread 会持续不断地将这个流推送给从库（或其它客户端）。
- 从库实时接收： 从库的 I/O Thread 实时地接收这个流，并立即将其写入本地的中继日志 (Relay Log)，SQL Thread 随后几乎实时地重放这些操作。
- 优势： 极大降低了复制延迟（Replication Lag），从库可以近乎实时地与主库保持同步。
一个简单的比喻：
- 传统文件方式： 就像等作者写完一整章后，你才能把这一章拿去阅读。
- 流模式： 就像作者一边写，你一边在他身后看他写的每一个句子，几乎是同步的。
3. 流模式是如何工作的？(技术实现要点)
流模式的核心依赖于 MySQL 的复制协议 和 Binlog 事件流。
连接与认证： 从库（或客户端工具）使用
CHANGE MASTER TO命令指定主库信息，并启动复制线程。请求Binlog流： 从库会向主库发送一个请求，内容包括：
起始位置： 从哪个 Binlog 文件名和文件内的位置（Position）开始读取（例如
mysql-bin.000001:120）。GTID： 在基于 GTID 的复制中，则是从哪个 GTID 集合开始。
Dump Thread 流式推送： 主库上的 Binlog Dump 线程 被创建。它不会一次性发送所有数据，而是：
从指定的位置开始，读取 Binlog 事件。
一旦有新事件产生，就立即通过网络连接发送给从库。
如果暂时没有新事件，这个线程会保持连接并等待，直到有新事件产生或连接超时中断。
持续流动： 这个过程会一直持续，只要复制关系存在，事件流就会像水流一样源源不断地从主库流向从库。
4. 谁在使用 Binlog 流模式？
MySQL 原生主从复制： 这是最核心的使用者。流模式是保证主从同步低延迟的基础。
数据同步与异构复制工具： 许多第三方工具也利用 MySQL 协议模拟一个“从库”，来订阅 Binlog 流。
Canal： 阿里巴巴开行的用于 MySQL 数据库增量日志解析和同步的工具。
Debezium： 一个流行的 CDC (Change Data Capture) 工具，用于将数据库变更实时流式传输到 Kafka 等消息队列。
MaxWell, Flink CDC 等。
备份工具： 一些高级的备份工具可以通过流模式实时获取 Binlog，从而实现真正的实时增量备份。
5. 重要概念：GTID 和 位点 (Position)
在流模式中，准确地指定从何处开始读取流至关重要。有两种方式：
- 基于位点的复制 (Position-Based)： 使用 Binlog 文件名和文件内的偏移量（如
mysql-bin.000001:120）作为坐标。这是较传统的方式。 - 基于 GTID 的复制 (GTID-Based)： 使用 GTID (Global Transaction Identifier)，即全局事务标识符。每个提交的事务都有一个唯一的 GTID（例如
server-uuid:transaction-id）。这种方式更现代化、更强大，可以避免因为日志文件切换或位置点不准确导致的主从数据不一致问题。流模式强烈推荐使用 GTID。
总结
| 特性 | 传统文件方式 | 流模式 (Streaming) |
|---|---|---|
| 数据传输方式 | 批量传输整个文件或大块数据 | 持续流式传输单个事件 |
| 延迟 | 较高（文件级延迟） | 极低（近实时） |
| 资源占用 | 网络带宽使用有波峰波谷 | 网络带宽使用更平稳 |
| 本质 | 拉取 (Pull)： 从库主动去要 | 推送 (Push)： 主库主动实时发送 |
| 适用场景 | 对延迟要求不高的环境 | 现代数据库复制、实时数据同步、CDC |
总而言之，MySQL Binlog 流模式是现代数据库生态系统的基石，它使得实时数据同步、低延迟的读写分离、以及构建实时数据管道成为可能。
到此这篇关于深入理解MySQL流模式的文章就介绍到这了,更多相关MySQL 流模式内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！