Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
ライセンスコストの削減、クラウド運用の柔軟性向上、ベンダーロックイン回避を目的とし、SQL ServerからPostgreSQLへ移行する企業が増えています。しかしSQL ServerとPostgreSQLはアーキテクチャ、インデックスの動作、SQL構文、トランザクション制御に大きな相違点が存在するため、多くの現場が想定以上に移行が複雑であると感じています。
本ガイドではSQL ServerからPostgreSQLへの移行手順をステップバイステップで解説し、代表的な移行課題、適切な移行手法、本番切り替え時の停止時間を抑制する企業向けの手法を紹介します。
RedditのSQL Server関連ディスカッションにおいて、経験豊富なDBAは以下のようにまとめています。
「SQL ServerからPostgreSQLへの移行は単なるデータ移行ではなく、大規模なリファクタリングである」
多くの担当者はSQL ServerからPostgreSQLへの移行を「テーブルを出力しPostgreSQLに取り込むだけ」と認識しています。実際のところ、移行の難易度の大半は2つのデータベースエンジンのアーキテクチャの差異に起因します。
代表的な課題として識別子の大文字小文字の区別が挙げられます。SQL Serverは標準で大文字小文字を区別しないのに対し、PostgreSQLは引用符で囲まれていない識別子を自動的に小文字へ変換します。
例：
SELECT * FROM CustomerTable;PostgreSQL内部では下記のように解釈されます。
SELECT * FROM customertable;この仕様により、移行後のアプリケーションは次のようなエラーで動作不良を起こすケースが頻繁に発生します。
ERROR: relation "CustomerTable" does not existインデックスの仕組みにも違いが存在します。SQL Serverはクラスタードインデックスを活用するのに対し、PostgreSQLはヒープテーブルを採用し、インデックスをテーブルデータと分離して保持します。SQL Server向けに最適化されたアプリケーションは、移行後に追加のチューニングが必要になる場合が多いです。
データ型の互換性も複雑な要因の一つです。Unicodeの扱い、タイムスタンプの解釈方法、自動採番シーケンスの同期問題など、見た目は類似するデータ型であっても、本番環境で障害を引き起こす可能性があります。
SQL ServerからPostgreSQLへ移行する際の一般的なデータ型対応は下表の通りです。
| SQL Server | PostgreSQL |
|---|---|
| NVARCHAR | VARCHAR / TEXT |
| VARCHAR(MAX) | TEXT |
| BIT | BOOLEAN |
| DATETIME | TIMESTAMP |
| UNIQUEIDENTIFIER | UUID |
| INT IDENTITY | SERIAL / IDENTITY |
移行ツールを選定する前に、多くの企業移行プロジェクトで採用されている全体の流れを把握することが重要です。
事前評価
↓
スキーマ変換
↓
初期一括データロード
↓
CDCによる増分同期
↓
検証・テスト
↓
本番切り替え
移行プロジェクトは通常、互換性評価から開始します。この段階でスキーマ、ストアドプロシージャ、インデックス設計、リファクタリングが必要なアプリケーションの依存関係を分析します。
次にスキーマ変換と初期の一括データ読み込みを実施します。基準となるデータの同期が完了した後、多くの企業はCDC（変更データキャプチャ）レプリケーションを有効化し、アプリケーションを稼働させたまま増分変更データを継続的に同期します。
同期が安定した後、エンジニアはレコード件数の照合、テーブル比較、アプリ動作テストを実施し、最後に本番環境の切り替えを実行します。
実際の移行プロジェクトにおいて、最初のデータ転送自体が原因で失敗するケースは稀です。大半のトラブルは、アプリケーションがPostgreSQLに接続し運用開始した後に発生します。
SQL Serverのストアドプロシージャは独自のT-SQL構文、一時テーブルの仕様、SQL Server Agentジョブなどを利用している場合が多く、PostgreSQL上で直接実行することはできません。多くの場合、PL/pgSQLまたは外部スケジューラーを利用して業務ロジックを手動で書き換える必要があります。
SQL Serverは既定で大文字小文字を区別しない一方、PostgreSQLは引用符なしの識別子を小文字に変換します。この違いにより、テーブル名やカラム名とアプリのクエリが一致せず、移行後アプリが異常終了する事例が頻発します。
SQL Serverの既定の照合ルールに依存していたアプリケーションは、移行後PostgreSQL上でソート結果や文字列比較の挙動が変化する可能性があります。
データ取り込み完了後、PostgreSQLのシーケンス値が移行済みのレコードの番号と自動的に連携しません。手動で調整を実施しないと、後続の登録処理で重複キーエラーが発生します。
企業が頻繁に遭遇する互換性の課題には以下があります。
これらの問題が存在するため、最終的な本番切り替え前の十分なテスト・検証が不可欠です。
移行手法は運用シナリオごとに使い分ける必要があります。軽量なオープンソース移行ツールで十分なケースもあれば、ほぼ無停止で運用可能な企業向けリアルタイム同期基盤が必要なケースも存在します。
ここでは代表的な従来型の2つの移行手法を紹介します。
無料のSQL ServerからPostgreSQLへの移行ツールを探す場合、PostgreSQLコミュニティではpgloaderが最初に推奨されます。
pgloaderは異種データベース変換向けのオープンソースコマンドラインツールです。スキーマの自動生成、一括ロード、SQL ServerとPostgreSQL間のデータ型変換機能を搭載しています。
開発環境、中規模以下のデータベース、一時的な停止が許容できるオフライン移行に適しています。
手順1. pgloaderをインストール
Ubuntu環境：
sudo apt install pgloadermacOS環境：
brew install pgloaderインストール完了後、pgloaderがSQL ServerとPostgreSQL双方に接続できるか検証します。
手順2. PostgreSQL側にデータベースを作成
移行実行前に、移行先となるPostgreSQLデータベースを作成します。
CREATE DATABASE targetdb;本番データを取り込む前に、ユーザー権限、ネットワークアクセス設定も構成してください。
手順3. 移行コマンドを実行
pgloaderの移行コマンドを実行します。
pgloader mssql://sa:password@sqlserver/source_db \
postgresql://postgres:password@localhost/targetdb
実行中、pgloaderは自動的にSQL Serverのスキーマを抽出し、データ型を変換、PostgreSQLのテーブルを作成し、移行先へレコードを登録します。
手順4. 移行データの検証
移行完了後、下記項目を検証します。
pgloaderは主にオフライン移行向けのため、切り替え時には本番の停止時間が発生します。
Microsoft製品を中心に基盤を運用している企業は、SQL Server Integration Services（SSIS）を選択するケースが多いです。
SSISはMicrosoft純正のETL基盤であり、多くのSQL Server管理者が慣れているGUI型のワークフロー環境を提供します。完全にスクリプトに依存せず、視覚的に移行パイプライン、変換ロジック、同期フローを設定可能です。
既にMicrosoftのETL基盤を活用しており、移行時に柔軟なデータ変換を必要とする企業に適しています。
手順1. SSISコンポーネントとドライバーを導入
移行環境には通常下記が必要となります。
インストール後、SQL ServerとPostgreSQLの接続性を確認します。
手順2. Integration Servicesプロジェクトを作成
Visual Studio内で新規SSISプロジェクトを作成し、SQL Serverを移行元データベースとして設定します。
続いてPostgreSQL ODBCコネクターを通じ、PostgreSQLを移行先として構成します。
手順3. データフローと変換ルールを設定
移行元・移行先の接続設定完了後、以下を構成します。
移行時にスキーマの再構成が必要な場合は、この設定が非常に重要となります。
手順4. 実行後、データを検証
ワークフロー設定完了後、SSISパッケージを実行し、移行したデータを慎重に検証します。
本番切り替え前に、レコード件数の比較、インデックス確認、アプリ動作テストを実施します。
SSISは柔軟なデータ変換に強みを持つ一方、大規模な本番システムで長期的な増分同期を安定的に運用するには管理負荷が高まります。
多くの企業にとって最大の課題は単なるデータ移送ではありません。
真の課題は、本番データベースを業務を停止させずに移行する手法をどう確立するかです。
従来のオフライン移行ツールは移行期間中、アプリケーションの書き込みを停止する必要があります。大規模DBの場合、数時間以上の停止が発生する可能性があります。
この背景から、現在多くの企業がCDCを活用した移行アーキテクチャを採用しています。
変更データキャプチャ（CDC）はSQL Server上のINSERT、UPDATE、DELETEを継続的に捕捉し、リアルタイムでPostgreSQLへ同期します。移行期間中にアプリケーションを停止する必要がなく、バックグラウンドで同期処理を継続できます。
従来のオフライン移行手法と異なり、CDCベースの移行では本番システムを稼働させたまま、データベースの増分変更を継続的に同期可能です。
この手法は特に下記の環境に適しています。
初期一括ロードと継続的な増分同期を分離することで、移行時の運用リスクを大幅に低減できます。
Info2softが提供するi2Streamは、異種データベース移行や災害対策用途向けに開発された企業向けリアルタイム同期プラットフォームです。
従来のオフライン移行ツールと異なり、i2StreamはCDC技術を活用し、SQL ServerとPostgreSQL間のデータ変更をリアルタイムで継続同期します。
停止時間、同期精度、業務継続性が最重要要件となる企業本番環境向けに設計されています。
– リアルタイムCDC同期
i2StreamはSQL ServerのINSERT/UPDATE/DELETEを継続的に捕捉しPostgreSQLへリアルタイム同期。移行期間中もアプリケーションを稼働させ続けられます。
– ほぼ無停止での切り替え
長時間本番業務を停止する必要はなく、同期遅延が限りなくゼロになったタイミングで最終切り替えを実施可能です。
– 自動検証と監視機能
タスク検査、テーブル比較、同期状況監視が標準搭載されており、切り替え後のデータ不整合リスクを低減します。
– 地域間・ハイブリッドクラウドに対応
異種環境、地域間レプリケーション、ハイブリッドクラウド導入、Aurora PostgreSQL移行といった企業基盤で一般的なシナリオに対応します。
– 企業規模に応じたスケーラビリティ
高圧縮転送、中断再開、増分DDL同期、大規模本番データベース移行業務に対応します。
AWS環境のシステム近代化施策の一環として、SQL ServerからAurora PostgreSQLへ移行を計画する企業も増えています。
Aurora PostgreSQLはPostgreSQLの互換性とAWSのマネージド基盤を融合し、自動フェイルオーバー、弾力的なスケーリング、統合バックアップ管理機能を提供します。
移行の大まかな流れは通常のPostgreSQL移行と同様ですが、AWS環境特有のネットワーク、セキュリティグループ、レプリケーション構成、パラメータ設定の考慮事項が追加されます。
クラウド移行の時間枠に制限があるため、SQL ServerからAurora PostgreSQLへ移行する企業は、最終切り替え時の停止時間を抑えるためCDC型同期ツールを導入するケースが一般的です。
| 機能 | pgloader | SSIS | i2Stream |
|---|---|---|---|
| ツール種別 | オープンソースCLI | 従来型ETL | 企業向けCDCプラットフォーム |
| 運用難易度 | 中 | 高 | 低 |
| 停止時間 | 長くなりがち | データ量に依存 | 極めて短い |
| 増分同期 | 制限あり | 一部対応 | リアルタイム |
| データ検証 | 手動 | 手動 | 自動 |
| クロスプラットフォーム対応 | 良好 | 制限あり | 非常に強固 |
| 最適な利用先 | 開発者・DBA向け軽量移行 | Microsoft中心の環境 | 企業本番システム |
実運用において、停止時間が許容できる開発系の軽量移行にはpgloaderが適します。MicrosoftのETLワークフローを活用している組織にはSSISが選択肢となります。停止時間とデータ整合性が最重要となる企業本番システムでは、i2StreamなどCDC型プラットフォームがより安全な選択肢となります。
データベースの移行完了はスタート地点に過ぎません。
切り替え後、PostgreSQL環境を安定稼働させるため追加のチューニングが必要となるのが一般的です。
重要な施策の一つがVACUUMの適切な設定です。PostgreSQLはMVCC（複数バージョン同時実行制御）を採用しており、不要なタプルが時間経過とともに蓄積します。クリーンアップ処理を適切に調整しないとパフォーマンス低下を引き起こします。
また移行後は自動採番シーケンスを慎重に検証する必要があります。データ取り込み後、SERIALまたはIDENTITYの値が不連続になり、後続の登録処理で重複キーエラーが発生する事例が存在します。
例：
SELECT setval('users_id_seq', MAX(id)) FROM users;移行直後数日間は、トランザクション遅延、クエリ実行計画、ロック競合、レプリケーション遅延、ディスクI/Oを継続的に監視する必要があります。
Q. 停止時間ゼロでSQL ServerからPostgreSQLへ移行可能ですか？
A. 可能です。現在多くの企業がCDC型同期プラットフォームを活用し、本番システムを稼働させたままほぼ無停止移行を実施しています。
Q. SQL ServerからPostgreSQLへの最適な移行ツールは何ですか？
A. 環境によって最適解は異なります。軽量な無料移行にはpgloader、Microsoftエコシステム内ではSSIS、停止時間が重要な企業本番移行にはi2StreamなどCDC型プラットフォームが適しています。
Q. SQL ServerからPostgreSQLの移行にはどれくらいの時間がかかりますか？
A. データベース規模、スキーマの複雑さ、同期方式、ネットワーク帯域に左右されます。小規模DBは数時間、企業の大規模本番システムでは数日～数週間に分けた段階的移行を実施する場合もあります。
Q. SQL ServerからAurora PostgreSQLへ移行できますか？
A. 可能です。AWSのシステム近代化プロジェクトにおいて、Aurora PostgreSQLはクラウドネイティブな移行先として広く活用されています。
小規模な開発プロジェクトであればpgloaderなどのオープンソースツールで十分なケースもあります。しかし停止時間、同期精度、業務継続性が求められる企業本番環境においては、リアルタイムCDCによる移行アーキテクチャがより安全な選択肢となります。
特に大規模データベース、地域間レプリケーション、Aurora PostgreSQLへの移行、ほぼ無停止での切り替え要件が存在する企業において重要となります。
適切な事前計画と移行戦略を組み合わせることで、運用リスクを抑えながらSQL ServerからPostgreSQLへの移行を成功させ、スケーラブルでクラウド対応可能な基盤を構築できます。
