GreatSQL 8.0.32-24 今日發佈

• 1.新增特性

• • 1.1 SQL相容性
  • 1.2 MGR
  • 1.3 性能優化
  • 1.4 安全

• 2.穩定性提升

• 3.其他調整

• 4.bug修複

• 5.GreatSQL VS MySQL

• 6.GreatSQL Release Notes

GreatSQL 8.0.32-24版本發佈，增加並行load data、（邏輯 & CLONE）備份加密、MGR讀寫節點可綁定動態VIP、Oracle相容擴展、審計日誌增強等重磅特性。

直播預告：GreatSQL 8.0.32-24發佈會

直播時間：2023.06.05 15:00 - 16:00

掃碼預約發佈會或點擊下方閱讀原文進行報名

0.項目信息

• 代碼倉庫：https://gitee.com/GreatSQL/GreatSQL
• 最新下載：https://gitee.com/GreatSQL/GreatSQL/releases/tag/GreatSQL-8.0.32-24
• 項目文檔：https://greatsql.cn/docs
• 項目官網：https://greatsql.cn

1.新增特性

1.1 SQL相容性

在GreatSQL 8.0.32-24中，實現了多項SQL相容性功能，包括數據類型擴展、SQL語法等超過20個相容特性。

1.1.1 數據類型擴展

• CLOB
• VARCHAR2

1.1.2 SQL語法

• DATETIME 運算
• ROWNUM
• 子查詢無別名
• EXPLAIN PLAN FOR

1.1.3 函數

• ADD_MONTHS()
• CAST()
• DECODE()
• INSTR()
• LENGTH()
• LENGTHB()
• MONTHS_BETWEEN()
• NVL()
• SUBSTRB()
• SYSDATE()
• TO_CHAR()
• TO_DATE()
• TO_NUMBER()
• TO_TIMESTAMP()
• TRANSLATE()
• TRUNC()
• SYS_GUID()

更多信息詳見文檔：GreatSQL中的SQL相容性（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/greatsql-803224/sql-compat.md）

1.2 MGR

1.2.1 MGR內置動態VIP

在GreatSQL 8.0.32-24中，新增MGR讀寫節點支持綁定VIP（虛擬IP）特性。利用該特性，使得MGR在單主模式下運行時，能自動識別讀寫節點並綁定VIP，支持應用端即可通過VIP對資料庫發起讀寫請求，當讀寫節點角色發生變化時，VIP也會隨之自動漂移並重新綁定，應用端無需修改VIP配置。

更多信息詳見文檔：GreatSQL中MGR支持內置vip特性（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/greatsql-803224/mgr-vip.md）

1.2.2 新增applier queue批處理機制

新增相應選項 group_replication_applier_batch_size_threshold。當MGR中的併發事務太大，或者個別Secondary節點（磁碟I/O）性能較差時，可能會導致applier queue堆積越來越大，一直無法及時跟上Primary節點。

這時候有效的辦法就是讓applier queue落地時採用批量的方式，提高落盤效率。預設地，applier queue里的event是逐個落盤的，這種方式效率很低。當applier queue超過 group_replication_applier_batch_size_threshold 設定的閾值時，就會觸發批量落盤模式，每100個event批量落盤，就能大大提高落盤效率。

在生產環境中，選項 group_replication_applier_batch_size_threshold 值不要設置太小，建議不低於10000。預設值 100000，最小值10（僅用於開發、測試環境），最大值100000000（基本上等於禁用）。一個大事務會包含很多個event，當該選項設置太低時，可能會導致一個事務中的event沒辦法及時落盤，會造成relay log不完整，節點crash時，就需要從Primary節點重新讀取binlog進行恢復。

1.2.3 Xcom cache分配靜態化

在MySQL 5.7里，Xcom cache size最大值1G，且不可動態調整。從MySQL 8.0開始，可對其動態調整。在 <= MySQL 8.0.20的版本中，最小值1G。在>= MySQL 8.0.21的版本中，最小值128M。

在MySQL中，是動態按需分配Xcom cache的，如果太多有空閑，就釋放；如果不夠用，再動態分配更多記憶體，一次分配大概250000個cache item，很容易造成約150ms的響應延遲。也就是說，會隨著事務多少的變化而可能頻繁產生響應延遲。

在GreatSQL中，對Xcom cache採用了靜態化分配機制，即一開始就預分配約1GB記憶體用於Xcom cache，這可以避免前面提到的響應延遲抖動風險，不過“副作用”是mysqld進程所占用的記憶體會比原來多，在記憶體特別緊張的伺服器上不太適合。

新增相應選項 group_replication_xcom_cache_mode 用於設置Xcom cache靜態化初始大小：

1.2.4 其他優化

