在MySQL8.0引入了InnoDB ReplicaSet，它提供了我們熟悉的復制特性，如果有mongodb副本集的概念，理解InnoDB ReplicaSet會比較容易。

InnoDB ReplicaSet使用了下面的技術：

1、MySQL Shell，一個功能更強大的客戶端

2、MySQL Router，一個輕量級別的中間件，可以類比MongoDB中的mongos的角色；

3、MySQL Server，也就是MySQL服務

InnoDB ReplicaSet，下面簡稱 innodb副本集。它采用了MySQL的復制技術，副本集中擁有一個primary節點，一個或者多個secondary節點，它不像innodb cluster(innodb cluster是另外一種MySQL高可用方案)一樣提供故障自愈和多主模式，但是提供手工的方法添加、移除和配置相關節點。

我們通常使用MySQL Shell中的AdminApi來管理innodb副本集，adminapi有js和python兩種版本，我們可以很方便的去編寫腳本來自動部署MySQL，AdminAPI為MySQL實例集提供了一個有效的現代接口，使您能夠從一個中心工具提供、管理和監視部署。

innodb副本集支持MySQL Clone組件，我們可以利用克隆插件很方便的搭建起來一個副本集。

InnoDB ReplicaSet與MySQL Router緊密集成，可以使用AdminAPI與它們一起工作。MySQL Router可以基于InnoDB ReplicaSet自動配置自己，這個過程稱為bootstrapping，這樣就不需要手動配置路由。

上面介紹了innodb 副本集的一些基本知識和概念，這里我們有必要說一下它的局限性，innodb副本集的局限性，主要是對比innodb cluster來體現出來的，下面我們羅列一下：

1、沒有故障自動切換功能。在主庫不可用的情況下，需要使用AdminApi手動觸發故障轉移；

2、無法防止由于意外或者不可用而導致的數據丟失，發生故障時候沒有應用的事務可能有丟失現象；

3、無法防止意外退出之后的數據不一致現象；在主節點因為網絡問題而短暫失聯時候，如果某個從節點提升為主節點，則可能發生腦裂現象；

4、innodb 副本集不支持多主模式，經典的多主寫入復制方案無法保證數據一致性；

5、innodb副本集基于異步復制，不能像MGR那樣進行流控，因此讀的擴展性會一定程度上受限；

6、所有secondary都要從primary復制，因此可能會對源實例產生一定的影響

從上面的描述中不難看出，innodb副本集跟MongoDB的副本集還有很大的差距，但是我們依然有研究的必要，因為它是MySQL官方在高可用之路上邁出的重要一步，后續隨著版本的迭代，我相信這些問題會得到關注和解決，有更好的方案進一步滿足用戶的要求。

innodb副本集的運行環境有一定的要求，如下：

1、僅支持MySQL8.0及以上版本；

2、僅支持GTID的復制方法

3、僅支持row格式的binlog，不支持statement格式的binlog

4、不支持復制過濾器

5、不允許建立額外的復制通道

6、副本集primary節點只有一個，secondary節點可以有多個，MySQL Router會對每個節點進行監控

7、副本集必須完全由MySQL Shell管理，不支持在MySQL Shell之外對實例進行配置和更改

下一篇文章我將會從最基本的安裝過程說起，詳細描述MySQL Shell、MySQL Router的安裝以及innodb 副本集的搭建過程。

以上就是MySQL InnoDB ReplicaSet(副本集)簡單介紹的詳細內容，更多關于MySQL InnoDB ReplicaSet(副本集)的資料請關注好吧啦網其它相關文章！