PolarDB-X 1.0 の DDL 例外の処理 - PolarDB - Alibaba Cloud - PolarDB

このトピックでは、 PolarDB-X 1.0 の使用時に発生するデータ定義言語 (DDL) の例外を処理する方法について説明します。

DDL の原則

PolarDB-X 1.0 では、 1 つの DDL コマンドがすべてのシャード化されたテーブルで対応する操作を実行します。エラーは、次の 2 つのカテゴリに分類できます。

DDL 操作がシャード化されたデータベースで失敗する。いずれかのシャード化されたデータベースで DDL 操作が失敗した場合、シャード化されたテーブルのテーブルスキーマに不整合が生じる可能性があります。
シャード化されたデータベースでの失敗は、テーブル作成時にテーブルがすでに存在する場合、新しい列を追加する際に列がすでに存在する場合、ディスク容量が不足している場合など、さまざまな理由で発生する可能性があります。
実行が無応答になる。サイズの大きいテーブルで DDL 操作を実行すると、シャード化されたデータベースでの実行に時間がかかりすぎた場合に操作が無応答になる可能性があります。
無応答の操作は、通常、シャード化されたデータベースでの実行時間が長いことが原因です。たとえば MySQL では、 DDL 操作に必要な時間は、その操作がインプレース (ソーステーブルを直接変更) かテーブルのコピー (テーブルデータをコピー) かによって異なります。インプレース操作ではメタデータの変更のみが必要です。テーブルのコピー操作では、テーブル全体のデータを再構築する必要があり、ログやバッファの操作も含まれます。さまざまな操作とこれら 2 つの方式の関係については、 MySQL の公式ドキュメント「Online DDL Operations」をご参照ください。

DDL 操作がインプレースかテーブルのコピーかを判断するには、操作完了後に rows affected の戻り値を確認します。以下に例を示します。

列のデフォルト値の変更は非常に高速で、テーブルデータには影響しません。
```
Query OK, 0 rows affected (0.07 sec)
```
インデックスの追加には時間がかかりますが、戻り値が 0 rows affected であることは、テーブルデータがコピーされなかったことを示します。
```
Query OK, 0 rows affected (21.42 sec)
```
列のデータ型の変更には時間がかかり、テーブル内のすべての行を再構築する必要があります。
```
Query OK, 1671168 rows affected (1 min 35.54 sec)
```

したがって、サイズの大きいテーブルで DDL 操作を実行する前に、以下の手順に従って、それが高速な操作か低速な操作かを判断できます。

テーブルスキーマをコピーしてクローンテーブルを作成します。
データをいくつか挿入します。
クローンテーブルに対して対象の DDL 操作を実行します。
操作完了後に rows affected の値が 0 であるかどうかを確認します。 0 以外の値は、操作がテーブル全体を再構築する必要があることを示します。この場合、オフピーク時間に操作を実行することを検討してください。

PolarDB-X 1.0 の DDL 操作は、すべての SQL ステートメントをすべてのシャード化されたデータベースに分散して並列実行します。 1 つのシャード化されたデータベースでの失敗は、他のデータベースには影響しません。さらに、 PolarDB-X 1.0 は、シャード化されたテーブルスキーマの整合性をチェックするための CHECK TABLE コマンドを提供します。したがって、失敗した DDL 操作を再試行できます。すでに成功しているシャード化されたデータベースでは操作は失敗しますが、これは他のデータベースには影響しません。最終的にすべてのシャード化されたテーブルスキーマに一貫性があることだけを確認する必要があります。

DDL 実行エラーの対応手順

CHECK TABLE コマンドを使用してテーブルスキーマを確認します。結果セットに行が 1 つだけで、ステータスが OK の場合は、テーブルスキーマに一貫性があります。この場合、手順 2 に進みます。それ以外の場合は、手順 3 に進みます。
SHOW CREATE TABLE コマンドを使用してテーブルスキーマを確認します。表示されたスキーマが DDL 操作後の想定スキーマと一致する場合、 DDL 操作は成功です。それ以外の場合は、手順 3 に進みます。
SHOW PROCESSLIST コマンドを使用して、現在実行中のすべての SQL ステートメントのステータスを表示します。DDL 操作がまだ実行中の場合は、完了するまで待機します。その後、手順 1 と 2 を実行して、テーブルスキーマが想定どおりであるかを確認します。それ以外の場合は、手順 4 に進みます。
PolarDB-X 1.0Lock conflict で DDL 操作を再試行します。エラーメッセージが返された場合は、手順 5 に進みます。それ以外の場合は、手順 3 に進みます。
RELEASE DBLOCK コマンドを使用して DDL 操作のロックを解放し、手順 4 に進みます。

詳細な手順は次のとおりです。

テーブルスキーマの整合性チェック
CHECK TABLE コマンドを使用してテーブルスキーマを確認します。以下に例を示します。
```
check table `xxxx`;
```
説明 DMS で CHECK TABLE を実行したときに結果が返されない場合は、コマンドラインでコマンドを再試行できます。
結果セットに行が 1 つだけで、ステータスが OK の場合は、テーブルスキーマに一貫性があります。以下に例を示します。
```
+----------------------------+-------+----------+----------+
| TABLE                      | OP    | MSG_TYPE | MSG_TEXT |
+----------------------------+-------+----------+----------+
| TDDL5_APP.xxxx             | check | status   | OK       |
+----------------------------+-------+----------+----------+
1 row in set (0.05 sec)       
```

