核心概念一句話總結(jié)

MySQL Binlog 流模式是指一種實(shí)時(shí)、持續(xù)不斷地讀取二進(jìn)制日志（Binary Log）的技術(shù)方法，而不是一次性下載整個(gè)日志文件。 它允許下游系統(tǒng)（如從庫(kù)、數(shù)據(jù)同步工具）像打開一個(gè)“水龍頭”一樣，幾乎無(wú)延遲地獲取數(shù)據(jù)庫(kù)的每一個(gè)數(shù)據(jù)變更事件。

1. 背景知識(shí)：什么是 Binlog？

首先，要理解流模式，必須先了解 Binlog 本身。

• Binlog (Binary Log)： 是 MySQL 服務(wù)器層面的一種邏輯日志，它忠實(shí)地記錄了所有對(duì)數(shù)據(jù)庫(kù)結(jié)構(gòu)和內(nèi)容進(jìn)行修改的操作（DDL & DML），例如 INSERT、UPDATE、DELETE、CREATE TABLE 等。

• 它的核心用途： 數(shù)據(jù)復(fù)制 (Replication) 和 數(shù)據(jù)恢復(fù) (Point-in-Time Recovery)。

  • 在主從復(fù)制中，主庫(kù)將 Binlog 發(fā)送給從庫(kù)，從庫(kù)重放這些操作，從而保持?jǐn)?shù)據(jù)一致。

  • 你可以用全量備份 + Binlog 來(lái)將數(shù)據(jù)庫(kù)恢復(fù)到過去的任意時(shí)間點(diǎn)。

默認(rèn)情況下，Binlog 是以文件形式存儲(chǔ)在磁盤上的（例如 mysql-bin.000001, mysql-bin.000002）。

2. 傳統(tǒng)方式 vs. 流模式

傳統(tǒng)文件方式 (非流式)

• 等待文件寫完： 主庫(kù)會(huì)先將日志寫入一個(gè)完整的文件（例如 mysql-bin.000001），達(dá)到一定大小后（由 max_binlog_size 控制）才切換到下一個(gè)文件。
• 從庫(kù)拉取： 從庫(kù)的 I/O Thread 會(huì)定期檢查主庫(kù)上是否有新的 Binlog 文件或新的內(nèi)容。
• 批量傳輸： 當(dāng)發(fā)現(xiàn)新內(nèi)容時(shí)，從庫(kù)會(huì)請(qǐng)求整個(gè)文件或文件的一部分，通過網(wǎng)絡(luò)傳輸過來(lái)。
• 問題： 這種方式存在延遲。從庫(kù)必須等待主庫(kù)完成一個(gè)文件的寫入后才能開始拉取，這在需要極低延遲復(fù)制的場(chǎng)景下是不可接受的。

流模式 (Streaming)

• 實(shí)時(shí)事件流： 主庫(kù)不再等待整個(gè)文件寫完。只要事務(wù)被提交（Commit），記錄該事務(wù)的 Binlog 事件（Event） 會(huì)立即被放入一個(gè)網(wǎng)絡(luò)流中。
• 持續(xù)推送： 主庫(kù)的 Binlog Dump Thread 會(huì)持續(xù)不斷地將這個(gè)流推送給從庫(kù)（或其它客戶端）。
• 從庫(kù)實(shí)時(shí)接收： 從庫(kù)的 I/O Thread 實(shí)時(shí)地接收這個(gè)流，并立即將其寫入本地的中繼日志 (Relay Log)，SQL Thread 隨后幾乎實(shí)時(shí)地重放這些操作。
• 優(yōu)勢(shì)： 極大降低了復(fù)制延遲（Replication Lag），從庫(kù)可以近乎實(shí)時(shí)地與主庫(kù)保持同步。

一個(gè)簡(jiǎn)單的比喻：

• 傳統(tǒng)文件方式： 就像等作者寫完一整章后，你才能把這一章拿去閱讀。
• 流模式： 就像作者一邊寫，你一邊在他身后看他寫的每一個(gè)句子，幾乎是同步的。

3. 流模式是如何工作的？(技術(shù)實(shí)現(xiàn)要點(diǎn))

