Group Replication 組復制 1、特性： a、高一致性，以插件方式提供一致數據安全保證 b、高容錯性，大多數服務正常就可繼續工作，自動不同節點檢測資源征用沖突，按順序優先處理。內置自動防腦裂機制。 c、高擴展性，自動添加移除節點，并更新組信息。 d、高靈活性，單主模式和多住模式。單主模式自動選主，所有更新操作在主進行。多主模式，所有server同時更新。 2、事務并發沖突處理： 兩個不同的事務在兩個節點上操作同一行數據，就會有沖突。GR會采用樂觀策略，依賴事務提交的時間先后順序，先發起提交的節點能夠正確提交，后面的提交會失敗。 3、節點故障自動檢測： 組內節點心跳檢測來識別出組內成員是否掛掉。當一個節點失敗，將由其他節點決定是否將這個失效的節點從group里面剔除。當然這是建立在滿足大多數節點存活并且可以進行決議的前提上。 4、容錯能力 GR基于分布式一致性算法實現，一個組允許部分節點掛掉。只要大多數節點仍然存活并且之間通訊沒有問題，那么這個組對外仍能正常提供服務。 如3個節點可以最多掛掉一個。建議由奇數個節點組成。當由偶數時，出現一半節點掛掉，兩邊都沒有大多數，因此整個集群實際上處于不可用。 若不滿足大多數，所有事務寫操作都會阻塞，直到集群滿足大多數節點存活為止。 5、兩種模式 a、單主模式：single-primary 組內只有一個節點負責寫入，讀可以從任意一個節點讀取。默認是單主 b、多主模式：multi-primary 寫操作交下發到組內所有節點，組內所有節點同時可讀可寫。 通過在my.cnf中進行定義 group_replication_single_primary_mode 6、single-primary:只有一臺可寫，其他只能讀 read_only=0 可讀可寫 read_only=1 只讀 部署步驟： 先將primary啟動，設置可讀可寫，然后再將其他節點一一加進group。其他節點會自動同步primary節點上的變化，將自己設置為只讀。 故障自動修復： 當primary節點掛掉，其他節點會進行選舉，提升為primary節點。選舉規則是根據server_uuid升序來選擇，排在最前面的提升為primary節點。 查看當前是否為primary節點？ select @@read_only; 0 為可讀可寫，為primary 7、組復制要求和限制 引擎為innodb 每個表必須提供主鍵 只支持ipv4 一個group最多只能有9個節點 不支持replication event checksums，需在my.cnf中配置 不支持savepoints （保存點） multi-primary的限制（以上的也包括） : 不支持serializable事務隔離級別，（串行） 不能完全支持外鍵約束 不支持在不同節點上對同一個數據庫對象并發執行DDL語句（在不同節點上并發進行RW事務，后發起的事務會失敗） 8、組復制配置 server_id=1 唯一標識符 log-bin=log_file_name 開啟binlog模式 binlog-format=row 行模式 gtid-mode=ON 全局事務ID master-info-repository=TABLE 　　 這兩個參數會將master.info和relay.info保存在表中 relay-log-info-repository=TABLE transaction-write-set-extraction=XXXHASH64 log-slave-updates=true 當從庫log_slave_updates參數沒有開啟時，從庫的binlog不會記錄來源于主庫的操作記錄。只有開啟log_slave_updates，從庫binlog才會記錄主庫同步的操作日志。 binlog-checksum=NONE 其中 type 包含：1）CRC32，使用 ISO-3309 CRC-32 校驗和；2）NONE，即關閉校驗和。默認是 CRC32 以下部分是server組復制的配置 transaction_write_set_extraction=XXHASH64 loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" loose-group_replication_start_on_boot=off loose-group_replication_local_address= "127.0.0.1:24901" loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903" loose-group_replication_bootstrap_group= off 第1行指示server必須為每個事務收集寫集合，并使用XXHASH64哈希算法將其編碼為散列。 第2行告知插件，正在加入或創建的組要命名為“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”。 第3行指示插件在server啟動時不自動啟動組復制。 第4行告訴插件使用IP地址127.0.0.1或本地主機，端口24901用于接受來自組中其他成員的傳入連接 第5行告訴插件，當下面這些server需要加入組時，應該連接到這些主機和端口上訪問他們。這些就是種 子成員，當此成員想要連接到組時使用 第6行指示插件是否自動引導組，此選項在任何時候只能在一個server實例上使用，通常是首次引導組時 組復制是一種可用于實現容錯系統的技術。復制組是一個通過消息傳遞相互交互的服務器組。通信層提供了很多保證， 例如原子消息和總消息序號的傳遞。通過這些強大的特性，我們可以構建更高級的數據庫復制解決方案。 MySQL組復 制構建在這些屬性和抽象之上，并實現多主復制協議的更新。實質上，復制組由多個數據庫實例組成，并且組中的每 個實例都可以獨立地執行事務。但是所有讀寫（RW ）事務只有在被組批準后才會提交。只讀（RO）事務不需 要在組內協調，因此立即提交。換句話說，對于任何RW事務，組需要決定是否提交，因此提交操作不是來 自始發服務器的單向決定。準確地說，當事務準備好在始發服務器上提交時，該始發服務器原子地廣播寫 入值（已改變的行）和對應的寫入集（已更新的行的唯一標識符）。然后為該事務建立一個全局總序號。 最終，這意味著所有服務器以相同的順序接收同一組事務。因此，所有服務器以相同的順序應用相同的一 組更改，因此它們在組內保持一致。 但是，在不同服務器上并發執行的事務之間可能存在沖突。通過檢查兩個不同的并發事務的寫集合來檢測這樣的沖突， 這個檢查過程稱為認證（ certification ）。如果在不同的服務器上執行的兩個并發事務更新同一行，則會出現沖突。解 析過程會這么做，首先發起的事務在所有服務器上提交，而后發起的事務將在源服務器上回滾，并由組中的其他服務 器刪除。這實際上是一個分布式環境下“優先提交者贏”的規則。