テーブルスキーマのチェック

SHOW CREATE TABLE コマンドを使用してテーブルスキーマを確認します。以下に例を示します。

mysql> show create table `xxxx`;

テーブルスキーマに一貫性があり、正しい場合、 DDL 操作は成功です。結果セットの例を次に示します。

+---------+------------------------------------------------------------------------------------------------------------------+
| Table   | Create Table                                                                                                     |
+---------+------------------------------------------------------------------------------------------------------------------+
|  xxxx   | CREATE TABLE `xxxx` (
`id` int(11) NOT NULL DEFAULT '0',
`NAME` varchar(1024) NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 dbpartition by hash(`id`) tbpartition by hash(`id`) tbpartitions 3                      |
+---------+------------------------------------------------------------------------------------------------------------------+
1 row in set (0.05 sec)

現在実行中の SQL ステートメントの表示

一部の DDL 操作は実行が遅い場合があります。DDL 操作が長時間無応答になった場合は、 SHOW PROCESSLIST コマンドを実行して、現在実行中のすべての SQL ステートメントのステータスを表示できます。以下に例を示します。

mysql> SHOW PROCESSLIST WHERE COMMAND != 'Sleep';

結果セットの例を次に示します。

+---------------+-----------+--------------------+-------------+---------+-----------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------+---------------+-----------+
| ID            | USER      | DB                 | COMMAND     | TIME    | STATE                                                                 | INFO                                                                                                 | ROWS_SENT | ROWS_EXAMINED | ROWS_READ |
+---------------+-----------+--------------------+-------------+---------+-----------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------+---------------+-----------+
| 0-0-352724126 | ifisibhk0 | test_123_wvvp_0000 | Query       |      15 | Sending data                                                          | /*DRDS /42.120.74.88/ac47e5a72801000/ */select `t_item`.`detail_url`,SUM(`t_item`.`price`) from `t_i |      NULL |          NULL |      NULL |
| 0-0-352864311 | cowxhthg0 | NULL               | Binlog Dump |      13 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL                                                                                                 |      NULL |          NULL |      NULL |
| 0-0-402714566 | ifisibhk0 | test_123_wvvp_0005 | Query       |      14 | Sending data                                                          | /*DRDS /42.120.74.88/ac47e5a72801000/ */select `t_item`.`detail_url`,`t_item`.`price` from `t_i      |      NULL |          NULL |      NULL |
| 0-0-402714795 | ifisibhk0 | test_123_wvvp_0005 | Alter       |     114 | Sending data                                                          | /*DRDS /42.120.74.88/ac47e5a72801000/ */ALTER TABLE `Persons` ADD `Birthday` date                    |      NULL |          NULL |      NULL |
......
+---------------+-----------+--------------------+-------------+---------+-----------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------+---------------+-----------+
12 rows in set (0.03 sec)

TIME 列は、命令が実行されている秒数を示します。例にある ID 0-0-402714795 のように長時間実行されている命令を見つけた場合は、[KILL '0-0-402714795'] コマンドを実行してキャンセルできます。

説明 PolarDB-X 1.0 では、 1 つの論理 SQL ステートメントがシャード化されたデータベースに対する複数のコマンドに対応しています。したがって、 1 つの論理 DDL 操作を停止するには、複数のコマンドを強制終了する必要がある場合があります。 SHOW PROCESSLIST の結果セットの INFO 列から、コマンドが属する論理 SQL ステートメントを特定できます。

Lock conflict エラー
PolarDB-X 1.0 が DDL 操作を実行すると、データベースレベルのロックを取得し、操作完了後にロックが解放されます。DDL 操作を強制終了した場合、ロックが解放されないことがあります。その後に別の DDL 操作を実行すると、次のエラーが返されます。
```
Lock conflict , maybe last DDL is still running
```
この場合、 RELEASE DBLOCK コマンドを実行してロックを解放できます。コマンドがキャンセルされ、ロックが解放された後、オフピーク時間またはメンテナンス時間に DDL 操作を再試行してください。

よくある質問

Q：変更後のテーブルスキーマが DMS や他のクライアントに表示されないのはなぜですか。
A： COLUMNS や TABLES などのシステムテーブルからテーブルスキーマを取得するクライアントとの互換性を保つために、 PolarDB-X 1.0 はシャード 0 の RDS インスタンスにシャドウデータベースを作成します。シャドウデータベースは PolarDB-X 1.0 の論理データベースと同じ名前を持ち、論理データベースのすべてのスキーマ情報を格納します。
DMS は、シャドウデータベースのシステムテーブルから PolarDB-X 1.0 のテーブルスキーマを取得します。DDL 例外を処理する際に、データベースとテーブルのスキーマが変更されても、シャドウデータベース内のスキーマは更新されない場合があります。この場合、シャドウデータベースに接続し、テーブルに対して再度 DDL 操作を実行できます。
説明 CHECK TABLE は、シャドウデータベースのスキーマが PolarDB-X 1.0 の論理データベースのスキーマと一致しているかどうかはチェックしません。
Q： DDL ステートメントの実行時にエラーコードが返された場合はどうすればよいですか。
A： PolarDB-X 1.0 によって返される一般的なエラーコードとその解決策については、「エラーコード」をご参照ください。