ApsaraDB RDS for PostgreSQL の拡張機能 rds_online_migrate は、オンラインパーティショニング機能を提供します。この機能を使用すると、標準テーブルをパーティションテーブルに変換できます。
背景情報
ビジネスの成長に伴い、データ量は増加します。特定のシナリオでは、標準テーブルをパーティションテーブルに変換する必要がある場合があります。しかし、ネイティブの PostgreSQL はオンラインでの変換機能を提供していません。運用保守 (O&M) を簡素化し、パーティショニングがビジネスに与える影響を軽減するために、ApsaraDB RDS for PostgreSQL はオンラインパーティショニング機能を提供します。
適用範囲
ご利用の ApsaraDB RDS for PostgreSQL インスタンスは、次の要件を満たす必要があります：
メジャーバージョン：13 以降。
マイナーエンジンバージョン：20251130 以降。
注意事項
オンラインパーティショニング操作を実行する前に、データセキュリティを確保し、操作を成功させるために、以下の情報をご確認ください。
事前準備
バックアップとテスト：操作を実行する前に、有効な完全バックアップがあることを確認してください。また、非本番環境で十分なテストと検証を行うことを推奨します。
ストレージ容量の計画：オンラインパーティショニングのプロセス中に、システムはデータ移行のために新しいテーブルを作成します。そのため、少なくともソーステーブルとそのすべてのインデックスの合計サイズの 2 倍のストレージ容量を確保する必要があります。
データベースパラメーターの設定：この機能は論理デコーディングに依存します。
wal_levelパラメーターをlogicalに設定する必要があります。さらに、複数のパーティショニングタスクを並行して実行するには、max_worker_processesパラメーターの値を増やす必要がある場合があります。
テーブルスキーマと権限要件
プライマリキーまたは一意の ID：この機能は PostgreSQL のネイティブな論理レプリケーションを使用するため、ソーステーブルには
PRIMARY KEYが設定されているか、REPLICA IDENTITYが設定されている必要があります。ユーザー権限：操作を実行するユーザーアカウントには、
publication、subscription、およびreplication slotを作成する権限が必要です。また、アカウントにはソーステーブルと移行先テーブルに対してRENAME操作を実行する権限も必要です。権限の一貫性：業務継続性を確保するために、移行前にビジネスアカウントがソーステーブルに対して持っているのと同じ権限を、移行先のパーティションテーブルにも付与してください。
例外処理とリスク
非アトミック操作：この機能はスクリプト化されたプロセスであり、原子性はありません。プロセスが例外によって中断された場合、内部オブジェクトが残存する可能性があります。
手動クリーンアップ：例外が発生した場合、残存する
rds_online_migrate.internal_mapテーブルのレコード、publication、subscription、およびreplication slotオブジェクトを手動でクリーンアップする必要がある場合があります。エラーログを参照し、以下のコマンドを使用してクリーンアップを実行してください：-- メタデータレコードのクリーンアップ DELETE FROM rds_online_migrate.internal_map WHERE src_relname = 'source_table' AND dst_relname = 'destination_table'; -- 残存する publication の削除 DROP PUBLICATION publication_name; -- 残存する subscription の削除 DROP SUBSCRIPTION subscription_name; -- 残存するレプリケーションスロットの削除 SELECT pg_drop_replication_slot('slot_name');
RENAME 操作の潜在的な影響
関連オブジェクトの再構築：
RENAME操作が完了した後、元のテーブルに依存するビュー、トリガー、および外部キー制約を手動で再構築する必要があります。論理レプリケーションへの影響：ソーステーブルが別の論理レプリケーションタスクの一部である場合、
RENAME操作によってそのレプリケーションタスクが中断される可能性があります。操作が完了した後、新しいテーブル (元の移行先テーブル) を対応するpublicationに再度追加してください。
拡張シナリオ
この機能は、既存のパーティションテーブルのオンラインでの再パーティショニングもサポートしています。
使用例
以下の例では、public.test という名前の標準テーブルをオンラインでパーティションテーブルに変換する方法を示します。
1. データベースパラメーターの設定
rds_online_migrate 機能は論理デコーディングに依存します。ApsaraDB RDS コンソールで、wal_level パラメーターを logical に設定します。
2. ソーステーブルとデータの準備
変換のソーステーブルとして、public.test という名前の標準テーブルを作成します。次に、実際のビジネスシナリオをシミュレートするために、100 万行のテストデータを挿入します。
-- ソーステーブルの作成
CREATE TABLE public.test(id int4 PRIMARY KEY, info text);
-- テストデータの挿入
INSERT INTO public.test SELECT x, repeat(x::text, 2) FROM generate_series(1, 1000000) AS x;3. 拡張機能のインストール
操作を実行するデータベースに rds_online_migrate 拡張機能を作成します。
CREATE EXTENSION rds_online_migrate;4. 移行先のパーティションテーブルの作成
ソーステーブルと同じ構造を持つ public.test_p という名前の移行先のパーティションテーブルを作成します。この移行先テーブルは、ソーステーブルと同じスキーマ (名前空間) にある必要があります。この例では、ID をハッシュ化してパーティション分割し、4 つのサブパーティションを持つテーブルを作成します。
CREATE TABLE public.test_p (LIKE test INCLUDING ALL) PARTITION BY HASH(id);
CREATE TABLE public.test_p_0 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE public.test_p_1 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE public.test_p_2 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE public.test_p_3 PARTITION OF public.test_p FOR VALUES WITH (MODULUS 4, REMAINDER 3);5. オンライン変換の実行
rds_online_migrate.rewrite_table 関数を呼び出して、オンラインパーティショニングプロセスを開始します。関数の最初のパラメーターはソーステーブル名、2 番目は移行先のパーティションテーブル名です。関数は、実行が成功したことを示す t を返します。
SELECT rds_online_migrate.rewrite_table('public.test', 'public.test_p');
-- 期待される出力：
rewrite_table
---------------
t
(1 row)6. 変換結果の検証
操作が成功すると、関数は自動的にテーブル名を切り替え、ビジネスのシームレスな移行を保証します：
元のテーブル
public.testはpublic.test_rds_bkpに名前が変更されます。このテーブルは、後の検証のためのデータバックアップとして機能し、任意で削除できます。移行先のパーティションテーブル
public.test_pはpublic.testに名前が変更され、新しいテーブルとして使用されます。
次に、以下の手順で結果を検証します：
テーブルスキーマの確認
\dコマンドを使用してリレーションのリストを表示できます。テーブル名が期待どおりに切り替えられ、新しいtestテーブルがpartitioned tableであることを確認します。testdb=> \d -- 期待される出力： リレーションのリスト Schema | Name | Type | Owner --------+--------------+-------------------+----------- public | test | partitioned table | rds_super public | test_p_0 | table | rds_super public | test_p_1 | table | rds_super public | test_p_2 | table | rds_super public | test_p_3 | table | rds_super public | test_rds_bkp | table | rds_super (6 rows)データ整合性の検証 新しいテーブル、バックアップテーブル、および各パーティションの行数をクエリして、データ移行が完了し、データが正しく分散されていることを確認できます。
バックアップテーブルの総行数をクエリします。カウントは移行前のカウントと同じである必要があります。
SELECT count(*) FROM public.test_rds_bkp; -- 期待される出力：1000000新しいパーティションテーブルの総行数をクエリします。カウントはバックアップテーブルのカウントと一致する必要があります。
SELECT count(*) FROM public.test; -- 期待される出力：1000000各パーティションの行数をクエリして、データがハッシュルールに従って子テーブルに分散されていることを確認します。
SELECT count(*) FROM public.test_p_0; -- 期待される出力：249589 SELECT count(*) FROM public.test_p_1; -- 期待される出力：250376 SELECT count(*) FROM public.test_p_2; -- 期待される出力：249786 SELECT count(*) FROM public.test_p_3; -- 期待される出力：250249