方茹慧,文正國,陳小松,王京紅
(北京中水科水電科技開發有限公司,北京 100038)
iP9000一體化平臺是北京中水科水電科技開發有限公司研發的水利水電自動化業務一體化平臺,主要為水電站監控、水情水調、設備安全監測、設備故障分析與診斷、水電廠培訓仿真、監控運維大數據管理與分析等各種專業應用提供運行和管理環境[1]。
在電力系統二次安全防護“安全分區、網絡專用、橫向隔離、縱向認證”的安全防護規定下[2],隨著一體化平臺接入的業務子系統越來越多、業務子系統間數據應用越來越復雜,如何使數據在不同安全分區、不同應用之間達到“互通、互聯、共享”、滿足不同專業應用系統之間的跨安全分區的同步與交互,成為了水利水電工程自動化業務部署和實施中亟待解決的問題。
數據庫鏡像技術,即每當主數據庫更新時,數據庫鏡像系統會自動把更新后的數據復制到對側數據庫,保證鏡像數據與主數據的一致性。由于實際電站多以MySQL數據庫作為第三方商業數據庫部署數據庫鏡像功能,因此本文以MySQL數據庫的數據庫鏡像作為研究對象,主要探討如何解決MySQL數據庫作為持久化工具時的跨區數據鏡像問題。
MySQL主從復制是使用最為廣泛的一種集群架構,其原理為主數據庫(稱為master)將所有對數據庫的更新操作都記錄在二進制日志(binlog)中,從數據庫(稱為slave)獲取到主數據庫的binlog并且順序的對所有的更新操作進行重放,從而實現與主數據庫保持數據同步。
MySQL數據庫主從復制的實現涉及到3個關鍵線程。主數據庫對每一個從數據庫維護一個發布線程,當收到從數據庫的同步請求后,讀取指定位點信息之后的binlog日志信息返回給從數據庫,同時返回新的位點信息。從數據庫維護有2個線程:1個線程與主數據庫建立連接,向主數據庫發送同步請求并將獲取到的binlog寫入到中繼日志(relay log),同時更新位點信息;第2個線程用于從中繼日志中讀取內容并進行重放,完成數據的同步[3]。由于binlog采用多文件存儲方式,因此位點信息需要包括binlog filename(binlog文件名)以及binlog position(binlog偏移量定位)。
要實現MySQL的主從復制,必須打開主數據庫的binlog記錄功能,這樣主數據庫才會將之后的所有更新操作記錄到binlog文件中。同時,從數據庫只能同步啟用binlog日志功能以后的數據。為了防止主從數據庫數據不一致進而導致的從數據庫同步失敗,從數據庫需要在啟用binlog日志功能前把主數據庫上已經存在的數據全部拷貝到從數據庫上,保證主從數據庫在同一數據基礎上再進行同步。
Canal是阿里開源的數據庫同步中間件,利用MySQL數據庫主從復制的實現原理,基于主數據庫的日志解析以獲取數據的變更,提供變化數據的訂閱與消費,主要用作跨機房數據庫同步。
Canal的工作原理如下:
(1)Canal模擬MySQL從數據庫的交互協議,偽裝自己成為MySQL從數據庫,向MySQL主數據庫發送dump協議;
(2)MySQL主數據庫收到dump請求,開始推送binlog流給從數據庫,即Canal;
(3)Canal解析binlog對象、進行序列化、并存儲;
(4)Canal客戶端(Canal C/S框架客戶端)通過增量訂閱Canal服務端(Canal C/S框架服務端)已經序列化的數據,以獲取MySQL主數據庫的增量變更,并可根據需要對數據進行處理。
EventParser在向MySQL發送dump命令之前會先獲取上次解析成功的位置(如果是第1次啟動,則獲取初始指定位置或者當前數據段binlog位點)。MySQL接受到dump命令后,由EventParser從MySQL上拉取binlog數據進行解析并傳遞給EventSink(傳遞給EventSink模塊進行數據存儲,是一個阻塞操作,直到存儲成功 ),傳送成功之后更新binlog位點信息。
Canal客戶端與Canal服務端之間是C/S模式的通信,采用增量訂閱/消費設計,當Canal 客戶端主動發起拉取請求,Canal服務端就會模擬MySQL從數據庫去MySQL 主數據庫拉取binlog。所以通常Canal客戶端通常是一個守護進程,通過不斷調用get方法,實現對MySQL主數據庫的變更的抓取。
為解決iP9000一體化平臺面臨的數據“互聯、互通、共享”問題,設計并實現了跨安全分區數據庫鏡像功能,提供了部署在不同安全分區的專業應用訪問其他安全分區專業應用采集數據的可能性。
本文研究的跨安全分區數據庫鏡像功能的主要設計目標如下:
(1)專業應用子系統將采集到的數據持久化存儲到MySQL數據庫中;
(2)在其他安全分區部署鏡像數據庫;
(3)自動完成數據庫數據的跨安全分區的同步功能;
(4)鏡像數據庫可以是不同類型的數據庫。
iP9000一體化平臺跨安全分區數據庫鏡像功能按照數據流向,需要依次實現以下功能。
(1)使用開源組件Canal模擬從數據庫來實現MySQL主數據庫binlog的增量訂閱及消費,對數據變更進行抓??;
(2)對抓取的binlog數據進行解析和格式轉換;
(3)通過一體化平臺的跨安全分區數據同步機制傳送到其他安全分區;
(4)其他安全分區一體化平臺接收數據并寫入鏡像數據庫;
總體實現方案如圖1所示。
(1)HA(Highly Available高可用性集群)機制
為了實現跨安全分區數據庫鏡像功能魯棒運行,本文采用高可用性集群機制,通過多服務器的熱備部署,使跨安全分區數據庫鏡像系統盡可能的對外提供可用的、完整的功能。
針對Canal服務端和客戶端,數據庫鏡像系統使用開源的分布式應用程序協調服務zookeeper,實現集群中只有一個節點處于運行狀態,其他節點處于備份狀態。在實現高可用的同時,減少Canal服務端對MySQL主數據庫同步請求,實現Canal客戶端對數據的有序消費。
針對一體化平臺的跨安全分區數據同步相關服務,數據庫鏡像系統使用一體化平臺的調度機制,實現集群中節點的熱備功能。一體化平臺調度機制能夠根據服務的心跳對集群中的服務進行熱調度,保證在一個節點出現故障時能夠及時快速的啟用其他備用節點,有力的保證了跨安全分區傳輸功能以及同步寫入鏡像數據庫功能的高可用性。
(2)binlog日志數據的解析
基于MySQL主數據庫行的復制,Canal服務端抓取到MySQL主數據庫的變更信息包含每條記錄變更前及變更后的詳細信息,從而可以準確地復制每一條記錄。數據庫鏡像服務根據行數據變更前和變更后的對比,從而解析數據的增、刪、改等操作,實現數據的解析功能。
(3)一體化平臺跨安全分區同步
跨安全分區數據同步機制由一體化平臺實現,對應用完全透明。應用可以根據需要將數據傳輸至任意安全分區同時寫入一個或多個第三方商業數據庫中,并支持Oracle、MySQL、MongoDB、達夢等多種數據庫類型。數據庫鏡像服務在對binlog日志數據進行解析和格式轉換之后,將格式化的數據交由一體化平臺即可透明傳輸、寫入部署在其他安全分區的鏡像數據庫,實現同構或異構的跨安全分區數據庫鏡像功能。
以某電站為例。某電站配備了趨勢分析系統以及現地采集系統(包括子系統:機組狀態在線監測子系統、主變壓器在線監測子系統、GIS在線監測子系統、GIL在線監測子系統等)。根據安全要求,現地采集系統和趨勢分析系統不能運行在同一個安全分區。為解決數據分析系統能夠及時準確訪問到采集系統采集的數據,該電站部署投運了跨安全分區的數據庫鏡像功能,并可以較好地滿足實際生產需要。
如圖2所示,主變壓器在線監測子系統和GIS/GIL在線監測子系統部署在安全II區,趨勢分析系統部署在安全III區。由于采集子系統由不同廠家進行設計實現,分別將采集數據存儲于部署在本安全分區的MySQL數據庫和MariaDB數據庫2個數據庫。MariaDB數據庫與MySQL數據庫強的兼容性為MariaDB數據庫跨安全分區同步提供了可能。為了將這2個數據庫分別跨安全分區同步到部署在安全III區的鏡像數據庫,現場部署了如圖2所示的MySQL、MariaDB 2套數據庫鏡像系統。