流模式的核心依賴于 MySQL 的復(fù)制協(xié)議 和 Binlog 事件流。

1. 連接與認(rèn)證： 從庫(kù)（或客戶端工具）使用 CHANGE MASTER TO 命令指定主庫(kù)信息，并啟動(dòng)復(fù)制線程。

2. 請(qǐng)求Binlog流： 從庫(kù)會(huì)向主庫(kù)發(fā)送一個(gè)請(qǐng)求，內(nèi)容包括：

   • 起始位置： 從哪個(gè) Binlog 文件名和文件內(nèi)的位置（Position）開始讀?。ɡ?nbsp;mysql-bin.000001:120）。

   • GTID： 在基于 GTID 的復(fù)制中，則是從哪個(gè) GTID 集合開始。

3. Dump Thread 流式推送： 主庫(kù)上的 Binlog Dump 線程 被創(chuàng)建。它不會(huì)一次性發(fā)送所有數(shù)據(jù)，而是：

   • 從指定的位置開始，讀取 Binlog 事件。

   • 一旦有新事件產(chǎn)生，就立即通過網(wǎng)絡(luò)連接發(fā)送給從庫(kù)。

   • 如果暫時(shí)沒有新事件，這個(gè)線程會(huì)保持連接并等待，直到有新事件產(chǎn)生或連接超時(shí)中斷。

4. 持續(xù)流動(dòng)： 這個(gè)過程會(huì)一直持續(xù)，只要復(fù)制關(guān)系存在，事件流就會(huì)像水流一樣源源不斷地從主庫(kù)流向從庫(kù)。

4. 誰(shuí)在使用 Binlog 流模式？

1. MySQL 原生主從復(fù)制： 這是最核心的使用者。流模式是保證主從同步低延遲的基礎(chǔ)。

2. 數(shù)據(jù)同步與異構(gòu)復(fù)制工具： 許多第三方工具也利用 MySQL 協(xié)議模擬一個(gè)“從庫(kù)”，來(lái)訂閱 Binlog 流。

   • Canal： 阿里巴巴開行的用于 MySQL 數(shù)據(jù)庫(kù)增量日志解析和同步的工具。

   • Debezium： 一個(gè)流行的 CDC (Change Data Capture) 工具，用于將數(shù)據(jù)庫(kù)變更實(shí)時(shí)流式傳輸?shù)?Kafka 等消息隊(duì)列。

   • MaxWell, Flink CDC 等。

3. 備份工具： 一些高級(jí)的備份工具可以通過流模式實(shí)時(shí)獲取 Binlog，從而實(shí)現(xiàn)真正的實(shí)時(shí)增量備份。

5. 重要概念：GTID 和 位點(diǎn) (Position)

在流模式中，準(zhǔn)確地指定從何處開始讀取流至關(guān)重要。有兩種方式：

• 基于位點(diǎn)的復(fù)制 (Position-Based)： 使用 Binlog 文件名和文件內(nèi)的偏移量（如 mysql-bin.000001:120）作為坐標(biāo)。這是較傳統(tǒng)的方式。
• 基于 GTID 的復(fù)制 (GTID-Based)： 使用 GTID (Global Transaction Identifier)，即全局事務(wù)標(biāo)識(shí)符。每個(gè)提交的事務(wù)都有一個(gè)唯一的 GTID（例如 server-uuid:transaction-id）。這種方式更現(xiàn)代化、更強(qiáng)大，可以避免因?yàn)槿罩疚募袚Q或位置點(diǎn)不準(zhǔn)確導(dǎo)致的主從數(shù)據(jù)不一致問題。流模式強(qiáng)烈推薦使用 GTID。

總結(jié)

總而言之，MySQL Binlog 流模式是現(xiàn)代數(shù)據(jù)庫(kù)生態(tài)系統(tǒng)的基石，它使得實(shí)時(shí)數(shù)據(jù)同步、低延遲的讀寫分離、以及構(gòu)建實(shí)時(shí)數(shù)據(jù)管道成為可能。

到此這篇關(guān)于深入理解MySQL流模式的文章就介紹到這了,更多相關(guān)MySQL 流模式內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論