GreatSQL 8.0.32-26 今日發佈

版本信息

• 發佈時間：2024年08月05日

• 版本號：8.0.32-26, Revision a68b3034c3d

• 下載鏈接：https://gitee.com/GreatSQL/GreatSQL/releases/tag/GreatSQL-8.0.32-26

• 用戶手冊：https://greatsql.cn/docs/8.0.32-26/

特性增強

GreatSQL 8.0.32-26 版本在 高可用、高性能、高相容、高安全 等多方面都有增強新特性，包括 Clone 增量備份、壓縮備份，MGR 新加入成員節點時自動選擇最新數據節點為 donor 節點，NUMA 親和性優化，非阻塞式 DDL，無主鍵表導入優化，更多 Oracle 相容用法，最後登錄信息，基於規則的數據脫敏功能等多個新特性。

高可用

• 當有新成員節點加入 MGR 時，如果選擇 Clone 方式複製數據，支持自動選擇從最新事務數據的成員節點複製數據，可有效提升 Clone 速度，提高 MGR 的服務可靠性。當新加入節點觸發 Clone 方式複製數據時，也支持該特性。

  參數 group_replication_donor_threshold 用於定義選擇 donor 節點時判斷事務延遲閾值，取值範圍 [1, MAX]，預設值為 MAX。MAX 值取決於 CPU 類型，在 32-bit 系統中是 2147483647（2^31-1），而在 64-bit 系統中是 9223372036854775807（2^63-1）。

  當新成員節點加入 MGR 時，新成員節點只會選擇那些延遲小於 group_replication_donor_threshold 的節點作為 donor 節點。

  假設 group_replication_donor_threshold = 100，那麼：

1. 現在 MGR 中有兩個節點A、B，它們的 GTID 分別是 [1-300]、[1-280]，新節點 C 加入，由於 A & B 節點的 GTID 差值小於預設閾值，則隨機選擇 A 或 B 其中一個節點作為 donor 節點。
2. 現在 MGR 中有兩個節點A、B，它們的 GTID 分別是 [1-400]、[1-280]，新節點 C 加入，由於 A & B 節點的 GTID 差值大於預設閾值，則只會選擇 A 作為 donor 節點。
3. 現在 MGR 中有三個節點A、B、C，它們的 GTID 分別是 [1-400]、[1-350]、[1-280]，新節點 D 加入，由於 C 節點的 GTID 差值大於預設閾值，A & B 節點 GTID 延遲小於預設閾值，則會隨機選擇 A 或 B 其中一個作為 donor 節點。

• 在主從複製中，由從節點向主節點發起 Binlog 讀取請求，如果讀取太快或併發太多線程就會加大主節點的壓力。新增參數 rpl_read_binlog_speed_limit 用於控制從節點上向主節點發起 Binlog 讀取請求的限速，這對於控制主從複製中的網路帶寬使用率、降低主節點壓力、或在數據恢復過程中降低消耗資源非常有用。該參數可在從節點端設置生效。

  • Binlog 讀取限速 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-2-ha-binlog-speed-limit.html

• 優化了在 快速單主模式 下 relay log 應用邏輯，提升 MGR 整體性能；並優化了當 relay log 存在堆積時的 applier 線程的記憶體消耗異常情況。

  • 快速單主模式 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-2-ha-mgr-fast-mode.html

• 優化了 asynchronous connection failover 中的故障檢測效率，特別是發生網路故障時，備用集群能更快完成主從複製通道調整，降低主從複製鏈路斷開的時間，提高整體可用性。以設置 MASTER_RETRY_COUNT = 2 為例（slave_net_timeout 和 MASTER_CONNECT_RETRY 預設值均為 60），在主從複製通道間發生網路故障時導致的複製中斷持續約 3 分鐘，優化後故障影響時長縮短到 10 - 20 秒以內。可以利用 asynchronous connection failover 實現兩個 MGR 集群間的主從複製，實現跨機房間的高可用切換方案。

  • asynchronous connection failover ➥ https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-connection-failover.html