• 優化了孟子演算法，使得無論是單主模式還是多主模式下，均有不同程度的性能提升。
• 消除了殺節點進程場景下的性能抖動。
• 優化了加入節點時可能導致性能劇烈抖動的問題。
• 優化手工選主機制，解決了長事務造成無法選主的問題。
• 完善MGR中的外鍵約束機制，降低或避免從節點報錯退出MGR的風險。
• 提升了Secondary節點上大事務併發應用回放的速度。
• 增加Xcom cache條目，提升了在網路延遲較大或事務應用較慢場景下的性能。
• 新增參數選項：group_replication_broadcast_gtid_executed_period 用於設置節點之間各自廣播節點的gtid值的頻率，單位為毫秒，預設為1000，最小200，最大60 000，配合新的事務認證隊列清理演算法，進行認證資料庫的清理操作。收到所有節點的gtid後，就可以清理都執行完畢的gtid的認證信息了。
• 新增參數選項：group_replication_flow_control_max_wait_time，用於設置每次觸發流控時，流控等待的最大時長，預設為3600s，最大為86400s（1天）。

1.3 性能優化

1.3.1 並行load data

MySQL原生的load data採用單線程讀取本地文件（或收取client傳來的網路數據包），逐行獲取內容後再插入數據。

當導入的單個文件很大時，單線程處理模式無法充分利用資料庫的資源，導致執行時間很長。又由於load data導入的數據在一個事務內，當binlog事務超過2G時，可能會導致無法使用binlog在MGR集群間同步。

為解決上述兩個問題，GreatSQL支持了load data並行導入。開啟並行導入後，會自動切分文件成小塊（可配置），然後啟動多個worker線程（數量可配置）導入文件塊。並行導入與engine無關，理論上支持任何存儲引擎。

更多信息詳見文檔：GreatSQL中的並行load data特性（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/greatsql-803224/parallel_load_data.md）

1.3.2 優化器優化

優化了執行計劃，使得benchmark tpcc測試吞吐量更高，也更加穩定。

1.4 安全

1.4.1 mysqldump備份加密

GreatSQL 8.0.32-24支持在mysqldump進行邏輯備份時產生加密備份文件，並且也支持對加密後的備份文件解密導入。

更多信息詳見文檔：GreatSQL中的邏輯備份加密特性（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/greatsql-803224/mysqldump-encrypt.md）

1.4.2 審計日誌入表

GreatSQL支持將審計日誌寫入數據表中，並且設置審計日誌入表規則，以便達到不同的審計需求。

審計內容將包括操作賬戶、客戶端ip、被操作的資料庫對象、操作的完整語句、操作結果。

更多信息詳見文檔：GreatSQL中的審計日誌入表特性（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/greatsql-803224/audit-log-in-table.md）

1.4.3 表空間國密加密

在開源MySQL原有keyring架構，通過國密演算法，增強開源MySQL keyring架構的安全性。MySQL的表空間加密keyring架構包含2層加密，master key 和 tablespace key。

• master key用於加密tablespace key，加密後的結果存儲在tablespace的header中。
• tablespace key用於加密數據

當用戶想訪問加密的表時，InnoDB會先用master key對之前存儲在header中的加密信息進行解密，得到tablespace key。再用tablespace key解密數據信息。tablespace key是不會被改變的，而master key可以隨時改變。開源MySQL的master key採用keyring_file插件，key file直接存儲在磁碟上。

本功能點通過基於國密演算法sm4，增加了資料庫的安全性。

創建國密演算法加密表

CREATE TABLE test.t1(c1 INT, c2 INT) ENGINE = InnoDB ENCRYPTION = 'Y';

更多信息詳見文檔：GreatSQL中的表空間加密國密支持（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/greatsql-803224/innodb-tablespace-encrypt.md）

1.4.4 CLONE備份加密

GreatSQL支持在利用CLONE備份時同步進行加密操作，提升備份文件安全性，避免備份文件被盜或泄漏時造成損失。

更多信息詳見文檔：CLONE備份加密（https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/relnotes/greatsql-803224/clone-encrypt.md）

2.穩定性提升

3.其他調整

4.bug修複

• 修複InnoDB並行查詢可能導致查詢hang住，甚至crash的問題。

5. GreatSQL VS MySQL

此外，GreatSQL 8.0.32-24基於Percona Server for MySQL 8.0.32-24版本，它在MySQL 8.0.32基礎上做了大量的改進和提升以及眾多新特性，詳情請見：Percona Server for MySQL feature comparison（https://docs.percona.com/percona-server/8.0/feature_comparison.html#percona-server-for-mysql-feature-comparison），這其中包括線程池、審計、數據脫敏等MySQL企業版才有的特性，以及PFS提升、IFS提升、性能和可擴展性提升、用戶統計增強、processlist增強、slow log增強等大量改進和提升，這裡不一一重覆列出。

6. GreatSQL Release Notes

• Changes in GreatSQL 8.0.25-17 (2023-3-13)
• Changes in GreatSQL 8.0.25-16 (2022-5-16)
• Changes in GreatSQL 8.0.25-15 (2022-8-26)
• Changes in GreatSQL 5.7.36-39 (2022-4-7)

Enjoy GreatSQL