[發明專利]一種跨機房數據庫同步方法及系統

在審

• 申請號: 201210400979.2
• 申請日: 2012-10-19
• 公開（公告）號: CN103778136A
• 公開（公告）日: 2014-05-07
• 發明（設計）人: 樓江航
• 申請（專利權）人: 阿里巴巴集團控股有限公司
• 主分類號: G06F17/30
• 分類號: G06F17/30;G06F11/14
• 代理公司: 杭州天勤知識產權代理有限公司 33224
• 代理人: 楊天嬌

技術領域

本申請涉及計算機及網絡技術領域，尤其涉及一種跨機房數據庫同步傳輸方法和系統。

背景技術

目前針對一些大型網站業務，在系統可用性上往往會考慮數據庫的跨機房鏡像復制，容災備份等，在發生不可抗力因素導致當地數據不可用時，能夠快速的通過異步的數據庫備份或者鏡像提供系統訪問。

在做數據庫同步時，目前一般的做法是通過數據庫DML/DDL的變更日志解析，發送給目標庫后再重新執行一次數據庫DML/DDL變更，以達到兩邊的數據庫保持一致。這種做法針對跨機房，跨地區網絡的數據庫同步，存在的一個問題就是數據的傳輸量以及重新執行的代價，源數據庫和目標數據庫完全是1∶1的模式，源庫的一次變更，就會有一份數據傳輸以及一次DDL/DML執行。

目前杭州到青島的單個tcp包的網絡延遲為70ms，杭州到美國的單個tcp包的網絡延遲為200ms，一旦同一時間數據庫的變更達到一個高峰，數據庫的同步過程會因為網絡傳輸和重新執行而造成阻塞，從而導致數據庫同步延遲。因此，針對一些跨機房，跨地區網絡的數據庫同步，如何減少傳輸數據以及減少重新執行的代價就非常關鍵。

現有的技術通常是利用數據庫自帶的解決方案，比如使用比較廣泛的mysql數據庫同步。mysql同步會將數據庫變更的記錄存入binlog文件，并提供socket服務，由需要執行同步的目標庫發起一次數據同步請求。

目前mysql5版本自帶數據庫復制方案，同步系統本身與mysql?server進行了集成，作為一個mysql組件存在。例如源數據庫為A，目標數據庫為B，同步系統為C，同步過程如下：

1)同步系統通過單個socket鏈接和數據庫建立鏈接，開始監聽數據變更；

2)原始數據在數據庫A中發生insert/update/delete等操作；

3)數據庫A會在本地生成變更日志數據；

4)同步系統監聽到數據變更，通過建立的socket開始獲取變更數據；

5)在異步接收完整個變更數據包后，解析為內部執行對象；

6)根據數據庫A上的變更操作，在目標數據庫B上重新執行insert/update/delete等操作。

但現有技術mysql同步主要存在以下問題：

1)為保證同步順序性，mysql采用了tcp長鏈接的方式進行數據傳輸。

2)為保證數據的可靠性，mysql采用了ack請求的回饋模式+順序傳輸。只有上一批數據完全獲取成功后，才會去獲取下一批數據，并且同一時間只有一份數據在傳輸。

3)mysql變更日志文件binlog詳細記錄每次數據庫的變更，可以提供DBA(數據庫管理員)詳細查看后用于分析數據庫的歷史變更記錄，并不是僅僅為數據庫的高效同步而特殊設計的，所以存在很多冗余數據，造成數據量巨大。

針對跨機房，跨地區網絡的同步業務，傳統的單tcp工作模式面對高峰時期的數據庫變更同步時，會產生數據堆積，造成網絡擁堵。

發明內容

本申請提出了一種高效、可靠的數據庫同步方法及系統，采用多線程并行處理的思路，利用SQL語義執行的特性，通過對數據的合并、壓縮、并行處理等完整的傳輸方案，來緩解目前跨機房、跨地區網絡的同步延遲問題。

一種跨機房數據庫同步方法，用于目標數據庫跨機房的從源數據庫同步數據，包括如下步驟：

步驟100、在源數據庫端監聽源數據庫的變更；

步驟110、利用多個順序編號的并行進程依次提取源數據庫的變更數據；

步驟120、各個并行進程將提取到的數據經合并、壓縮后進行發送；

步驟130、在目標數據庫端接收各個并行進程發送的數據，按照各并行進程的次序進行加載得到待同步數據，利用該待同步數據更新目標數據庫。

所述步驟100中，在源數據庫端通過socket和源數據庫建立鏈接，監聽數據變更，所述源數據庫的變更為Insert、Update、Delete至少一種事件的觸發。

源數據庫發生insert、update或delete事件時會在本地生成變更日志數據，通過建立的socket可以獲取變更數據。

步驟110具體包括：

步驟111、開啟多個并行進程并對每個并行進程賦以編號；

步驟112、各個并行進程按照編號依次提取源數據庫的變更數據，且在提取的同時進行解析得到若干內部對象，即步驟120所述的提取到的數據。