• 地理標簽 功能中包含兩個參數 group_replication_zone_id（預設值為 0）和 group_replication_zone_id_sync_mode（預設值為ON）。在舊版本中，要求各個節點的 group_replication_zone_id_sync_mode 保持一致，否則無法加入 MGR。新版本中，允許仲裁節點設置不同的 group_replication_zone_id_sync_mode。例如，節點 A1、A2 設置 group_replication_zone_id = 0 & zone_id_sync_mode = ON；節點 B1、B2 設置 group_replication_zone_id = 1，它們也必須設置 zone_id_sync_mode = ON；仲裁投票節點C 設置 group_replication_zone_id = 2，但可以設置 group_replication_zone_id_sync_mode = OFF。

  • 地理標簽 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-2-ha-mgr-zoneid.html

• 當啟用 greatdb_ha Plugin 時，新增支持 IPv6。

更多信息詳見文檔：高可用 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-2-ha.html

高性能

• 支持非阻塞式 DDL 操作。當執行 DDL 操作的表上有大事務或大查詢未結束時，會導致 DDL 請求長時間等待.htmlL 鎖。利用該特性，可以避免資料庫因為必須儘快完成 DDL 操作而導致業務請求大量被阻塞的問題。

  • 詳見：非阻塞式 DDL ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-1-highperf-nonblocking-ddl.html

• NUMA 親和性優化。通過 NUMA 親和性調度優化，將前端用戶線程和後臺線程綁定到固定 NUMA 節點上以提升線程處理性能。

  • 詳見：NUMA 親和性優化 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-1-highperf-numa-affinity.html

• 無顯式主鍵表並行導入性能優化。對無顯式主鍵表並行導入數據時，會隨著併發數的增加，性能明顯下降，GreatSQL針對這種情況也提供了優化方案。

  • 詳見：並行 LOAD DATA ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-1-highperf-parallel-load.html

更多信息詳見文檔：高性能 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-1-highperf.html

高相容

• 新增支持在 LOOP 迴圈使用 CONTINUE 語法。

  • 詳見：CONTINUE ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/sql-compat/5-3-easyuse-ora-sp-continue.html

• 新增支持用 CREATE OR REPLACE 語法創建/修改觸發器；新增支持在觸發器中使用 DECLARE BEGIN 語法。

  • 詳見：觸發器 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/sql-compat/5-3-easyuse-ora-sp-trigger.html

• 新增支持在匿名塊中使用 DECLARE BEGIN 語法。

  • 詳見：匿名塊 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/sql-compat/5-3-easyuse-ora-sp-anony-block.html

• 新增支持在 FOR/FOR ALL ... LOOP 用法中使用符號和參數相連，例如 FOR var1..var2 LOOP。

  • 詳見：FOR LOOP ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/sql-compat/5-3-easyuse-ora-sp-for-loop.html
  • FORALL LOOP ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/sql-compat/5-3-easyuse-ora-sp-forall-loop.html

更多信息詳見文檔：高相容 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-3-easyuse.html

高安全

• 新增支持記錄指定用戶的最後一次登入時間，便於管理員查詢，進一步提升資料庫安全性。

  • 詳見：最後登錄信息 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-4-security-last-login.html

• 新增支持基於規則的數據脫敏功能。

  • 詳見：數據脫敏 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-4-security-data-masking.html

更多信息詳見文檔：高安全 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-4-security.html

其他

• 支持採用 Clone 實現線上全量熱備和增備以及恢復（類似 Xtrabackup），結合 Binlog 可實現恢復到指定時間點。此外，Clone 備份還支持壓縮功能。

  • 詳見：Clone 備份 ➥ https://greatsql.cn/docs/8.0.32-26/5-enhance/5-5-clone-compressed-and-incrment-backup.html

• 合併龍芯支持 patch，參考：add loongarch64 support ➥ https://gitee.com/src-openeuler/greatsql/pulls/54/files

• 由於 GreatSQL 已支持 Rapid 引擎，以及未來還將推出 dplan 特性，因此從 GreatSQL 8.0.32-26 開始，不再推薦使用 InnoDB 並行查詢特性（同時會刪除用戶手冊中的入口鏈接）。

缺陷修複

