Multi-Source on Tarragonhttps://tarrragon.github.io/blog/tags/multi-source/Recent content in Multi-Source on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 22 May 2026 00:00:00 +0000MySQL Multi-source Replicationhttps://tarrragon.github.io/blog/backend/01-database/vendors/mysql/multi-source-replication/Fri, 22 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/01-database/vendors/mysql/multi-source-replication/<p>MySQL multi-source replication 的核心責任是讓一個 replica 從多個 source 接收資料。這種拓撲常用於資料整併、分庫匯總、migration staging、報表集中或多個 bounded context 的 read consolidation。</p> <p>本文的判讀錨點是：multi-source replication 是 consolidation pattern，而非 multi-primary conflict resolution。每個 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/replication-channel/" data-link-title="Replication Channel" data-link-desc="說明多來源複製中，每個來源對應的獨立複製通道如何成為隔離單位">replication channel</a> 要有獨立 source、schema scope、lag、error handling 與 ownership。</p> <h2 id="use-cases">Use Cases</h2> <p>Use cases 的核心責任是確認 multi-source 解決的是整併需求。</p> <table> <thead> <tr> <th>情境</th> <th>適合條件</th> </tr> </thead> <tbody> <tr> <td>Reporting replica</td> <td>多個 source 匯入同一 read-only target</td> </tr> <tr> <td>Migration staging</td> <td>新平台先接多個 source binlog</td> </tr> <tr> <td>Regional fan-in</td> <td>多區 local DB 匯總到中心</td> </tr> <tr> <td>Shard consolidation</td> <td>多 shard 同 schema 匯入 reporting DB</td> </tr> <tr> <td>Audit / CDC sink</td> <td>變更集中供後續 pipeline 使用</td> </tr> </tbody> </table> <p>Multi-source target 通常應 read-only。若 target 同時接受 application write，就要設計 conflict 與 ownership，複雜度會大幅提高。</p> <h2 id="channel-design">Channel Design</h2> <p>Channel design 的核心責任是把每個 source 隔離成可觀測單位。</p> <table> <thead> <tr> <th>設計項</th> <th>審查問題</th> </tr> </thead> <tbody> <tr> <td>Channel name</td> <td>是否能看出 source / owner / purpose</td> </tr> <tr> <td>Schema scope</td> <td>不同 source 是否寫入不同 schema / table</td> </tr> <tr> <td>GTID</td> <td>GTID domain / collision policy</td> </tr> <tr> <td>Filter</td> <td>replicate-do / ignore 規則是否可審查</td> </tr> <tr> <td>Credential</td> <td>每個 channel 是否獨立 secret</td> </tr> <tr> <td>Lag alert</td> <td>channel-level lag 與 error</td> </tr> </tbody> </table> <p>Channel 命名要可讀。Incident 時看到 channel 名稱，就要知道哪個 source、哪個 team、哪個用途與是否可暫停。</p> <h2 id="conflict-boundary">Conflict Boundary</h2> <p>Conflict boundary 的核心責任是避免多個 source 寫同一份邏輯資料。Multi-source 沒有自動解決業務 conflict 的能力。</p> <table> <thead> <tr> <th>Conflict 類型</th> <th>控制方式</th> </tr> </thead> <tbody> <tr> <td>Primary key collision</td> <td>shard key prefix、schema isolation</td> </tr> <tr> <td>Duplicate natural key</td> <td>source namespace、dedupe layer</td> </tr> <tr> <td>Out-of-order update</td> <td>source ownership、event timestamp</td> </tr> <tr> <td>Delete collision</td> <td>tombstone policy</td> </tr> <tr> <td>DDL drift</td> <td>migration coordination</td> </tr> </tbody> </table> <p>最安全的 pattern 是每個 source 寫自己的 schema 或帶 source namespace 的 table。若多 source 寫同一 table，必須先設計 key space 與 conflict policy。</p> <h2 id="monitoring">Monitoring</h2> <p>Monitoring 的核心責任是讓每個 channel 的狀態可見。</p>MySQL multi-source replication 的核心責任是讓一個 replica 從多個 source 接收資料。這種拓撲常用於資料整併、分庫匯總、migration staging、報表集中或多個 bounded context 的 read consolidation。

