DDL操作ガイド - PolarDB - Alibaba Cloud ドキュメントセンター

このトピックでは、PolarDB-XでのDDLステートメントの実行方法について説明します。

背景情報

次の図は、PolarDB-Xのアーキテクチャを示しています。

PolarDB-XでのDDLステートメントの実行中、ステートメントが正しく実行されるように、ほぼすべてのコンポーネントが関与します。

グローバルメタサービス (GMS) ノードは、テーブル、スキーマ、統計などのメタデータ情報を保持します。
コンピューティングノード (CN) は、分散DDL実行やグローバルインデックスのメンテナンスなどの機能を提供します。
データノード (DN) は、すべてのテーブルとスキーマの物理データを維持し、ALTER TABLEなどのプッシュダウンされたDDLステートメントを実行します。

このトピックの説明を簡単にするために、ユーザーがPolarDB-XでCNに送信するDDLステートメントをユーザーDDLステートメントと呼びます。ユーザーDDL文の実行中にCNによってDNにプッシュダウンされるDDL文は、物理DDL文と呼ばれます。

DDL実行メソッド

PolarDB-Xでは、DDL文は、実行モードによって、物理的に実行されるDDL文と論理的に実行されるDDL文の2つのカテゴリに分類されます。

物理実行

物理的に実行されるDDLステートメントは、DNにプッシュダウンされ、DN上で実行されるものです。 DDL文の物理的な実行中、CNはメタデータの変更のみを維持する。実際のスキーマ変更はDNによって実行されます。そのようなDDLステートメントは、CREATE TABLE、DROP TABLE、CREATE LOCAL INDEX、およびALTER TABLEを含む。

原子性

PolarDB-Xでは、論理テーブルは複数の物理テーブルに対応します。これはシャードとも呼ばれます。これらのシャードは、ほとんどの場合、複数のDNに分散されます。 DDLステートメントが論理テーブル上で物理的に実行される場合、CNはユーザーDDLステートメントを物理DDLステートメントに変換し、それらを対応するDNにプッシュダウンして実行します。各シャードの完了ステータスが記録されます。物理DDLステートメントがすべてのシャードで実行された後、CNは最終的なメタデータ変更を実行します。

物理的に実行されるDDL文は、同時に実行することができる。したがって、CNは、各シャードの実行ステータスを記録するだけでなく、すべてのシャードに対する変更のアトミック性を保証する必要もあります。これにより、すべてのシャードをアトミックに変更できます。詳細については、「DDLアトミック性」をご参照ください。

実行アルゴリズム

DDLステートメントの物理実行中に、テーブルがロックされているかどうか、テーブルを再作成する必要があるかどうか、およびメタデータのみが変更されるかどうかはすべて、物理DDLステートメントを実行するためにDNによって使用される実行アルゴリズムに依存します。テーブルロックは、同時DML操作を許可するかどうかを決定します。テーブルの再作成は、DDL文の実行期間を決定します。メタデータのみの変更により、DDL操作を即座に完了できるかどうかが決まります。

DNが物理DDL文を実行するには、次の3つの実行アルゴリズムを使用できます。

INSTANTアルゴリズム: データディクショナリのメタデータのみが変更されます。履歴データを変更またはコピーする必要はなく、物理テーブルは再作成されません。物理DDLステートメントの実行は数秒で完了できます。
INPLACEアルゴリズム: データをコピーし、物理テーブルを再作成する必要があります。しかし、コピー動作と再作成動作の両方は、ストレージエンジン内で完了する。通常、読み取りと書き込みの同時操作を実行できるため、ビジネスへの影響が最小限に抑えられます。
COPYアルゴリズム: すべてのデータを物理テーブルから新しいテーブルにコピーする必要があります。データがコピーされると、テーブルがロックされ、すべての書き込み操作がブロックされ、ビジネスに大きな影響を与えます。

サポートされる実行アルゴリズムは、DDL文によって異なります。詳細については、「オンラインDDL」をご参照ください。

論理実行

論理的に実行されるDDLステートメントは、CNのオンラインスキーマ変更 (OSC) 機能を使用して実行されるものである。論理実行は一般に、一時テーブルの作成、履歴データのコピー、増分データの同期、メタデータ切り替えの実行などの操作を伴います。実行にはしばしば長い時間がかかります。ただし、プロセス全体を通してテーブルロックは必要ありません。論理的に実行されるDDLステートメントは、CREATE GLOBAL INDEX、DROP GLOBAL INDEX、ONLINE MODIFY COLUMN、ADD PRIMARY KEY、およびパーティション変更関連のDDLステートメントを含む。 RENAME TABLEやRENAME GLOBAL INDEXなどの論理的に実行されたDDLステートメントは、メタデータを直接変更および同期することで完了できます。

論理的に実行されるDDLステートメントには、通常次の特性があります。

変更は、テーブルをロックする必要なしにオンラインで行われます。これにより、ビジネスへの影響が最小限に抑えられます。
通常、データはコピーされ、テーブルは再作成されます。実行には比較的長い時間がかかる。
原子性が保証される。これにより、一部のシャードでは実行は成功しますが、他のシャードでは失敗するという状況を防ぎます。

