本文介紹了PolarDB-X的BinlogLog Service，以及其兩種形態和適用情境。
介紹
Binlog是MySQL記錄變更資料的二進位日誌，它可以看做是一個訊息佇列，隊列中按順序儲存了MySQL中詳細的增量變更資訊，通過消費隊列中的變更條目，下遊系統或工具實現了與MySQL的即時資料同步，此機制也稱為CDC（Change Data Capture，增量資料捕捉）。
PolarDB-X是相容MySQL生態的分散式資料庫。通過執行個體內PolarDB-X的CDC組件，能夠提供與MySQL binlog格式相容的變更日誌，並且對外隱藏了執行個體擴縮容、分散式交易、全域索引等分布式特性，讓您獲得與單機MySQL資料庫一致的使用體驗。
PolarDB-X提供了兩種形態的binlog日誌消費訂閱能力，且兩種形態可同時共存。
單流形態：即單流binlog日誌（也稱為Global binlog），將所有DN的binlog歸併到同一個全域隊列，提供了保證事務完整性和有序性的日誌流，可以提供更高強度的資料一致性保證。例如在轉賬情境下，基於Global binlog接入PolarDB-X的下遊MySQL，可以在任何時刻查詢到一致的餘額。
多流形態：即多流binlog日誌（也稱為Binlog-X），並不是將所有DN的binlog歸併到一個全域隊列，而是將資料進行Hash打散並分發到不同的日誌流，在一定程度上犧牲了事務的完整性，但大大提升了擴充性，可以解決大規模叢集下單流binlog存在的單點瓶頸問題。
單流形態
將所有DN節點的原始binlog日誌歸併到一個隊列，並進行排序和合并，剔除內部細節，對外提供相容MySQL binlog格式和dump協議的日誌流。當購買PolarDB-X執行個體時，預設開通單流binlog服務。
注意事項
CDC的Master節點和Slave節點之間會進行binlog檔案的複製，並保證兩邊資料完全一致，即下遊按照filename+position的方式進行消費訂閱，當CDC發生主從切換時，無需擔心檔案名稱和位點會發生變化。
僅當事務策略指定為TSO時，才支援對分散式交易的合并，否則只能保證資料的最終一致性，PolarDB-X預設的事務策略為TSO。
當需要對某行資料進行分區索引值變更時，需在採用TSO事務策略的分散式交易內進行，才能保證delete事件在binlog中的位置早於insert事件，從而保證資料一致。具體來講，首先需要採用TSO事務策略，然後按如下任意一種進行操作都可以實現分區索引值的變更，並可以保證資料一致。
執行一條update sql進行分區索引值的修改；
執行一條replace sql進行分區索引值的修改；
顯示開啟事務，先執行delete，調整分區索引值，重新insert。
多流形態
多流binlog依然完全相容MySQL binlog檔案格式和dump協議，可以將每條binlog日誌流看作一個單機MySQL，針對單個日誌流，可執行change master、show binlog events等SQL命令消費或查看binlog資料。
多流服務不是預設開通的，需通過控制台手動開通，對於同一個PolarDB-X執行個體，可支援同時開通多個多流服務，每個多流服務中支援多個流，不同服務之間是完全隔離的，可設定不同的拆分數量、不同的資料拆分層級、不同的參數規則等，可根據實際需求開通不同形態的多流服務。
拆分層級
多流binlog提供了3種形式的資料拆分層級，在開通多流服務時可進行設定，滿足不同情境下的使用需求。
庫層級
按照資料庫的名字計算Hash值並進行分發，即對應同一個庫的binlog資料，會始終按序路由給同一個binlog資料流，適用於單個PolarDB-X執行個體上資料庫比較多的情境，如果事務不涉及跨庫操作，該策略下不僅可以具備多流能力，還可以保證事務的完整性。
表層級
按照資料表的名字計算Hash值並進行分發，即對應同一張表的binlog資料，會始終按序路由給同一個binlog資料流，適用於表的數量較多且希望針對單張表的操作（如DML、DDL等）在binlog日誌流中保持有序的情境。
記錄層級
按照資料行的主鍵計算Hash值並進行分發，即對應同一資料行的binlog資料，會始終按序路由給同一個binlog資料流，適用於希望將資料充分打散且不要求日誌資料按庫或按表保持有序的情境，該策略要求資料表必須含有主鍵，無主鍵表的資料會被直接丟棄。
資料拆分層級支援分層配置，分別為服務層和庫表層，層級配置成功就不支援修改，否則會觸發相同資料在不同流之間的“漂移”，導致資料一致性問題。開通多流服務前，建議結合實際業務情境進行評估，預先規劃好拆分層級。
服務層
該多流服務的預設拆分層級，如果針對某個庫或表沒有單獨設定拆分層級，則使用服務層的預設配置。
庫表層
可以針對某個庫或表單獨設定分發策略，該分發策略會對執行個體層級的配置進行重載，以滿足差異性需求。
注意事項
多流服務建立成功後，不支援修改流的個數，請提前規劃好流的數量，建議流的數量大於等於DN的個數。
多流服務建立成功後，不支援調整已經生效的拆分層級，建議提前進行規劃。
如果希望對新增加的資料表獨立設定拆分層級，請在該表有資料寫入之前進行配置。
當拆分層級為表級時，支援對錶進行
Rename操作，PolarDB-X會始終依據初始表名進行資料拆分。當拆分層級為表級時，為避免大表資料集中到少數幾個流，出現資料扭曲的問題，可單獨設定路由規則。
如果想調整流的個數和已經生效的資料拆分層級，可以通過開通一個新的多流服務來進行替換，此時會涉及下遊消費鏈路的一些營運調整。
當拆分層級為記錄級時，如果資料表包含唯一性限制式並且會發生唯一鍵交換，按照記錄級進行拆分，可能會觸發資料一致性問題。例如，uk(name)=a先後被id=1和id=2的資料所持有，但因無法保證
delete(id=1,name=1)和insert(id=2,name=a)在目標庫的執行順序，當insert(id=2,name=2)先於delete(id=1,name=1)執行時，會出現寫入衝突。此類情境建議設定拆分層級為表級。
透明消費
CDC會優先把構建好的binlog檔案儲存在本地磁碟，並支援即時上傳到遠端儲存（例如OSS）。本地磁碟上的檔案一般存活周期較短，遠端儲存上的檔案存活周期較長（例如15天）。針對遠端儲存上的檔案，CDC提供了透明消費能力，即屏蔽了本地和遠端的儲存差異，下遊系統無需為訪問遠端儲存上的binlog資料做任何額外適配。
CDC 2.0.0及以上版本支援透明消費能力。
異地多活
除了通過CDC將資料匯入其他外部系統，PolarDB-X的CDC也可以用於實現異地多活的業務部署。例如，將使用者ID按照所在地區劃分到不同機房，寫入操作必須在特定機房進行，而讀取操作可以讀就近的“副本”，這些副本資料就可以通過CDC從原機房同步得到。