PolarDB:オンラインパーティションのメンテナンス

オンラインパーティションメンテナンス機能は、データアクセスに対するパーティションメンテナンスの影響を回避し、軽減します。 パーティションのメンテナンスはいつでも実行できます。 次の例は、機能の使用方法を示しています。

# クライアント1のtrテーブルの構造を表示します。
SHOW CREATE TABLE tr\G
*************************** 1。 行 ***************************    
       テーブル: tr
テーブルの作成: テーブル 'tr' を作成 (                                  
  'id' int(11) DEFAULT NULL、                                       
  'name' varchar (50) DEFAULT NULL、                                 
  「購入済み」日付DEFAULT NULL
) エンジン=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
/*!50100パーティーBY RANGE (year('purchased '))
(PARTITION p0は (1990) エンジンより少ない値=InnoDB、             
 PARTITION p1は (1995) エンジン=InnoDBより少ない値、             
 PARTITION p2は、(2000) エンジン=InnoDBよりも少ない値であり、             
 PARTITION p3は (2005) エンジンよりも少ない値=InnoDB、            
 PARTITION p4は (2010) エンジン=InnoDBより少ない値を示し、            
 パートp5は (2015) エンジン=InnoDBより少ない値 * /
セットの1列 (0.00秒)

# クライアント1でトランザクションを有効にします。
開始;
クエリOK、影響を受ける0行 (0.01秒)                               
                                                                  
SELECT * 購入済みのtrから>= '2010-01-01 ';
------ ---------------- -------------
| id | 名前 | 購入 |
------ ---------------- -------------
| 5 | エアロバイク | 2014-05-09 |
| 7 | エスプレッソメーカー | 2011-11-22 |
------ ---------------- -------------
セットの2列 (0.01秒)

# クライアント2に新しいパーティションを作成します。
ALTER TABLE tr ADD PARTITION (PARTITION p6の値は (2020) 未満);
INSERT INTO tr VALUES (11、「ホープ」、「2017-11-04」) 、(12、「カーメン」、「2018-06-08」);

# 同じトランザクションで、クライアント1は新しいパーティションのデータにアクセスできます。
SELECT * 購入済みのtrから>= '2010-01-01 ';
------ ---------------- -------------
| id | 名前 | 購入 |
------ ---------------- -------------
| 5 | エアロバイク | 2014-05-09 |
| 7 | エスプレッソメーカー | 2011-11-22 |
| 11 | 希望 | 2017-11-04 |
| 12 | カルメン | 2018-06-08 |
------ ---------------- -------------
セットの4列 (0.00秒)

# クライアント2の古いパーティションを削除します。
ALTER TABLE tr DROP PARTITION p0;

# クライアント1のテーブル定義を表示します。 この結果は、新しいパーティションp6が存在し、古いパーティションp0が削除されたことを示す。
SHOW CREATE TABLE tr\G
*************************** 1。 行 ***************************     
       テーブル: tr
テーブルの作成: テーブル 'tr' を作成 (                                 
  'id' int(11) DEFAULT NULL、                                       
  'name' varchar (50) DEFAULT NULL、                                 
  「購入済み」日付DEFAULT NULL
) エンジン=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
/*!50100パーティーBY RANGE (year('purchased '))
(PARTITION p1は (1995) エンジンよりも少ない値=InnoDB、             
 PARTITION p2は、(2000) エンジン=InnoDBよりも少ない値であり、             
 PARTITION p3は (2005) エンジンよりも少ない値=InnoDB、             
 PARTITION p4は (2010) エンジン=InnoDBより少ない値を示し、            
 PARTITION p5は (2015) エンジン=InnoDBより少ない値を示し、             
 PARTITION p6は (2020) エンジン=InnoDBより少ない値 * /
セットの1列 (0.00秒)

# クライアント1でトランザクションをコミットします。
コミット; 

次のセクションでは、DML操作とDDL操作の相互作用の最も一般的なシナリオについて説明します。実行時間の長いトランザクションによるブロックされたDDL操作と時間のかかるDDL操作です。 オンラインパーティションのメンテナンス機能が有効と無効になっている場合のパフォーマンスが比較されます。

• シナリオ1: 長期トランザクションによるブロックされたDDL操作

  このシナリオでは、DDL操作がパーティションテーブルで実行されます。 実行時間の長いトランザクションがまだコミットされていないため、DDL操作はブロックされます。 ブロックされたDDL操作はすべての新しいDML操作をブロックし、データベーストラフィックをゼロに落とします。

  上の図は、オンラインパーティションのメンテナンス機能が無効になってDDL操作が実行されると、テーブル内のsysbenchのトラフィックがすぐにゼロになり、データベースが完全に使用できなくなることを示しています。 データベースは、DDL操作をキャンセルするか、すべての長時間実行トランザクションをコミットした後にのみ再開されます。 オンラインパーティションのメンテナンス機能を有効にすると、次の効果が見られます。

  • 通常の状況では、sysbenchのスループットは、オンラインパーティションのメンテナンス機能が無効になっている場合とまったく同じです。 これは、オンラインパーティションのメンテナンス機能が有効になっている場合、パフォーマンスに影響がないことを示します。

  • コミットされていない長いトランザクションはDDL操作をブロックしません。 データベースのDMLトラフィックは安定しており、ほとんど影響を受けません。

• シナリオ2: 時間のかかるDDL操作

  このシナリオでは、DDL操作は他のSQL文によってブロックされませんが、DMLスループットは時間のかかるDDL操作の影響を受けます。

  上の図では、オンラインパーティションのメンテナンス機能が無効になっていると、時間のかかるDDL操作により、DMLのスループットが大幅に変動します。 オンラインパーティションのメンテナンス機能を有効にすると、時間のかかるDDL操作はDMLのスループットにほとんど影響を与えません。

オンラインパーティションのメンテナンス機能は、パーティションレベルのMDLを使用して、DMLおよびDDL操作中のロックの粒度を減らし、同時実行性を向上させます。 DDL操作が実行されると、performance_schema.metadata_locksテーブルからパーティションレベルでMDLステータスを表示できます。 次のサンプルコードに例を示します。

# クライアント1のtrテーブルの構造を表示します。
SHOW CREATE TABLE tr\G
*************************** 1。 行 ***************************    
       テーブル: tr
テーブルの作成: テーブル 'tr' を作成 (                                  
  'id' int(11) DEFAULT NULL、                                       
  'name' varchar (50) DEFAULT NULL、                                 
  「購入済み」日付DEFAULT NULL
) エンジン=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
/*!50100パーティーBY RANGE (year('purchased '))
(PARTITION p0は (1990) エンジンより少ない値=InnoDB、             
 PARTITION p1は (1995) エンジン=InnoDBより少ない値、             
 PARTITION p2は、(2000) エンジン=InnoDBよりも少ない値であり、             
 PARTITION p3は (2005) エンジンよりも少ない値=InnoDB、            
 PARTITION p4は (2010) エンジン=InnoDBより少ない値を示し、            
 パートp5は (2015) エンジン=InnoDBより少ない値 * /
セットの1列 (0.00秒)

# クライアント1でトランザクションを有効にします。
開始;
クエリOK、影響を受ける0行 (0.01秒)                               
                                                                  
SELECT * 購入済みのtrから>= '2010-01-01 ';
------ ---------------- -------------
| id | 名前 | 購入 |
------ ---------------- -------------
| 5 | エアロバイク | 2014-05-09 |
| 7 | エスプレッソメーカー | 2011-11-22 |
------ ---------------- -------------
セットの2列 (0.01秒)

# クライアント1でMDLステータスを表示します。
SELECT * FROM performance_schema.metadata_locks;
------------ -------------------- ---------------- ------------ ----------------------- --------------------- -------------------------------------------------- ------------------- ----------------- ----------------- + ----------------
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | COLUMN_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | SOURCE | OWNER_THREAD_ID | OWNER_EVENT_ID |
------------ -------------------- ---------------- ------------ ----------------------- --------------------- -------------------------------------------------- ------------------- ----------------- ----------------- + ----------------
| TABLE | test | tr | NULL | 140734887898944 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6759 | 67 | 17 |
| PARTITION | test | tr | p5 | 140734887896704 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6502 | 67 | 17 |
| TABLE | performance_schema | metadata_locks | NULL | 140734879511488 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6759 | 68 | 4 |
| スキーマ | performance_schema | NULL | NULL | 140734879511648 | INTENTION_EXCLUSIVE | トランザクション | GRANTED | dd_schema.cc:108 | 68 | 4 |
------------ -------------------- ---------------- ------------ ----------------------- --------------------- -------------------------------------------------- ------------------- ----------------- ----------------- + ----------------
セットの4列 (0.02秒)

# クライアント1での結果は、trテーブルレベルでのSHARED_READロックが取得され、p5パーティションレベルでのSHARED_READロックがプルーニング後にアクセスされることを示しています。 次に、クライアント2のp5パーティションを削除します。
ALTER TABLE tr DROP PARTITION p5;

# p5パーティションがクライアント1によってアクセスされているため、前述の削除操作は待機状態になります。 次のステートメントを実行して、スレッドがパーティションレベルのMDLを待機しているかどうかを確認できます。 
ショーのPROCESSLIST;
---- ----------------- -------- --------------------------------------------------------------------------------- ---------------------------------- +
| Id | ユーザー | ホスト | db | コマンド | 時間 | 状態 | 情報 |
---- ----------------- -------- --------------------------------------------------------------------------------- ---------------------------------- +
| 4 | event_scheduler | localhost | NULL | デーモン | 1550 | 空のキューで待機中 | NULL |
| 8 | ルート | localhost | テスト | スリープ | 426 | | NULL |
| 9 | root | localhost | NULL | クエリ | 0 | 開始 | SHOW PROCESSLIST |
| 10 | root | localhost | test | クエリ | 10 | パーティションメタデータロック待ち | ALTER TABLE tr DROP partition p5 |
---- ----------------- -------- --------------------------------------------------------------------------------- ---------------------------------- +
セットの4列 (0.00秒)

# トランザクションがクライアント1でコミットされた後、p5パーティションはクライアント2から削除されます。 

STATUSパラメーターOnline_alternated_partitionを使用して、オンラインパーティションのメンテナンスタスクの数を表示できます。 例：

「オンライン_altered_partition」のようなステータスを表示します。+ -------------------------- + -------
| Variable_name | 値 |
+ -------------------------- + -------
| Online_altered_partition | 2565 |
+ -------------------------- + -------
1行セット (0.00秒)