Azure Database for PostgreSQL へのシームレスな移行に関するベスト プラクティス
適用対象:
Azure Database for PostgreSQL - フレキシブル サーバー
この記事では、Azure Database for PostgreSQL への移行で発生することがよくある落とし穴と、それを円滑に成功させるためのベスト プラクティスについて説明します。
移行前の検証
移行の最初のステップとして、移行を実行する前に移行前の検証を行います。 移行セットアップ ページの [検証] および [検証と移行] オプションを使用できます。 移行前の検証では、定義済みのルール セットに対して徹底的な検査が行われます。 目的は、潜在的な問題を明らかにし、是正措置のための役に立つ分析情報を提供することです。 結果が成功状態になるまで、移行前の検証を実行し続けます。 詳しくは、移行前の検証に関する記事をご覧ください。
ターゲット フレキシブル サーバーの構成
データの最初の基本コピーの間に、移行先に対して複数の INSERT ステートメントが実行されて、WAL (先書きログ) が生成されます。 これらの WAL がアーカイブされるまで、ログによって、移行先のストレージと、データベースに必要なストレージが消費されます。
その値を計算するには、移行元インスタンスにサインインし、移行対象のすべてのデータベースに対して次のコマンドを実行します。
SELECT pg_size_pretty( pg_database_size('dbname') );
フレキシブル サーバーに十分なストレージを割り当てることをお勧めします。これは、上記のコマンドの出力ごとに使われている量より、1.25 倍つまり 25% 多いストレージに相当します。 [ストレージの自動拡張] も使用できます。
重要
ストレージ サイズは、手動構成またはストレージの自動拡張で減らすことはできません。 ストレージ構成範囲内の各ステップではサイズが 2 倍になるため、必要なストレージを事前に見積もることをお勧めします。
始める場所としては、ポータルを使用した Azure Database for PostgreSQL フレキシブル サーバーの作成に関するクイックスタートが適しています。 「Azure Database for PostgreSQL - フレキシブル サーバーのコンピューティングとストレージのオプション」にも、各サーバー構成に関する詳細情報が用意されています。
移行のタイムライン
各移行の有効期間は移行開始から 7 日間 (168 時間) であり、7 日後にはタイムアウトします。 データの検証とすべてのチェックが完了したら、移行とアプリケーションの一括移行を完了して、移行のタイムアウトを回避できます。オンライン移行では、最初の基本コピーが完了した後、一括移行がタイムアウトするまでの期間は 3 日間 (72 時間) です。オフライン移行では、データ損失を防ぐために、アプリケーションによるデータベースへの書き込みを停止する必要があります。 同様に、オンライン移行の場合は、移行全体を通じてトラフィックを低く抑えてください。
ほとんどの非運用サーバー (開発、UAT、テスト、ステージング) は、オフライン移行を使って移行されます。 これらのサーバーのデータは運用サーバーよりも少ないため、移行は短時間で完了します。 運用サーバーの移行では、事前に計画するため、移行が完了するまでにかかる時間を把握しておく必要があります。
移行が完了するまでにかかる時間は、いくつかの要因によって異なります。 これには、データベースの数、サイズ、各データベース内のテーブルの数、インデックスの数、テーブル間のデータの分散などが含まれます。 また、移行先サーバーの SKU と、移行元インスタンスと移行先サーバーで使用できる IOPS にも左右されます。 移行時間に影響を与える可能性のある多くの要因を考えると、移行が完了するまでの合計時間を見積もることは困難です。 最善の方法は、実際のワークロードでテスト移行を実行することです。
運用サーバーの移行を実行するための合計ダウンタイムを計算するには、次のフェーズを考慮します。
PITR の移行 - 運用データベース サーバーの移行にかかる時間を適切に見積もる最善の方法は、運用サーバーのポイントインタイム リストアを実行し、この新しく復元されたサーバーでオフライン移行を実行することです。
バッファーの移行 - 上記の手順を完了したら、アプリケーションのトラフィックが少ない時間帯に実際の運用環境への移行を計画できます。 この移行は、同日に計画することも、場合によっては 1 週間後に計画することもできます。 この時点で、ソース サーバーのサイズが増えている可能性があります。 この増加の量に基づいて、運用サーバーの推定移行時間を更新してください。 増加が大きい場合は、PITR サーバーを使用して別のテストを行うことを検討できます。 しかし、ほとんどのサーバーでは、サイズはそれほど大きく増加しないはずです。
データの検証 - 運用サーバーの移行が完了したら、フレキシブル サーバー内のデータが移行元インスタンスの正確なコピーであるかどうかを検証する必要があります。 お客様は、オープンソースまたはサードパーティ製のツールを使うことも、手動で検証を行うこともできます。 実際の移行の前に行う検証手順を準備します。 検証には、次のものが含まれます。
移行に関連するすべてのテーブルの行数が一致していること。
すべてのデータベース オブジェクト (テーブル、シーケンス、拡張機能、プロシージャ、インデックス) の一致数
主要なアプリケーション関連の列の最大 ID または最小 ID の比較
Note
データベースのサイズが、検証に適したメトリックである必要があります。 移行元インスタンスに肥大化したタプルやデッド タプルが含まれる場合があり、それによって移行元インスタンスのサイズが増大する可能性があります。 移行元インスタンスと移行先サーバー間でサイズが異なるのは、まったく正常なことです。 検証の最初の 3 つの手順で問題がある場合は、移行に問題があることを示しています。
サーバー設定の移行 - すべてのカスタム サーバー パラメーター、ファイアウォール規則 (該当する場合)、タグ、アラートは、移行元インスタンスから移行先に手動でコピーする必要があります。
接続文字列の変更 - 検証が成功した後、アプリケーションの接続文字列をフレキシブル サーバーに変更する必要があります。 この作業では、アプリケーション チームと連携して、移行元インスタンスをポイントしている接続文字列のすべての参照を変更します。 フレキシブル サーバーの接続文字列では、user=username という形式でユーザー パラメーターを使用できます。
例: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1
ほとんどの場合、移行は問題なく実行されますが、デバッグにさらに時間が必要な場合や、移行を再開する必要がある場合などの不測の事態に備えることをお勧めします。
移行速度のベンチマーク
次の表は、移行サービスを使ってさまざまなサイズのデータベースの移行を実行するのにかかる時間を示したものです。 移行は、SKU – Standard_D4ds_v4 (4 コア、16 GB メモリ、128 GB ディスク、500 IOPS) のフレキシブル サーバーを使用して実行されました
| データベース サイズ | おおよその所要時間 (HH:MM) |
|---|---|
| 1 GB | 00:01 |
| 5 GB | 00:03 |
| 10 GB | 00:08 |
| 50 GB | 00:35 |
| 100 GB | 01:00 |
| 500 GB | 04:00 |
| 1,000 GB | 07:00 |
注意
上記の数値は、移行が完了するまでの概算時間です。 実際のワークロードでテスト移行を実行し、サーバーの移行に関する正確な値を取得することを強くお勧めします。
重要
移行をより速く実行するには、フレキシブル サーバーに対してより高い SKU を選択します。 Azure Database for PostgreSQL フレキシブル サーバーでは、ダウンタイムがほぼゼロのコンピューティングと IOPS のスケーリングがサポートされているため、最小限のダウンタイムで SKU を更新できます。 SKU は、移行後にアプリケーションのニーズに合わせていつでも変更できます。
移行速度の向上 - テーブルの並列移行
PostgreSQL 移行サービスがフレキシブル サーバー上のコンテナーを使い切ってしまうので、移行先には強力な SKU を使うことをお勧めします。 SKU が強力であるほど、より多くのテーブルを並列に移行できます。 移行後に、SKU を任意の構成にスケールバックできます。 このセクションでは、テーブル間のデータの分散をさらにバランスよくする必要がある場合や、SKU を強力にしても移行速度に大きな影響がない場合に、移行速度を向上させる手順について説明します。
移行元でのデータの分散に大きな偏りがあり、ほとんどのデータが 1 つのテーブルに存在する場合、移行用に割り当てられたコンピューティングを完全に利用する必要があり、ボトルネックが発生します。 そのため、大きなテーブルを小さなチャンクに分割し、並列的に移行します。 この機能は、10,000,000 (10 M) を超えるタプルを持つテーブルに適用されます。 次のいずれかの条件を満たす場合は、テーブルをより小さなチャンクに分割できます。
テーブルには、int 型または significant int 型の単純な (複合ではない) 主キーまたは一意なインデックスを含む列が必要です。
Note
アプローチ #2 または #3 の場合は、移行元スキーマに一意なインデックスの列を追加することによる影響を慎重に評価する必要があります。 一意のインデックス列を追加しても、アプリケーションに影響を与えないことを確認した後でない限り、ユーザーが変更を進めることは推奨されません。
テーブルに int 型または significant int 型の単純な主キーまたは一意なインデックスはないが、データ型の条件を満たす列がある場合は、次のコマンドを使ってその列を一意なインデックスに変換できます。 このコマンドでは、テーブルに対するロックは必要ありません。
create unique index concurrently partkey_idx on <table name> (column name);テーブルにシンプルな int/big int 主キーまたは一意のインデックスがない場合、またはデータ型の条件を満たす列がない場合は、ALTER を使用してこのような列を追加し、移行後に削除できます。 ALTER コマンドを実行する場合は、テーブルに対するロックが必要です。
alter table <table name> add column <column name> big serial unique;
上記条件のいずれかが満たされる場合、テーブルは複数のパーティションで並行して移行され、移行速度が大幅に向上します。
しくみ
- 移行サービスは、分割して並列に移行する必要があるテーブルの主キーまたは一意なインデックスの、最大と最小の整数値を検索します。
- 最小値と最大値の間の差が 10,000,000 (10 M) を超える場合、テーブルは複数の部分に分割されて、各部分が並列に移行されます。
まとめると、PostgreSQL 移行サービスは、次の場合にテーブルを並列スレッドで移行して、移行時間を短縮します。
- テーブルに、int 型または significant int 型の単純な主キーまたは一意なインデックスを含む列があります。
- テーブルには少なくとも 10000000 (10m) 行があるため、主キーの最小値と最大値の差は 10000000 (10m) を超えています。
- 使用される SKU には、テーブルの並列移行に利用できるアイドル状態のコアがある。
PostgreSQL データベース内の肥大化のバキューム処理
時間の経過とともに、データが追加、更新、削除されて、PostgreSQL にデッド行や無駄なストレージ領域が蓄積する可能性があります。 この肥大化により、ストレージ要件が増加し、クエリのパフォーマンスが低下する可能性があります。 バキューム処理は、この無駄な領域を再利用し、データベースが効率的に動作することを保証する重要なメンテナンス タスクです。 バキューム処理により、デッド行やテーブルの肥大化などの問題に対処し、ストレージの効率的な使用を保証します。 さらに重要なのは、移行にかかる時間がデータベース サイズの関数であるため、より迅速な移行を実現するのに役立つことです。
PostgreSQL には、デッド行によって占有されているストレージを再利用する VACUUM コマンドが用意されています。 また、ANALYZE オプションを使うと統計情報が収集されて、クエリ プランがさらに最適化されます。 書き込みアクティビティの負荷が高いテーブルの場合、VACUUM FULL を使うと VACUUM プロセスをいっそう積極的に行うことができますが、必要な実行時間が長くなります。
- 標準バキューム
VACUUM your_table;
- 分析を使用したバキューム
VACUUM ANALYZE your_table;
- 高負荷書き込みテーブル用のアグレッシブ バキューム
VACUUM FULL your_table;
この例では、your_table を実際のテーブル名に置き換えます。 FULL を指定しない VACUUM コマンドの場合、領域を効率的に再利用しますが、VACUUM ANALYZE の場合、クエリ プランを最適化します。 VACUUM FULL オプションは、パフォーマンスへの影響が大きいため、慎重に使用する必要があります。
一部のデータベースには、時間経過とともにデータベース肥大化の原因になる可能性のある、画像やドキュメントなどの大きなオブジェクトが格納されます。 VACUUMLO コマンドは、PostgreSQL 内のラージ オブジェクト用に設計されています。
- ラージ オブジェクトのバキューム処理
VACUUMLO;
これらのバキューム戦略を定期的に組み込むことで、適切に管理された PostgreSQL データベースが確保されます。
特別な考慮事項
学習者がチュートリアルまたはモジュールに進む前に認識しておく必要がある、固有の状況、構成、または前提条件を一般に指す、特別な状況があります。 これらの状況には、学習コンテンツを問題なく終えるために必要な特定のソフトウェア バージョン、ハードウェア要件、または追加のツールが含まれる場合があります。
オンライン移行
オンライン移行では pgcopydb follow が使用され、論理デコード制限が適用されます。 さらに、オンライン移行中のデータベースのすべてのテーブルに主キーを用意することをお勧めします。 主キーがない場合、その結果として、移行中に更新や削除を除く挿入操作のみが反映される可能性があります。 オンライン移行に進む前に、関連するテーブルに一時主キーを追加してください。
別の方法として、ALTER TABLE コマンドを使用することができます。アクションは REPLICA IDENTIY で、FULL オプションを指定します。 FULL オプションでは、プライマリ キーがない場合でも、オンライン移行中、移行先ですべての CRUD 操作が反映されるよう、行にすべての列の古い値が記録されます。 これらのオプションが機能しない場合は、代わりにオフライン移行を実行してください。
postgres_fdw 拡張機能を持つデータベース
postgres_fdw モジュールは、外部データ ラッパー postgres_fdw を提供します。これを使用して、外部 PostgreSQL サーバーに保存されているデータにアクセスできます。 データベースでこの拡張機能が使われている場合は、移行を成功させるために次の手順を実行する必要があります。
- 移行元インスタンスで外部データ ラッパーを一時的に削除 (リンク解除) します。
- 移行サービスを使って、残りのデータ移行を実行します。
- 移行後に、外部データ ラッパーのロール、ユーザー、リンクを移行先に戻します。
postGIS 拡張機能を持つデータベース
PostGIS 拡張機能の異なるバージョン間には、破壊的変更や圧縮の問題があります。 フレキシブル サーバーに移行する場合は、より新しいバージョンの PostGIS でアプリケーションを調べて、アプリケーションが影響を受けないこと、または必要な変更を行う必要があることを、確認する必要があります。 postGIS ニュースとリリース ノートが、バージョン間の破壊的変更を理解するための出発点として適しています。
データベース接続のクリーンアップ
移行を開始するときに、このエラーが発生することがあります。
CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.
この場合は、移行をもう一度試みる前に、データベースへのアクティブな接続をすべて閉じるためのアクセス許可を migration user に付与するか、接続を手動で閉じることができます。