本文的判讀錨點是：multi-source replication 是 consolidation pattern，而非 multi-primary conflict resolution。每個 replication channel 要有獨立 source、schema scope、lag、error handling 與 ownership。

Use Cases

Use cases 的核心責任是確認 multi-source 解決的是整併需求。

情境 適合條件
Reporting replica 多個 source 匯入同一 read-only target
Migration staging 新平台先接多個 source binlog
Regional fan-in 多區 local DB 匯總到中心
Shard consolidation 多 shard 同 schema 匯入 reporting DB
Audit / CDC sink 變更集中供後續 pipeline 使用

Multi-source target 通常應 read-only。若 target 同時接受 application write，就要設計 conflict 與 ownership，複雜度會大幅提高。

Channel Design

Channel design 的核心責任是把每個 source 隔離成可觀測單位。

設計項 審查問題
Channel name 是否能看出 source / owner / purpose
Schema scope 不同 source 是否寫入不同 schema / table
GTID GTID domain / collision policy
Filter replicate-do / ignore 規則是否可審查
Credential 每個 channel 是否獨立 secret
Lag alert channel-level lag 與 error

Channel 命名要可讀。Incident 時看到 channel 名稱，就要知道哪個 source、哪個 team、哪個用途與是否可暫停。

Conflict Boundary

Conflict boundary 的核心責任是避免多個 source 寫同一份邏輯資料。Multi-source 沒有自動解決業務 conflict 的能力。

Conflict 類型 控制方式
Primary key collision shard key prefix、schema isolation
Duplicate natural key source namespace、dedupe layer
Out-of-order update source ownership、event timestamp
Delete collision tombstone policy
DDL drift migration coordination

最安全的 pattern 是每個 source 寫自己的 schema 或帶 source namespace 的 table。若多 source 寫同一 table，必須先設計 key space 與 conflict policy。

Monitoring

Monitoring 的核心責任是讓每個 channel 的狀態可見。

1SHOW REPLICA STATUS FOR CHANNEL 'source_a'\G
2SHOW REPLICA STATUS FOR CHANNEL 'source_b'\G

要觀測：

  1. IO thread / SQL thread status。
  2. Seconds behind source。
  3. Last IO error / SQL error。
  4. Relay log growth。
  5. GTID executed / retrieved。
  6. Channel credential expiry。

Lag 要分 channel 告警。總體 replica 健康不足以定位哪個 source 卡住。

Migration Pattern

Migration pattern 的核心責任是把 multi-source 用在可回退的搬遷。

Phase Evidence
Source audit schema、GTID、binlog format
Target setup channel、filter、credential
Backfill dump / load、checksum
Catch-up channel lag、error
Read test report query、row count
Cutover read endpoint switch
Cleanup stop channel、retention、secret

Migration target 若只是 reporting，cutover 風險較低；若要成為 new primary，還要處理 write freeze、conflict、application route 與 rollback。

Failure Modes

Failure modes 的核心責任是把 multi-source 事故分 channel 處理。

Failure mode 判讀訊號 修正方向
Single channel lag 某 source 延遲 查 source load、network、SQL error
DDL drift replication SQL error migration coordination
Key collision duplicate key error namespace / key rewrite
Relay log growth target apply 慢 調整 parallel apply、拆 workload
Credential expired IO thread stopped rotate secret、resume channel

Channel failure 要避免全局操作。只停問題 channel，保留其他 channel，能降低 blast radius。

下一步路由

Multi-source replication 完成後，基本拓撲讀 Replication Topology；failover 讀 Orchestrator Failover；CDC 與 binlog 讀 Binlog CDC。

]]>