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 ??

關于 GreatSQL

GreatSQL是由萬里資料庫維護的MySQL分支，專注于提升MGR可靠性及性能，支持InnoDB并行查詢特性，是適用于金融級應用的MySQL分支版本，

相關鏈接： GreatSQL社區 Gitee GitHub Bilibili

GreatSQL社區：

社區博客有獎征稿詳情：https://greatsql.cn/thread-100-1-1.html

技術交流群：

微信：掃碼添加GreatSQL社區助手微信好友，發送驗證資訊加群，

標籤：MySQL

上一篇：快速上手kettle（三）壺中可以放些啥？

下一篇：返回列表