DDL常見問題 - PolarDB

本文將介紹PolarDB-X DDL常見問題。

PolarDB-X 2.0資料庫數量超限 32個，需要增加怎麼辦？

您可以使用高許可權賬戶串連資料庫執行SET GLOBAL MAX_LOGICAL_DB_COUNT=64; 即可。

PolarDB-X 2.0異常DDL如何確認？

具體可參考一下語句進行修改：

SHOW FULL DDL; 
SHOW FULL physical_processlist WHERE info !='';

PolarDB-X批量插入操作，一次能插入的最大行記錄？

您可以根據以下內容評估：

儲存容量計算原則：
- InnoDB引擎下，INT(4 Byte)、BIGINT(8 Byte)、DECIMAL(4 Byte)、DATETIME(8 Byte).
- VARCHAR(N)：UTF8字元集按3位元組，UTF8MB4按4位元組。
- 特殊欄位需單獨評估：TEXT/BLOB/LONGTEXT等大物件類型。例如：某些字元類型設計也不合理，例如Group_ID設定為VRACHAR（1024），其實該欄位只儲存了一個數字0，按照單行最大儲存進行預估。
  樣本：假設某表單行各欄位加總後，最大佔用儲存空間為：8+8+8+8+8+8+255+255+255+1024+4+64+8=1913 位元組。根據PolarDB-X CN計算層的16M批量插入方式，建議如下：
  - 按照1M計算，(1024*1024)/1913 ≈ 548。因此建議單批插入條數控制在500條以內，以避免超出限制。
  - 那麼16M下，500*16=8000條，當max_allowed_packet=16M時，單次批量插入8000條資料是相對合理且安全的範圍。
  綜上，實際批量插入條數應結合單行實際位元組佔用和max_allowed_packet參數合理預估，在保證效能和安全的前提下，選擇合適的批量插入條數。
其他影響插入效能因素：
- InnoDB緩衝池（buffer_pool）大小。
- 磁碟IOPS能力、網路頻寬（分散式資料庫情境）。
- Redo日誌緩衝區（innodb_log_buffer_size）刷盤機制。
參數設定建議：
- 建議您調整max_allowed_packet參數到最大值。
- 建議將innodb_log_buffer_size調整到 32M~128M 之間，並通過多次測試找出最佳的插入回應時間。合理設定該參數，可以避免InnoDB在事務提交前頻繁進行日誌刷盤操作，從而提升交易處理效能。

PolarDB-X執行DDL報錯：[ERR_REPARTITION_TABLE_WITH_GSI] can not alter table repartition when gsi table is not public?

問題原因：

GSI索引的狀態不正確，您可以使用SHOW GLOBAL INDEX FROM xxx;來進一步確認索引狀態。只有PUBLIC、ABSENT這兩個狀態才支援對目標表操作DDL，其他狀態表示GSI索引還在建立中，不能進行其他DDL操作。

解決方案：

先執行SHOW DDL;看下是否有殘留的DDL操作阻塞。
如有殘留的DDL操作，您可以先等待DDL操作結束。如果SHOW GLOBAL INDEX狀態並非PUBLIC或ABSENT，可以考慮CANCEL DDL JOB_ID;取消GSI的建立。然後重新執行需要的DDL操作。

PolarDB-X 2.0中執行DDL出現報錯：Table`find incorrect column xxx`/`Out of range value for column xxx`/`Data too Long for column xxx`？

若一個欄位的類型為DECIMAL(10, 0) ，則其可以儲存最大9位的整數（小數部分為0）。執行DDL後，欄位類型為DECIMAL(5, 4)，則可以儲存最多1位整數和4位小數。此時，如果原DECIMAL(10, 0)列中有任何大於等於10的整數，執行DDL就會報錯。

PolarDB-X中執行ALTER TABLE MODIFY/CHANGE COLUMN語句出現部分分區更新失敗的情況，應如何處理？

在PolarDB-X中分為2種方式處理：正向執行和反向執行。

樣本

建立以下表結構，並插入一些記錄：

