前提條件

PolarDB集群版本需為以下版本之一，您可以通過查詢版本號確認集群版本：

• PolarDB MySQL版8.0.1版本且Revision version為8.0.1.1.10及以上。

• PolarDB MySQL版5.7版本且Revision version為5.7.1.0.10及以上。

使用限制

• 目前并行DDL物理復制優化僅支持創建主鍵或二級索引（不包括全文索引和空間索引）的DDL操作。

• 對于只需修改元數據的DDL操作（如rename），因其本身執行速度已經很快，無需使用該優化功能。

• 不支持在PolarDB MySQL版8.0.2版本和5.6版本使用該優化功能。

背景信息

PolarDB通過存儲計算分離架構，實現了主節點和只讀節點共享同一份存儲數據，既降低了存儲成本，又提高了集群的可用性和可靠性。為實現這一架構，PolarDB采用了業界領先的物理復制技術，不僅實現了共享存儲架構上主節點和只讀節點間的數據一致性，而且減少了Binlog fsync操作帶來的I/O開銷。

InnoDB中的數據是通過B-Tree來維護索引的，然而大部分Slow DDL操作（如增加主鍵或二級索引、optimize table等）往往需要重建或新增B-Tree索引，導致大量物理日志的產生。而針對物理日志進行的操作往往出現在DDL執行的關鍵路徑上，增加了DDL操作的執行時間。此外，物理復制技術要求只讀節點解析和應用這些新生成的物理日志，由于DDL操作而產生的大量物理日志可能嚴重影響只讀節點的日志同步進程，甚至導致只讀節點不可用等問題。

針對上述問題，PolarDB提供了DDL物理復制優化功能，在主節點寫物理日志和只讀節點應用物理日志的關鍵路徑上做了全面的優化，使得主節點在執行創建主鍵DDL操作的執行時間最多可減少20.6%，只讀節點解析DDL的復制延遲時間最多約可減少至原來的0.4%。

使用方法

您可以通過設置如下參數開啟DDL物理復制優化功能。

性能測試

• 測試準備

  • 測試環境

    • PolarDB MySQL版8.0版本的集群（包含1個主節點和1個只讀節點）規格為16核128 GB。

    • 集群存儲空間為50 TB。

  • 測試表結構

    通過如下語句創建一張名為t0的表：

    CREATE TABLE t0(a INT PRIMARY KEY, b INT) ENGINE=InnoDB;

  • 測試表數據

    使用如下語句生成隨機測試數據：

    DELIMITER //
    CREATE PROCEDURE populate_t0()
    BEGIN
         DECLARE i int DEFAULT 1;
         WHILE (i <= $table_size) DO
                 INSERT INTO t0 VALUES (i, 1000000 * RAND());
                 SET i = i + 1;
         END WHILE;
    END //
    DELIMITER ;
    CALL populate_t0();

    說明

    • 實際測試時請將$table_size替換成具體的表內記錄數，如1000000。

    • 本測試分別使用了包含1000000行、10000000行、100000000行、1000000000行記錄數的表。

  • 測試使用的DDL操作

    • add primary key

    • add secondary Index

    • optimize table

• 測試方法

  • 測試一：測試當物理復制DDL優化功能開啟或關閉時，在不同數據量的表中執行不同DDL操作所需的時間。

  • 測試二：測試當物理復制DDL優化功能與并行DDL配合使用時，在包含10億數據量的表中執行add secondary Index操作所需的時間。

  • 測試三：測試當物理復制DDL優化功能開啟或關閉時，集群（包含10億數據量的表）中主節點的并發執行DDL操作數量不同的情況下（1、2、4、6和8），只讀節點的性能（如節點狀態是否正常、CPU使用率峰值和復制延遲時間等）。

• 測試結果

  • 測試一

    • 當innodb_bulk_load_page_grained_redo_enable參數開啟或關閉時，測試在不同數據量（1百萬、1千萬、1億和10億）的表中執行add primary key(a)操作所需的時間（單位：秒），結果如下圖所示。

    • 當innodb_bulk_load_page_grained_redo_enable參數開啟或關閉時，測試在不同數據量（1百萬、1千萬、1億和10億）的表中執行optimize table操作所需的時間（單位：秒），結果如下圖所示。

  • 測試二

    • 并行DDL的innodb_polar_use_sample_sort和innodb_polar_use_parallel_bulk_load參數開啟的情況下，測試innodb_bulk_load_page_grained_redo_enable參數開啟或關閉后，在包含10億數據量的表中使用不同并行線程數（即設置innodb_polar_parallel_ddl_threads參數為1、2、4、8、16和32），執行add secondary Index操作所需的時間（單位：秒），結果如下圖所示。

    • 并行DDL的innodb_polar_use_sample_sort和innodb_polar_use_parallel_bulk_load參數關閉的情況下，測試innodb_bulk_load_page_grained_redo_enable參數開啟或關閉后，在包含10億數據量的表中使用不同并行線程數（1、2、4、8、16和32），執行add secondary Index操作所需的時間（單位：秒），結果如下圖所示。

  • 測試三

    • innodb_bulk_load_page_grained_redo_enable參數開啟的情況下，測試當集群（包含10億數據量的表）中主節點的并發執行DDL操作數量不同（1、2、4、6和8）時只讀節點的性能，結果如下表所示。

      并發DDL數量	1	2	4	6	8
      只讀節點狀態	正常	正常	正常	正常	正常
      CPU使用率峰值（單位：%）	1.86	1.71	1.76	2.25	2.36
      內存使用率峰值（單位：%）	10.37	10.80	10.88	11	11.1
      讀IOPS峰值（單位：次/每秒）	10965	10762	10305	10611	10751
      復制延遲峰值（單位：秒）	0	0.73	0.87	0.93	0.03

    • innodb_bulk_load_page_grained_redo_enable參數關閉的情況下，測試當集群（包含10億數據量的表）中主節點的并發執行DDL操作數量不同（1、2、4、6和8）時只讀節點的性能，結果如下表所示。

      說明

      • 并發DDL數為4時的數據為只讀節點不可用前的測試數據。

      • 表中-符號表示在當前并發DDL數場景下未能執行相關DDL操作，因此無相應測試數據。

      并發DDL數	1	2	4	6	8
      只讀節點狀態	正常	正常	不可用	不可用	不可用
      CPU使用率峰值（單位：%）	4.2	9.5	10.3	-	-
      內存使用率峰值（單位：%）	22.15	23.55	68.61	-	-
      讀IOPS峰值（單位：次/每秒）	9243	7578	7669	-	-
      復制延遲峰值（單位：秒）	0.8	14.67	211	-	-

聯系我們

若您對DDL操作有任何疑問，可通過釘釘搜索群號入群咨詢。您可以直接@群內專家，并附上您要咨詢的問題；同時群內也有PolarDB MySQL版小助手24*7小時在線回答您的問題。釘釘群號：15375044501。