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

InnoDB ReplicaSet使用了下面的技術(shù)：

1、MySQL Shell，一個功能更強(qiáng)大的客戶端

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

3、MySQL Server，也就是MySQL服務(wù)

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

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

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

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

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

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

2、無法防止由于意外或者不可用而導(dǎo)致的數(shù)據(jù)丟失，發(fā)生故障時候沒有應(yīng)用的事務(wù)可能有丟失現(xiàn)象；

3、無法防止意外退出之后的數(shù)據(jù)不一致現(xiàn)象；在主節(jié)點因為網(wǎng)絡(luò)問題而短暫失聯(lián)時候，如果某個從節(jié)點提升為主節(jié)點，則可能發(fā)生腦裂現(xiàn)象；

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

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

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

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

innodb副本集的運行環(huán)境有一定的要求，如下：

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

2、僅支持GTID的復(fù)制方法

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

4、不支持復(fù)制過濾器

5、不允許建立額外的復(fù)制通道

6、副本集primary節(jié)點只有一個，secondary節(jié)點可以有多個，MySQL Router會對每個節(jié)點進(jìn)行監(jiān)控

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

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

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