MySQL Group Replication數據安全性保障

本文來自數據庫內核專欄

 

在以前的文章中，介紹了MGR對數據可靠性、可用性和一致性的實現方案。簡單來講，MGR經過基於paxos協議的多副原本實現數據的可靠性，經過多副本上的majority機制來實現可用性。對於一致性，主要說的是多主模式下經過基於事務版本的認證機制來確保多節點併發更新的正確性。

 

本文再介紹下MGR對於數據安全性的保護，這裏所說的安全性是指MGR中的數據不會被外來的操做所影響，從而引發不一樣節點的數據處於不一致的狀態，因爲引發不一致的緣由是外來的、計劃外的，因此歸爲安全性的範疇。

 

一，先說說單主模式下Secondary節點的安全性保障。該模式下，MGR會將Secondary節點的super_read_only設置爲true來確保Secondary節點沒法處理寫事務。這是由於，雖然是MGR對外呈現是單主模式，但Xcom層的Paxos仍是多點可寫，也就是說Secondary節點的Paxos仍能夠做爲proposer。在這種狀況下，若是不將super_read_only設置爲true，那麼在沒有事務認證機制參與的狀況下，不一樣節點的事務就可能由於衝突致使數據狀態出錯。所以，Secondary節點在執行start group_replication操做時super_read_only被置爲true。

 

圖中所示爲一個節點做爲Secondary加入MGR先後super_read_only變化狀況。

 

 

2、除了在加入（start group_replication）MGR集羣時會設置super_read_only，在退出MGR集羣時也會設置它，不論是主動退出（stop group_replication）仍是異常退出（好比網絡分區等緣由）。這是一種預防性措施，避免節點退出集羣后數據被意外修改掉。節點在加入集羣時，集羣會檢查節點的數據版本信息、若是節點的數據版本中存在集羣沒有的數據，那麼集羣會拒絕該節點加入其中，由於這意味着該節點的數據跟集羣數據不一致。因此，MGR在節點退出時主動將其super_read_only設置爲true，用戶須要手動將其設置爲false才能進行寫操做，最大限度減低由於誤操做致使節點數據被意外更改。

 

 

圖中所示爲primary節點退出MGR先後的super_read_only變化，能夠發現退出後只讀開啓，手動關閉只讀新建一個數據庫後從新加入集羣，提示3092錯誤。錯誤日誌以下：

 

 

 

3、除了上面所述節點加入或退出MGR時須要設置正確的super_read_only值外，還須要保證MGR節點不受異步複製通道影響。這又能夠分爲4種狀況。

 

一、需防止單主模式Secondary節點寫入異步複製通道數據。也就是說一個節點不能同時是MGR集羣的Secondary節點和Master-Slave複製（廣義的異步複製，包括半同步複製）的Slave節點。這是由於，Secondary節點會回放Primary節點的事務，若是又同時接收和回放另外一個複製通道的Master節點事務，這意味着該節點的數據跟其餘MGR節點不一致，可能引發數據衝突等多種嚴重問題，這顯然是不可接受的。

 

 

因此，既不能將異步複製的Slave節點做爲單主模式Secondary節點，也不能在單主模式Secondary節點上再啓動異步複製Slave節點；

 

二、不一樣於第1點，單主模式的Primary節點以及多主模式下，節點能夠做爲異步複製的Slave節點。但在節點寫入異步複製通道數據前，須要檢查數據是否符合MGR約束，包括必須爲InnoDB表，需顯式定義主鍵，沒有CASCADE外鍵等；

 

 

三、上面已經提到節點退出MGR時super_read_only會設置爲true，但這沒法阻塞relay-log中事務的回放，若是該節點上有異步複製通道，那麼該節點還會有緣由不斷的數據更新，而退出集羣后更新的數據對集羣的其餘節點是不可見的，這顯然也是沒法被接受，所以，在節點退出MGR集羣時，其上的異步複製通道也會被中止。

 

 

四、最後，若配置mysqld重啓後自動啓動MGR和異步複製通道，須要確保啓動順序協調一致。原則是確保MGR應該先於異步複製通道啓動，MGR節點變爲ONLINE狀態後再啓動異步複製通道。主要考慮三點：a、先確保MGR在線，再啓動異步複製；b、若是MGR啓動失敗，那麼異步複製也必須返回失敗；c、若是在單主模式Secondary節點上配置了自動啓動，那麼須要保證MGR啓動成功，異步複製返回失敗。

 

最後介紹下InnoSQL在這方面的加強。InnoSQL增長了一個參數group_replication_readonly_after_reconfig，該參數與官方提供的group_replication_force_members配合使用。當MGR集羣由於異常致使只有一個節點在線時，因爲失去majority致使該節點會阻塞寫事務的提交，group_replication_force_members參數能夠經過重配置，讓MGR集羣成爲只有該節點的新集羣，從而可以正常執行寫事務。但正由於此時集羣中只有一個節點，寫入的數據是極不可靠的。

 

對於RDS雲服務中3節點的MGR金融版實例，2個節點下線後，存活的節點本就應該只提供讀服務。若由於配置group_replication_force_members致使系統變爲可寫狀態，這顯然是不合適的。group_replication_readonly_after_reconfig就是爲了控制group_replication_force_members後節點的讀寫行爲，若是啓用，那麼重配置後，節點會變爲只讀狀態，在實現上也是經過設置super_read_only爲true實現。

 

 

 

網易雲數據庫RDS是一種穩定可靠、可彈性伸縮的在線關係型數據庫服務，當前支持MySQL引擎，提供基礎版，高可用版，金融版針對不一樣業務場景的高可用解決方案，同時提供多重安全防禦措施，性能監控體系，專業的數據庫備份、恢復及優化方案，使您能專一於應用開發和業務發展。

 

本文來源於數據庫內核專欄。由做者溫正湖受權發佈

原文：MySQL Group Replication數據安全性保障