DOP調整

一般に、履歴データは、論理的に実行されるDDL文に対してコピーされなければならず、時間がかかる。 CNとDNにCPUまたはI/Oのボトルネックがない場合は、履歴データのバックフィルの並列度 (DOP) とレート制限を調整して、DDLステートメントの実行効率を向上させることができます。

たとえば、グローバルセカンダリインデックス (GSI) の作成中に、プライマリテーブルの履歴データをGSIテーブルにバックフィルする必要があります。 CNとDNにCPUまたはI/Oリソースのボトルネックがない場合は、履歴データのバックフィルのDOPとレート制限を調整して、データバックフィルを高速化できます。

-- データバックフィルのグローバルDOPを設定します。 デフォルト値: 32。経験に基づいて調整する必要はありません。
グローバルBACKFILL_PARALLELISM = 32に設定します。-- データを物理シャードにバックフィルするためのDOPを設定します。 デフォルト値: 4。 このようなデータの量が多い場合は、DOPを調整することをお勧めします。
グローバルPHYSICAL_TABLE_BACKFILL_PARALLELISM = 8を設定します。-データバックフィルのレート制限を設定します。 デフォルト値: 150000 単位: row/s。
グローバルGSI_BACKFILL_SPEED_LIMITATION = 250000;

スキーマ、トポロジ、およびデータサイズはテーブルによって異なるため、上記のパラメーターに加えて他のパラメーターを調整することもできます。詳細については、「パラレルDDL」をご参照ください。

DDL文の実行モードの取得

PolarDB-Xでは、EXPLAINステートメントを実行して、DDLステートメントの実行モードを取得できます。出力が元のDDLステートメントの出力と同様の場合、DDLステートメントは物理的に実行されます。 CREATE TABLEに似たステートメントが出力に含まれている場合、DDLステートメントは論理的に実行されます。

例

PolarDB-Xインスタンスで、t1という名前の論理テーブルを作成します。次のサンプルコードは、そのスキーマを示しています。

+ ------- + -------------------------------------------------------------------------- +
| テーブル | テーブルの作成 |
+ ------- + -------------------------------------------------------------------------- +
| t1 | CREATE TABLE 't1' (
        'a' int(11) DEFAULT NULL、
        'b' int (11) DEFAULT NULL
) エンジン=InnoDBデフォルト料金セット=utf8mb4 |
+ ------- + -------------------------------------------------------------------------- +

EXPLAIN文を実行して, 論理表t1にローカルインデックスを追加するDDL文が論理的または物理的に実行されているかどうかを確認します。結果は、DDLステートメントが物理的に実行されたことを示します。

説明

alterテーブルt1 add local index idx(b);
+ ---------------------------------------------------------------------------------- +
| 実行計画 |
+ ---------------------------------------------------------------------------------- +
| ALTER_TABLE( tables="t1", shardCount=16, sql="ALTER TABLE? ADD INDEX idx (b)" ) |
| EXCLUDE_RESOURCE( wumu.t1, wumu.tg17 ) |
| SHARE_RESOURCE( wumu.t1, wumu.tg17 ) |
+ ---------------------------------------------------------------------------------- +

EXPLAIN文を実行して, 論理表t1の分割アルゴリズムをpartition by key(a) に変更するDDL文が論理的または物理的に実行されているかどうかを確認します。結果は、DDLステートメントが論理的に実行されたことを示します。

説明キー (a) でテーブルt1パーティションを変更します。+ ---------------------------------------------------------------------------------- +
| 実行計画 |
+ ---------------------------------------------------------------------------------- +
| CREATE_TABLE( tables="t1_msfg", shardCount=16, sql="CREATE TABLE? (
  'a' int(11) DEFAULT NULL、
  'b' int(11) DEFAULT NULL、
  '_drds_implicit_id_' bigint(20) NOT NULL AUTO_INCREMENT、
  PRIMARY KEY ('_drds_implicit_id_') 、
  INDEX 'auto_shard_key_a '使用するBTREE('a')
) エンジン=InnoDBデフォルトCHARSET = utf8mb4 " ) |
| DROP_TABLE( tables="t1_msfg" 、shardCount=16、sql="DROP TABLE IF EXISTS ?" ) |
| EXCLUDE_RESOURCE( wumu.t1, wumu.t1_msfg, wumu.tg17 ) |
| SHARE_RESOURCE( wumu.t1, wumu.t1_msfg, wumu.tg17 ) |
+ ----------------------------------------------------------------------------------- +

DDLステートメントの非同期実行

PolarDB-Xでは、DDLステートメントはデフォルトで同期実行されます。これはMySQLのそれと一致しています。クライアントが切断された場合、DDLステートメントの同期実行が中断される可能性があります。 DDL文の実行に時間がかかると予想される場合は、DDL文を非同期で実行することを推奨します。

DDLステートメントにヒントを追加することで、DDLステートメントを非同期で実行できます。例：

/* + TDDL:cmd_extra(PURE_ASYNC_DDL_MODE=true)*/ alter table t1 add global index gsi_a(a) partition by key(a);