CREATE TABLE `t1` (
 `id` bigint(20) NOT NULL AUTO_INCREMENT,
 `c2` varchar(16) DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4
PARTITION BY KEY(`id`)
PARTITIONS 32;

INSERT INTO t1 VALUES (1, "1");
INSERT INTO t1 VALUES (2, "abc");

此時在嚴格的SQL_MODE模式下，對t1表做⼀個MODIFY COLUMN的DDL，將c2列由varchar變更成數字類型：
```
SET sql_mode="strict_trans_tables"; 
ALTER TABLE t1 MODIFY COLUMN c2 INT;
```
由於某個分⽚包含"abc"這樣的⾮法值，所以在嚴格的SQL_MODE模式下，這個分⽚會變更失敗。此時DDL報錯：
```
...Not all physical DDLs have been executed successfully: 32 expected, 31 done, 1 failed...Incorrect integer value...
```

以上樣本情境，PolarDB-X是無法自動處理的，處理方式參考如下：

正向執行：修複執⾏失敗的分⽚的資料，並繼續此DDL，則稱為正向執⾏。
反向執行：若有些業務⽆法修改已有的⾮法資料，需要將已經執⾏成功的分⽚改回去，則稱為反向執⾏。

正向執行

修正⾮法的資料：根據DDL修正表中的非法值，例如：
```
UPDATE t1 SET c2=0 WHERE id=2;
```

執行SHOW DDL擷取執⾏失敗的DDL的JOB_ID：

--------------------+----------------+---------------+----------+--------------+-----------+--------------------------+--------------------------+-----------------+----------------------------+------------------------------+----------------------+-----------------------+---------------+
| JOB_ID            |OBJECT_SCHEMA   |  OBJECT_NAME  | ENGINE   |  DDL_TYPE    |  STATE    |  TOTAL_BACKFILL_PROGRESS | CURRENT_PHY_DDL_PROGRESS |   PROGRESS      |    START_TIME              |     END_TIME                 |     ELAPSED_TIME(MS）|      PHY_PROCESS      |    CANCELABLE |
--------------------+----------------+---------------+----------+--------------+-----------+--------------------------+--------------------------+-----------------+----------------------------+------------------------------+----------------------+-----------------------+--------------+
| 166113736846543257|    testdb      |      t1       |  DAG     |  ALTER_TABLE |  PAUSED   |  --                      |      96%                 |        33%      |    2023-11-14 14:01:11:585 |     2023-11-14 14:01:11:910  |        3325          |                       |     false    |
--------------------+----------------+---------------+----------+--------------+-----------+--------------------------+--------------------------+-----------------+----------------------------+------------------------------+----------------------+-----------------------+--------------+

繼續執⾏此DDL：
```
CONTINUE DDL 1661145277907759104;
```

反向執行

說明

反向執行僅適用於ALTER TABLE MODIFY COLUMN出現分區級部分成功/部分失敗的異常情境，使用限制如下：

在PolarDB-X執行個體的5.4.18版本中提供此情境下的⾃動復原能⼒，推薦您升級至該版本及以上版本。
僅適⽤於PolarDB-X 2.0執行個體。
ALTER語句中僅包含變更列類型的操作，不包括改名等操作。
必須是部分分⽚成功，部分分⽚失敗，不包括全部成功或者全部失敗的情境。也即報錯中需要有類似資訊32 expected, 31 done, 1 failed，failed數需要⼤於0，並且⼩於expected數。
執⾏演算法沒有指定使⽤OMC（DDL語句中顯式設定了ALGORITHM=OMC才會使⽤OMC，沒有指定則沒有使⽤）。

執行SHOW DDL擷取執⾏失敗的DDL的JOB_ID：

--------------------+----------------+---------------+----------+--------------+-----------+--------------------------+--------------------------+-----------------+----------------------------+------------------------------+----------------------+-----------------------+---------------+
| JOB_ID            |OBJECT_SCHEMA   |  OBJECT_NAME  | ENGINE   |  DDL_TYPE    |  STATE    |  TOTAL_BACKFILL_PROGRESS | CURRENT_PHY_DDL_PROGRESS |   PROGRESS      |    START_TIME              |     END_TIME                 |     ELAPSED_TIME(MS）|      PHY_PROCESS      |    CANCELABLE |
--------------------+----------------+---------------+----------+--------------+-----------+--------------------------+--------------------------+-----------------+----------------------------+------------------------------+----------------------+-----------------------+--------------+
| 166113736846543257|    testdb      |      t1       |  DAG     |  ALTER_TABLE |  PAUSED   |  --                      |      96%                 |        33%      |    2023-11-14 14:01:11:585 |     2023-11-14 14:01:11:910  |        3325          |                       |     false    |
--------------------+----------------+---------------+----------+--------------+-----------+--------------------------+--------------------------+-----------------+----------------------------+------------------------------+----------------------+-----------------------+--------------+

取消當前DDL任務：

DELETE FROM metadb.ddl_engine WHERE job_id=166113736846543257;
 
DELETE FROM metadb.ddl_engine_task WHERE job_id=166113736846543257;

說明

注意，此步驟需要⾼許可權帳號執⾏。

取消後，執行SHOW DDL查看已⽆此任務。

請注意，此時該表處於不⼀致狀態，務必及時處理，CHECK TABLE可以觀察到：

CHECK TABLE t1; 
+----------------------+-------+----------+--------------------------------+----------------------------------------------------------------+ 
| TABLE                | OP    | MSG_TYPE | MSG_TEXT                                                                                        | 
+----------------------+-------+----------+-------------------------------- ----------------------------------------------------------------+ 
|testdb.t1:Topology    | check | Error    | Table 'testdb_P00001_GROUP.t1 _EZ5p_00010' find incorrect columns 'c2', please recreate table   |                                           | 
|testdb.t1:Columns     | check | Error    | Table 'testdb_P00000_GROUP.t1 _EZ5p_00000' find incorrect columns 'c2', please recreate table   | 
+----------------------+-------+----------+-------------------------------- ----------------------------------------------------------------+ 
2 rows in set (0.03 sec)

執⾏反向ALTER TABLE語句：
```
ALTER TABLE t1 MODIFY COLUMN c2 varchar(16);
```
說明
此時也可以將列修改為其他類型，未必是原始類型，例如，若將欄位從varchar(16)縮減為varchar(12)失敗，可直接嘗試調整為varchar(14)，無需先恢複原始長度。

再次進行CHECK TABLE。此時，表已處於⼀致的狀態：

CHECK TABLE t1; 
+--------------------+-------+----------+------------+ 
| TABLE              | OP    | MSG_TYPE | MSG_TEXT   | 
+----------------------+-------+----------+----------+ 
| testdb.t1:Topology | CHECK | status   | OK         | 
| testdb.t1:Columns  | CHECK | status   | OK         | 
+--------------------+-------+----------+------------+ 
2 rows in set (0.02 sec)