PolarDBは、非ブロッキングDDLステートメントをサポートしており、DDLステートメントの実行時にロック待機が長引くことによる輻輳を防ぐことができます。 このトピックでは、非ブロッキングDDLステートメントについて説明します。
背景情報
ブロッキングDDLステートメントが送信され、その影響を受けるテーブルにコミットされていないトランザクションまたはクエリがある場合、DDLステートメントはMDL-Xロックを待機し続けます。 DDLステートメントが待機している間、同じテーブル内のデータを操作するトランザクションが送信される可能性があります。 ただし、MDL-Xロックの優先度が最も高いため、新しいトランザクションはこのブロッキングDDLステートメントが完了するまで待機する必要があります。 その結果、接続が輻輳し、業務システム全体に障害が発生する可能性があります。 ただし、このDDLステートメントが非ブロッキングDDLステートメントである場合、ステートメントがMDL-Xロックを待機している間、送信された新しいトランザクションを実行できます。
前提条件
- リビジョンバージョンが8.0.1.1.29以降のPolarDB for MySQL 8.0.1のクラスター。
- リビジョンバージョンが8.0.2.2.12以降のPolarDB for MySQL 8.0.2のクラスター。
注意事項
非ブロッキングDDLステートメントの優先度は低く、MDLロックがないために失敗する可能性が高くなります。
制限事項
- リビジョンバージョンが8.0.1.1.29以降のPolarDB for MySQL 8.0.1のクラスター、またはPolarDB for MySQL 8.0.2.2.12のクラスター:
- 非ブロッキングDDL機能をサポートするのは、ALTER TABLE文のみです。 この機能は、次のステートメントに最適です。
ALTER TABLE table_name ADD INDEX index_name ( 'column1', 'column2', 'column3')。 - InnoDBエンジンで作成されたテーブルを最適化するには、
OPTIMIZE TABLE TABLE_nameステートメントではなく、ALTER table table_name engine=innodbステートメントを実行する必要があります。
- 非ブロッキングDDL機能をサポートするのは、ALTER TABLE文のみです。 この機能は、次のステートメントに最適です。
- リビジョンバージョンが8.0.2.2.13以降のPolarDB for MySQL 8.0.2クラスター。
ALTER TABLE、OPTIMIZE TABLE、およびTRUNCATE TABLEステートメントは、非ブロッキングDDL機能をサポートしています。
非ブロックDDLステートメントの使用
| パラメーター | レベル | 説明 |
| loose_polar_nonblock_ddl_モード | セッション | 非ブロッキングDDL機能を有効にするかどうかを指定します。 デフォルト値: OFF。 有効な値：
|
| loose_polar_nonblock_ddl_retry_times | セッション | DDLステートメントの取得MDL-Xロックがタイムアウトした後に許可される再試行の最大数。 有効な値: 0 ~ 31536000 デフォルト値：0 デフォルト値は、lock_wait_timeoutパラメーターの値に基づいて計算されます。 説明 このパラメーターの値を4194304に設定することを推奨します。 |
| loose_polar_nonblock_ddl_retry_interval | セッション | DDLステートメントがMDL-Xロックの取得を再試行する間隔。 有効な値: 1 ~ 31536000 単位は秒です。 デフォルト値: 6。 |
| loose_polar_nonblock_ddl_lock_wait_timeout | セッション | DDLステートメントがMDL-Xロックを取得しようとするタイムアウト期間。 有効な値: 1 ~ 31536000 単位は秒です。 デフォルト値は 1 です。 |
性能テスト
このセクションでは、ブロッキングDDLステートメント、非ブロッキングステートメント、およびgh-ostを使用してスキーマ変更を実行するパフォーマンスを比較します。
テストツール
SysBenchは、コア指標に基づいて負荷の高いデータベースシステムのパフォーマンスを評価するために使用できる、モジュール式、クロスプラットフォーム、およびマルチスレッドのベンチマークツールです。 SysBenchを使用すると、データベースをインストールしなくても、複雑なベンチマーク設定なしでデータベースのパフォーマンスをすばやくテストできます。 SysBenchの使用方法については、「OLTPパフォーマンステスト」をご参照ください。
テスト環境
8 CPUコアと64 GBメモリを備えたPolarDB for MySQL 8.0クラスター。 クラスターはcluster Editionを実行します。
- SysBenchを使用して
sbtest1という名前のテストテーブルを作成し、テーブルに1百万行のデータを挿入します。. /oltp_read_write.lua-mysql-host="Cluster endpoint"-mysql-port="Port number"-mysql-user="Username"-mysql-password="Password"-mysql-db="sbtest"-tables=1-table-size=1000000-report-interval=99スレッド=8-time 6000 oltp_read_write.luaスクリプトを使用して、ユーザービジネスをシミュレートします。. /oltp_read_write.lua-mysql-host="Cluster endpoint"-mysql-port="Port number"-mysql-user="Username"-mysql-password="Password"-mysql-db="sbtest"-tables=1-table-size=1000000-report-interval=99スレッド=8-time実行6000sbtest1テーブルでトランザクションを開始しますが、トランザクションをコミットしないでください。これにより、トランザクションはテーブルに対するMDLロックを保持します。/* セッション1 * / 始める; * をsbtest1から選択します。- 別のセッションで、
sbtest1テーブルに列を追加し、TPSの変更を監視します。/* セッション2 * / テーブルsbtest1を追加列d int; - gh-ostツールを使用して列を追加し、TPSの変化を監視します。 バイナリログはパフォーマンスモニタリングに使用されます。 詳細については、「バイナリログの有効化」をご参照ください。
. /gh-ost -- assume-rbr -- user="Username"-password="Password"-host="Cluster endpoint"-port="Port number"-database="sbtest"-table="sbtest1"-alter="ADD COLUMN d INT"-allow-on-master-aliyun-rds-最初は古いテーブルをドロップ-最初はゴースト-テーブル -- 実行;
- 非ブロッキングDDLステートメントが無効になると、TPSはゼロに減少し、長期間ゼロのままになります。 ビジネスは深刻な影響を受けています。
- 非ブロッキングDDLステートメントが有効になっている場合、TPSは定期的に減少しますが、ゼロになることはありません。 ロック待機はビジネスにわずかな影響しか与えず、システムの安定性が確保されます。
- テーブルスキーマを修正するためにgh − ostが使用される場合、TPSは周期的にゼロに減少する。 この場合、ビジネスは深刻な影響を受けます。これは、カットオーバーステップでの一時的なテーブルロックが原因です。
非ブロッキングDDL文とgh-ostツールのパフォーマンス比較
- テーブルにワークロードがない場合、非ブロックDDLステートメントはgh-ostツールよりも高速です。
- SysBenchのoltp_read_writeスクリプトを使用してビジネスワークロードをシミュレートする場合でも、非ブロックDDLステートメントはgh-ostツールよりも高速です。
結論
非ブロックDDLステートメントは、新しいトランザクションをブロックせず、ゼロTPSを回避します。これにより、システムの安定性が最大化され、DDLステートメントの効率が向上します。