MySQL 數據庫雙向同步復制

下載網站:www.SyncNavigator.CN 
 客服QQ1793040
----------------------------------------------------------

關於HKROnline SyncNavigator 注冊機價格的問題

 

 

HKROnline SyncNavigator 8.4.1 非破解版 注冊機 授權激活教程
 

 

 

 

最近一直在研究數據庫同步的問題，在網上查了很多資料，也請教了很多人，找到了一種通過快照復制的方法。研究了一番后發現之前就是用的這個方法，效果不是很好，果斷放棄。經過了一番尋覓和他人指點，最后從一位熱心網友那里得知一款很好用的軟件—— SyncNavigator。

 

 

好東西就要拿出來跟大家分享，所以今天向大家介紹一下這款軟件，及其一些使用方法。下面先看看它有什么強大的功能吧！

 

SyncNavigator的基本功能：

 

自動同步數據/定時同步數據
無論是實時同步/24小時不間斷同步，還是根據計划任務(每小時/每日/每周/等)定時自動同步都能完全勝任。

完整支持 Microsoft SQL Server
完整支持 Microsoft SQL Server 2000 2005 2008 數據庫類型。並能在不同數據庫版本之間相互同步數據。

支持 MySQL 4.1 以上版本
支持 MySQL 4.1 5.0 5.1 5.4 5.5。並能在不同數據庫版本之間相互同步數據。

無人值守和故障自動恢復
當數據庫故障或網絡故障以后，無需人工干預(或操作)自動恢復同步並確保數據完全准確，可靠。

同構數據庫同步/異構數據庫同步
SQL Server to SQL Server, MySQL to MySQL, SQL Server to MySQL 等都能輕松實現。

斷點續傳和增量同步
當同步完成(或中斷)后，再次同步時能繼續上一次的位置增量同步，避免每次都需要從頭開始的問題。

MySQL 復制問題的最后一篇，關於雙向同步復制架構設計的一些設計要點與制約。

問題和制約

數據庫的雙主雙寫並雙向同步場景，主要考慮數據完整性、一致性和避免沖突。對於同一個庫，同一張表，同一個記錄中的同一字段的兩地變更，會引發數據一致性判斷沖突，盡可能通過業務場景設計規避。雙主雙寫並同步復制可能引發主鍵沖突，需避免使用數據庫自增類主鍵方案。另外，雙向同步潛在可能引發循環同步的問題，需要做回環控制。

如上圖所示，復制程序寫入時也會產生 binlog，如何識別由復制程序產生的 binlog 並將其過濾掉是避免循環復制的關鍵。

原生 Dual Master 方案

MySQL 自身支持雙主配置，但並沒有去解決潛在的主鍵和雙寫帶來的數據一致性沖突。對於雙向同步潛在的循環復制問題，MySQL 在 binlog 中記錄了當前 MySQL 的 server-id。一旦有了 server-id 的值之后，MySQL 就很容易判斷某個變更是從哪一個 Server 最初產生的，所以就很容易避免出現循環復制的情況。而且，還可以配置不打開記錄 slave 的 binlog 選項（–log-slave-update），MySQL 就不會記錄復制過程中的變更到 binlog 中，就更不用擔心可能會出現循環復制的情形了。

從 MySQL 自身的方案中可以找到切入點，就是如果能在 binlog 中打上標記，就有辦法判斷哪些 binlog 是復制產生的，並將其過濾。使用 MySQL 的方案則過於耦合 MySQL 的配置，在大規模部署的線上生產系統中容易因為 MySQL 配置錯誤導致問題。

自定義標記 SQL 方案

為了和 MySQL 配置解耦合，可以考慮一種通用的標記 SQL 方案。簡單來說，就是在同步復制入庫時插入特殊的標記 SQL 語句來標記這是來自復制程序的變更，這個標記 SQL 會進入 binlog 中。而在復制程序讀取時，通過識別這個標記 SQL 來過濾判斷。binlog 中存儲了對數據產生變更影響的的 SQL 語句，這些 SQL 語句組成了一段一段的事務，如下圖所示：

綠色區是業務運行產生的正常事務，紅色區是復制程序寫入產生的事務，其中藍色塊是標記 SQL。標記 SQL 分別在事務開始后與事務結束前，標記 SQL 更新一張預定義的區別於業務表的標記表。那么每次復制程序去批量讀取 binlog 內容時，可能存在下面 5 種情況，如下圖所示：

1. 批量讀取范圍全落在綠色區內。
2. 批量讀取范圍起點落在綠色區，終點落在紅色區。
3. 批量讀取范圍起點落在紅色區，終點落在綠色區。
4. 批量讀取范圍起點和終點都在綠色區，但中間涵蓋了一段紅色區。
5. 批量讀取范圍全落在紅色區。

如上只有第 5 種情況，一個事務被拆成 3 段來同步。中間一段因為沒有事務頭和尾的標記，復制程序讀取時將無法判斷，導致循環同步，需要避免。通過把復制程序的批量讀取范圍固定設置為至少大於或等於寫入的事務長度范圍，避免了第 5 種情況。復制程序批量讀取 binlog 日志事件時，通過標記 SQL 來過濾，避免了循環復制，實現了回環控制。

總結

本文考慮了在 MySQL 雙主寫入場景下雙向同步復制的一些設計要點和制約。以原生實現為參考，給出了一種自定義實現方式的設計要點分析。而對於同庫同表同記錄同字段的同時兩地變更，則必然引發數據一致性沖突，在復制同步層面無法區分哪邊的更新為准。通常會考慮以最后時間戳來恢復到一致狀態，但時間戳實際也會產生誤差，此類場景不多見最好還是盡可能還是在業務場景設計上來規避。