このトピックでは、PolarDB-X 1.0を使用するときに発生するデータ定義言語 (DDL) 例外を処理する方法について説明します。
DDLの原則の紹介
PolarDB-X 1.0のDDLコマンドは、すべてのテーブルシャーディングに対して対応するDDL操作を実行します。 障害は2つのタイプに分けられます。
- DDLステートメントがデータベースシャーディングで実行されません。 データベースシャーディングでのDDL実行エラーにより、テーブルシャーディングスキーマの一貫性が失われる可能性があります。
データベースシャーディングの実行エラーは、競合やディスク容量不足など、さまざまな理由で報告される場合があります。 たとえば、作成するテーブルが既に存在する場合、または追加する列が既に存在する場合に競合が発生します。
- システムは実行に長時間応答しません。 大きなテーブルでDDL操作を実行すると、データベースシャーディングでの実行時間が長いため、システムがDDLステートメントに長時間応答しないことがあります。
システムが長時間応答しない場合は、通常、データベースシャーディングの実行時間が長いことが原因です。 たとえば、MySQLでのDDLの実行時間は、操作がソーステーブルを直接変更するin-Placeであるか、テーブルデータをコピーするCopy tableであるかによって大きく異なります。 In-Placeはメタデータを変更するだけで済みます。 ただし、Copy Tableはテーブル全体を再構築する必要があり、ログおよびバッファ操作も伴います。 さまざまな操作と2つの要因の関係の詳細については、MySQLの公式ドキュメントの「オンラインDDL操作」をご参照ください。
DDL操作がインプレース操作かテーブルコピー操作かを確認するには、操作の完了後に影響を受ける行
の戻り値を表示します。 次の例を示します。
- 列のデフォルト値を変更します。 この操作は高速で、テーブルデータにはまったく影響しません。
クエリOK、影響を受ける0行 (0.07秒)
- インデックスを追加します。 この操作には時間がかかりますが、
0行の影響
はテーブルデータがコピーされていないことを示します。クエリOK、影響を受ける0行 (21.42秒)
- 列のデータ型を変更します。 この操作には時間がかかり、テーブル内のすべてのデータ行を再構築する必要があります。
クエリOK、影響を受ける1671168行 (1分35.54秒)
- スキーマをコピーして、クローンテーブルを生成します。
- データを挿入します。
- クローンされたテーブルに対してDDL操作を実行します。
- 操作の完了後、
影響を受ける行
の値が0かどうかを確認します。 非ゼロ値は、この操作がテーブル全体を再構築する必要があることを示します。 この場合、ビジネスのオフピーク時にこの操作を実行することを検討する必要があります。
PolarDB-X 1.0 DDL操作は、すべての構造化クエリ言語 (SQL) ステートメントを、並列実行のためにすべてのデータベースシャーディングに配布します。 データベースシャーディングの実行失敗は、他のデータベースシャーディングには影響しません。 さらに、PolarDB-X 1.0では、テーブルシャーディングのスキーマの整合性をチェックするCHECK TABLEコマンドが提供されます。 したがって、失敗したDDL操作を再度実行することができ、実行された操作が成功したデータベースシャーディングで報告されたエラーは、他のデータベースシャーディングでの実行に影響しません。 すべてのテーブルシャーディングが最終的に同じスキーマを持つことを確認するだけで済みます。
DDL障害の処理手順
- CHECK TABLEコマンドを実行して、スキーマを確認します。 返された結果に1行のみが含まれ、ステータスが正常の場合、テーブルのステータスは一貫しています。 この場合、ステップ2に進みます。 それ以外の場合は、ステップ3に進みます。
- SHOW CREATE TABLEコマンドを実行して、スキーマを確認します。 DDL文の実行後に表示されるスキーマが期待どおりである場合、DDL文が実行されます。 それ以外の場合は、ステップ3に進みます。
- SHOW PROCESSLISTコマンドを実行して、実行中のすべてのSQL文のステータスを確認します。 進行中のDDL操作が存在する場合は、これらの操作が完了するまで待ちます。 次に、ステップ1とステップ2を実行して、スキーマが期待どおりかどうかを確認します。 それ以外の場合は、ステップ4に進む。
- PolarDB-X 1.0で再度DDL操作を実行します。
ロック競合
エラーが報告された場合は、ステップ5に進みます。 それ以外の場合は、ステップ3に進みます。 - RELEASE DBLOCKコマンドを実行して、DDL操作ロックを解除します。 次に、ステップ4に進みます。
以下の詳細な操作を実行します。
- スキーマの整合性を確認します。
次の例に示すように、CHECK TABLEコマンドを実行してスキーマを確認します。
チェックテーブル 'xxxx';
説明 Data Management Service (DMS) でCHECK TABLEを実行しても結果が返されない場合は、コマンドラインで再試行してください。返された結果に1行のみが含まれ、表示されたステータスがOKの場合、次の例に示すように、スキーマが一貫していることを示します。
+ ---------------------------- + ------------------------------ + | テーブル | OP | MSG_TYPE | MSG_TEXT | + ---------------------------- + ------------------------------ + | TDDL5_APP.xxxx | チェック | ステータス | OK | + ---------------------------- + ------------------------------ + 1行セット (0.05秒)
- スキーマを確認します。
次の例に示すように、SHOW CREATE TABLEコマンドを実行してスキーマを確認します。
show createテーブル 'xxxx';
スキーマに一貫性があり、エラーがない場合は、DDLステートメントが実行されたと見なすことができます。 返される結果の例を次のコードに示します。
+ --------- + ------------------------------------------------------------------------------------------------------------------ + | テーブル | テーブルの作成 | + --------- + ------------------------------------------------------------------------------------------------------------------ + | xxxx | テーブル 'xxxx' の作成 ( 'id' int(11) NOT NULL DEFAULT '0' 、'NAME' varchar(1024) NOT NULL DEFAULT ''、主要なキー ('id') エンジン=InnoDB DEFAULT CHARSET=utf8 dbpartition by hash('id') tbpartition by hash('id') tbpartition 3 | + --------- + ------------------------------------------------------------------------------------------------------------------ + 1行セット (0.05秒)
- 実行中のSQL文を確認します。
一部のDDL文は低速で実行され、システムはDDL文に長時間応答しません。 この場合、次の例に示すように、SHOW PROCESSLISTコマンドを実行して、実行中のすべてのSQL文のステータスを確認できます。
コマンドがあるショーのプロセスリスト! ='Sleep';
返される結果の例を次のコードに示します。
-------------- ------------ -------------------- ------------------------------------------------------------------------ | ID | ユーザー | DB | コマンド | 時間 | 州 | 情報 | ROWS_SENT | ROWS_EXAMINED | ROWS_READ | -------------- ------------ -------------------- ---------------------------------------------------------------------------------------------------- | 0-0-352724126 | ifisibhk0 | test_123_wvvp_0000 | クエリ | 15 | データの送信 | /* DRDS /42.120.XX.XX/ac47e5a72801000/ */select 't_item'.'detail_url' 、SUM('t_item'.'price') from 't_i | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | | 0-0-352864311 | cowxhthg0 | NULL | Binlog Dump | 13 | マスターはすべてのbinlogをスレーブに送信しました。binlogが更新されるのを待っています | NULL | NULL | NULL | NULL | NULL | | 0-0-402714566 | ifisibhk0 | test_123_wvvp_0005 | クエリ | 14 | 送信データ | /* DRDS /42.120.XX.XX/ac47e5a72801000/ */select 't_item'.'detail_url' 、't_item'.'price' from 't_i | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | | 0-0-402714795 | ifisibhk0 | test_123_wvvp_0005 | 変更 | 114 | 送信データ | /* DRDS /42.120.XX.XX.XX/ac47e5a72801000/ * /Alter TABLE 'Persons 'ADD 'Birthday 'date | NULL | NULL | NULL | NULL | NULL | ...... -------------- ------------ -------------------- ---------------------------------------------------------------------------------------------------- セットの12行 (0.03秒)
TIME列は、コマンドが実行された秒数を表します。 例のIDが
0-0-402714795
であるコマンドのように、コマンドを長時間実行する場合は、KILL '0-0-402714795 'コマンドを実行して、低速コマンドをキャンセルできます。説明 PolarDB-X 1.0では、1つの論理SQLステートメントが複数のデータベースシャーディングコマンドに対応しています。 したがって、1つの論理DDLステートメントを停止するには、複数のコマンドを強制終了する必要があります。 SHOW PROCESSIST の結果集合で, INFO のコマンドは, SHOW PROCESSIST の結果セットにインフォームを使う. - ロッキの誤りを調べる.
PolarDB-X 1.0は DDL 操作を実行する前にデータベースロックを追加する. 操作が完了すると、分散リレーショナルデータベースサービス (DRDS) はロックを解放します。 KILL DDL動作は、ロックが解放されないことを引き起こし得る。 この場合、DDL操作が再度実行されると、次のエラーが報告されます。
デブロクは, 最後の DDLはまだ
この場合、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ステートメントの実行時に発生TDDL-4500 ERR_PARSERなどのエラーコードを処理する方法は?
A: DRDSによって返される一般的なエラーコードとそのソリューションの詳細については、「エラーコード」をご参照ください。