• 修複了在部分 ARM 架構環境中無法使用並行複製的問題，詳見：MySQL Bug 110752 ➥ https://bugs.mysql.com/bug.php?id=110752
• 修複了最後登錄信息和審計日誌入表時未處理 Binlog 可能導致主從異常的問題。在新版本中，最後登錄信息和審計日誌都不會記錄 Binlog，避免因為主從複製（也包括 MGR）中各實例都開啟該特性記錄 Binlog 而造成主從複製失敗（或 MGR 報錯）。
• 修複了數個因為 SQL 註入可能導致資料庫實例發生 coredump 的問題，大幅提升 GreatSQL 對 SQL 註入風險的抵禦能力。
• 修複了 Oracle 模式下 NULL 值唯一約束問題。在原來的 Oracle 模式下，插入 NULL 值會觸發唯一約束衝突；而在 Oracle 資料庫中，是允許向唯一約束列中重覆寫入 NULL 值的。在新版本中修複了這個問題。

-- 在老版本中
greatsql> SET sql_mode = ORACLE;
greatsql> CREATE TABLE t1 (c1 INT UNIQUE);
greatsql> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE "t1" (
  "my_row_id" bigint unsigned NOT NULL AUTO_INCREMENT /*!80023 INVISIBLE */,
  "c1" int DEFAULT NULL,
  PRIMARY KEY ("my_row_id"),
  UNIQUE KEY "c1" ("c1") /* nulls are equal in unique index as oracle does */
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

greatsql> INSERT INTO t1 SELECT NULL;
Query OK, 1 row affected (0.01 sec)
Records: 1  Duplicates: 0  Warnings: 0

greatsql> INSERT INTO t1 SELECT NULL;
ERROR 1062 (23000): Duplicate entry 'NULL' for key 't1.c1'

在新版本中修複了這個唯一性約束問題：

-- 在新版本中
greatsql> SET sql_mode = ORACLE;
greatsql> CREATE TABLE t1 (c1 INT UNIQUE);
greatsql> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE "t1" (
  "my_row_id" bigint unsigned NOT NULL AUTO_INCREMENT /*!80023 INVISIBLE */,
  "c1" int DEFAULT NULL,
  PRIMARY KEY ("my_row_id"),
  UNIQUE KEY "c1" ("c1") /* nulls are equal in unique index as oracle does */
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

greatsql> INSERT INTO t1 SELECT NULL;
Query OK, 1 row affected (0.01 sec)
Records: 1  Duplicates: 0  Warnings: 0

-- 不再報告唯一性約束衝突
greatsql> INSERT INTO t1 SELECT NULL;
Query OK, 1 row affected (0.01 sec)
Records: 1  Duplicates: 0  Warnings: 0

• 修複了開啟線程池後，當邏輯 CPU 核數大於 128 時會觸發 coredump 的問題

  • 詳見：mysqld debug version will core if the number of cpu cores is larger than 128 ➥ https://github.com/GreatSQL/GreatSQL/issues/5

• 修複了在 greatdb_ha Plugin 中啟用 VIP 後因系統環境問題或配置不當可能導致 GreatSQL 在啟動 MGR 後發生 coredump 的問題

  • 詳見：Issue#I9VTF8 ➥ https://gitee.com/GreatSQL/GreatSQL/issues/I9VTF8?from=project-issue

• 修複了用RPM包和TAR二進位包不同方式安裝會造成 lower_case_table_names 的預設設置不同的問題。

• 修複了在空跑或低負載時，進程 CPU 消耗較高的問題。

• 修複了 預設安裝多了sys_audit庫 問題

  • 詳見：Issue#I8TL52 ➥ https://gitee.com/GreatSQL/GreatSQL/issues/I8TL52?from=project-issue

• 修複了 merge view 後導致 assert fail 問題

  • 詳見：Issue#IABSE6 ➥ https://gitee.com/GreatSQL/GreatSQL/issues/IABSE6?from=project-issue

• 修複了 full join 執行計劃不正確問題

  • 詳見：Issue#IADFD7 ➥ https://gitee.com/GreatSQL/GreatSQL/issues/IADFD7?from=project-issue

註意事項

無。

升級/降級到 GreatSQL 8.0.32-26

升級到 GreatSQL 8.0.32-26

以下是升級到 GreatSQL 8.0.32-26 的幾種不同場景說明。

• 如果舊版本是 GreatSQL 8.0.32-25，並且沒有使用 Rapid 引擎，則可以直接在原來的 datadir 基礎上，修改 basedir 後，原地（in-place）啟動 GreatSQL 8.0.32-26 後會完成自動升級。
• 如果舊版本是 GreatSQL 8.0.32-25，並且已啟用 Rapid 引擎，這種情況下暫時先不要升級，可以等到後續發佈帶新版本 Rapid 引擎的 GreatSQL 8.0.32-26 版本後再升級。
• 如果舊版本是 GreatSQL 8.0.32-24、8.0.25-*、5.7.36-39 等系列版本，則可以直接在原來的 datadir 基礎上，修改 basedir 後，原地（in-place）啟動 GreatSQL 8.0.32-26 後會完成自動升級。
• 如果是 MySQL 8.0.（<= 8.0.32 版本）、Percona Server 8.0.（<= 8.0.32 版本）等系列版本，則可以直接在原來的 datadir 基礎上，修改 basedir 後，原地（in-place）啟動 GreatSQL 8.0.32-26 後會完成自動升級。
• 如果是 MySQL 8.0.（> 8.0.32 版本）、Percona Server 8.0.（> 8.0.32 版本）等系列版本，則需要利用邏輯備份方式導出數據，再導入的方式完成升級，不支持原地（in-place）升級到 GreatSQL 8.0.32-26。
• 如果是 MySQL 5.7.（>= 5.7.23 版本）、Percona Server 5.7.（<= 5.7.23 版本）等系列版本，則可以直接在原來的 datadir 基礎上，修改 basedir 後，原地（in-place）啟動 GreatSQL 8.0.32-26 後會完成自動升級。

在以上幾個原地升級場景中，務必保證 GreatSQL 中參數 upgrade 不能設置為 NONE，可以設置為預設的 AUTO 或 FORCE。例如：

[mysqld]
upgrade = AUTO

更多遷移升級方案請參考：遷移升級。

降級到 GreatSQL 8.0.32-26

如果是要從 MySQL/Percona 8.0.32 之後的版本降級到 GreatSQL 8.0.32-26 版本，則需要採取邏輯備份 + 邏輯導入方式完成降級操作，並且在邏輯備份導入完成後的首次重啟時，務必設置 upgrade = FORCE 強制升級所有數據表，包括系統表。

降級過程操作大致如下所示：

1. 在高版本中邏輯備份全量數據

$ mysqldump -S/data/MySQL/mysql.sock -A --triggers --routines --events --single-transaction > /data/backup/fulldump.sql

2. 在GreatSQL 8.0.32-26版本環境中導入邏輯備份文件，完成邏輯恢復

$ mysql -S/data/GreatSQL/mysql.sock -f < /data/backup/fulldump.sql

3. 修改my.cnf，確保 upgrade = FORCE 設置

$ vim /etc/my.cnf
...
[mysqld]
...
upgrade = FORCE
...

4. 重啟GreatSQL，降級完成

$ systemctl restart greatsql

重啟過程中，可以看到日誌有類似下麵的強制升級過程

$ tail -f /data/GreatSQL/error.log
...
[Note] [MY-013387] [Server] Upgrading system table data.
[Note] [MY-013385] [Server] Upgrading the sys schema.
[Note] [MY-013400] [Server] Upgrade of help tables started.
[Note] [MY-013400] [Server] Upgrade of help tables completed.
[Note] [MY-013394] [Server] Checking 'mysql' schema.
[Note] [MY-013394] [Server] Checking 'sys' schema.
[System] [MY-013381] [Server] Server upgrade from '80032' to '80032' completed.
...

如果不設置 upgrade = FORCE 強制升級所有表，有可能發生系統表 mysql.procs_priv 損壞錯誤，在創建用戶時可能會報告類似下麵的錯誤：

greatsql> create user tpch identified by 'tpch';
ERROR 1728 (HY000): Cannot load from mysql.procs_priv. The table is probably corrupted

GreatSQL VS MySQL

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

GreatSQL Release Notes

GreatSQL 8.0

• Changes in GreatSQL 8.0.32-26 (2024-08-05)
• Changes in GreatSQL 8.0.32-25 (2023-12-28)
• Changes in GreatSQL 8.0.32-24 (2023-6-5)
• 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 (2021-8-26)

GreatSQL 5.7

• Changes in GreatSQL 5.7.36-39 (2022-4-7)

Enjoy GreatSQL