圖2 某電站跨安全分區數據庫鏡像功能部署方式
安全II區 部 署2套Canal,由Canal服務端模擬從數據庫,獲取主數據庫增量變更信息;之后,由HDBMIRROR(Canal 客戶端)服務與Canal 服務端建立連接,將增量獲取到的內容進行解析和格式轉換,接著提交給本安全分區的iP9000隔離通信服務;最后,由部署在安全II區和安全III區的iP9000隔離通信服務實現跨隔離及寫庫功能。
為了保證系統的魯棒性,Canal服務端和HDBMIRROR程序均由zookeeper集群統一調度,HDBMIRROR通過向zookeeper詢問運行節點主機信息,實現與Canal服務端的連接,完成數據的增量訂閱、解析、消費功能;iP9000隔離通信/寫庫服務由iP9000調度服務統一調度,由服務主節點完成數據的傳輸和寫庫功能。
本文基于iP9000一體化平臺面對多專業應用、多類數據跨安全分區形成統一數據平臺的目的[4],設計并實現了跨安全分區的數據庫鏡像功能,為各專業應用之間數據的互通、互聯與共享統一提供了支持。基于iP9000一體化平臺的跨安全分區數據庫鏡像功能,在實際項目應用中成功地實現了不同專業應用系統之間通過數據庫的鏡像功能實現的跨安全分區的數據交互,滿足了數據同步的及時性、準確性和完整性,完善了iP9000一體化平臺的跨安全分區數據同步功能。