本文介紹GreatSQL的一些關鍵新特性，相關特性主要針對GreatSQL 8.0.x版本（不含GreatSQL 5.7.x版本中的相關特性）。

1. 地理標簽

可以對每個節點設置地理標簽，主要用于解決多機房數據同步的問題。

新增選項 group_replication_zone_id，用于標記節點地理標簽。該選項值支持范圍 0 ~ 8，默認值為0。

當集群中各節點該選項值設置為不同的時候，就被認定為設置了不同的地理標簽。

在同城多機房部署方案中，同一個機房的節點可以設置相同的數值，另一個機房里的節點設置另一個不同的數值，這樣在事務提交時會要求每組 group_replication_zone_id 中至少 有個節點確認事務，然后才能繼續處理下一個事務。這就可以確保每個機房的某個節點里，總有最新的事務。

2. 仲裁節點

該節點僅參與MGR投票仲裁，不存放實際數據，也無需執行DML操作，因此可以用一般配置級別的服務器，在保證MGR可靠性的同時還能降低服務器成本。

新增參數group_replication_arbitrator用于設置仲裁節點。

若想新增一個仲裁節點，只需在 my.cnf 配置文件中添加如下配置：group_replication_arbitrator = true

當集群中只剩下 Arbitrator 節點時，則會自動退出。

注意：

在有仲裁節點的情況下，將單主切換成多主模式時，需要把投票節點先關閉再機型切換，否則可能會導致切換失敗，并且仲裁節點報錯退出MGR。

即便是在關閉MGR服務狀態下，仲裁節點中也無法執任何有數據變更的操作。

3. 快速單注

GreatSQL中增加一個新的工作模式：單主快速模式，在這個模式下，不再采用MySQL MGR原有的認證數據庫方式。新增選項 group_replication_single_primary_fast_mode 用于 設置是否啟用，以及具體采用哪種模式。

快速單主模式特別適合在跨機房部署，壓力測試以及內存要求不高等多種場景。這種模式弱于傳統的異步復制，但強于半同步復制，且沒有MGR默認的認證數據庫可能消耗較大內存的問 題。

提醒，啟用快速單主模式時，不支持采用多主模式；所有節點都得設置必須相同，否則無法啟動。

選項 group_replication_single_primary_fast_mode 可選值有：0、1、2，不同值分別表示如下：

• 0，表示不采取快速單主模式，這是默認值。
• 1，表示采用快速單主模式，支持并并回放。**強烈建議設置為1，即啟用快速單主模式。**- 2，表示采用快速單主模式，但不支持并行回放，加速relay log落盤，且讓從庫消耗更少的資源。

4. 自定義選主策略

完善自動選主機制，增加基于最新GTID判斷來選主，避免自動選擇沒有最新GTID的節點作為新主。

默認地，MGR根據以下規則選主：

• 當有MySQL 5.7和MySQL 8.0不同版本的節點混合部署時，只會選擇運行5.7的節點作為主節點。此外，在 <= MySQL 8.0.16 版本時，以主版本號進行排序，也就是說 5.7 排在 8.0 前面。在 > MySQL 8.0.17版本中，則是以補丁版本號排序，也就是 8.0.17 排在 8.0.25 前面。
• 當所有節點版本號一致時，則根據節點權重值（選項 group_replication_member_weight 定義權重值，這個選項5.7版本沒有，8.0開始新增）排序，權重值高的節點排在前面。
• 根據節點 server_uuid 排序。

在一些情況下，在MGR所有節點都發生意外要重新拉起時，不會檢查各節點事務應用狀態，而錯誤選擇新的主節點，這時可能會導致丟失一些事務數據。或者當原來的主節點crash需要 重新投票選擇新的主節點時，可能也會選擇一個權重值較高，但沒有最新事務的節點，也會存在丟失一部分事務數據的風險。

在GreatSQL中，新增選項 group_replication_primary_election_mode 用于自定義選主策略，可選值有以下幾個：

• WEIGHT_ONLY，還是按照上述傳統模式自動選主，這是默認值。
• GTID_FIRST，優先判斷各節點事務應用狀態，自動選擇擁有最新事務的節點作為新的主節點。推薦設置為該模式。
• WEIGHT_FIRST，傳統模式優先，如果沒有合適的結果再判斷各節點事務狀態。

提醒，所有節點都的設置必須相同，否則無法啟動。

5. 并行查詢

根據B+樹的特點，可以將B+樹劃分為若干子樹，此時多個線程可以并行掃描同一張InnoDB表的不同部分。對執行計劃進行多線程改造，每個子線程執行計劃與MySQL原始執行計劃一致， 但每個子線程只需掃描表的部分數據，子線程掃描完成后再進行結果匯總。通過多線程改造，可以充分利用多核資源，提升查詢性能。

優化后，在TPC-H測試中表現優異，最高可提升30倍，平均提升15倍。該特性適用于周期性數據匯總報表之類的SAP、財務統計等業務。

使用限制：

暫不支持子查詢，可想辦法改造成JOIN。

暫時只支持ARM架構平臺，X86架構平臺優化也會盡快完成。

更多關于InnoDB并行查詢相關選項參考文檔 InnoDB并行查詢優化參考(https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/docs/innodb-parallel-execute.md)。

6. GreatSQL VS MySQL社區版