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變化情況。

 

 

二、除了在加入（start group_replication）MGR叢集時會設定super_read_only，在退出MGR叢集時也會設定它，不管是主動退出（stop group_replication）還是異常退出（比如網路磁碟分割等原因）。這是一種預防性措施，避免節點退出叢集後資料被意外修改掉。節點在加入叢集時，叢集會檢查節點的資料版本資訊、如果節點的資料版本中存在叢集沒有的資料，那麼叢集會拒絕該節點加入其中，因為這意味著該節點的資料跟叢集資料不一致。所以，MGR在節點退出時主動將其super_read_only設定為true，使用者需要手動將其設定為false才能進行寫操作，最大限度減低因為誤操作導致節點資料被意外更改。

 

 

圖中所示為primary節點退出MGR前後的super_read_only變化，可以發現退出後唯讀開啟，手動關閉唯讀建立一個資料庫後重新加入叢集，提示3092錯誤。錯誤記錄檔如下：

 

 

 

三、除了上面所述節點加入或退出MGR時需要設定正確的super_read_only值外，還需要保證MGR節點不受非同步複製通道影響。這又可以分為4種情況。

 

1、需防止單主模式Secondary節點寫入非同步複製通道資料。也就是說一個節點不能同時是MGR叢集的Secondary節點和Master-Slave複製（廣義的非同步複製，包括半同步複製）的Slave節點。這是因為，Secondary節點會回放Primary節點的事務，如果又同時接收和回放另一個複製通道的Master節點事務，這意味著該節點的資料跟其他MGR節點不一致，可能引起資料衝突等多種嚴重問題，這顯然是不可接受的。

 

 

所以，既不能將非同步複製的Slave節點作為單主模式Secondary節點，也不能在單主模式Secondary節點上再啟動非同步複製Slave節點；

 

2、不同於第1點，單主模式的Primary節點以及多主模式下，節點可以作為非同步複製的Slave節點。但在節點寫入非同步複製通道資料前，需要檢查資料是否符合MGR約束，包括必須為InnoDB表，需顯式定義主鍵，沒有CASCADE外鍵等；

 

 

3、上面已經提到節點退出MGR時super_read_only會設定為true，但這無法阻塞relay-log中事務的回放，如果該節點上有非同步複製通道，那麼該節點還會有原因不斷的資料更新，而退出叢集後更新的資料對叢集的其他節點是不可見的，這顯然也是無法被接受，因此，在節點退出MGR叢集時，其上的非同步複製通道也會被停止。

 

 

4、最後，若配置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是一種穩定可靠、可Auto Scaling的線上關係型資料庫服務，當前支援MySQL引擎，提供基礎版，高可用版，金融版針對不同業務情境的高可用解決方案，同時提供多重安全防護措施，效能監控體系，專業的Database Backup、恢複及最佳化方案，使您能專註於應用開發和業務發展。

 

本文來源於資料庫核心專欄。由作者溫正湖授權發布

原文：MySQL Group Replication資料安全性保障