sql >> データベース >  >> RDS >> PostgreSQL

PostgreSQLのクラウドへの移行-Amazon、Google、Microsoftのソリューションの比較

    鳥瞰的に見ると、PostgreSQLワークロードをクラウドに移行する場合、クラウドプロバイダーの選択に違いはないように思われます。 PostgreSQLを使用すると、いくつかの制限はありますが、論理レプリケーションを介して、ダウンタイムなしでデータを簡単にレプリケートできます。彼らのサービスをより魅力的なクラウドプロバイダーにするために、それらの制限のいくつかを解決するかもしれません。利用可能なPostgreSQLのバージョン、互換性、制限、制限、およびパフォーマンスの違いについて考え始めると、移行サービスがサービス提供全体の重要な要素であることが明らかになります。 「提供し、移行する」というケースではなくなりました。 「制限を最小限に抑えて、提供し、移行します」のようになりました。

    移行は、小規模な組織でも大規模な組織でも同様に重要です。許容可能なダウンタイムと移行後の作業については、PostgreSQLクラスターのサイズほどではありません。

    戦略の選択

    移行戦略では、データベースのサイズ、ソースとターゲット間のネットワークリンク、およびクラウドプロバイダーが提供する移行ツールを考慮する必要があります。

    ハードウェアまたはソフトウェア？

    インターネットの初期の頃にUSBキーやDVDを郵送するのと同じように、ネットワーク帯域幅が目的の速度でデータを転送するのに十分でない場合、クラウドプロバイダーはハードウェアソリューションを提供しています。最大数百ペタバイトのデータを伝送します。以下は、ビッグ3のそれぞれからの現在のソリューションです。

    利用可能なオプションを示すGoogleが提供する便利な表：

    GCPアプライアンスは転送アプライアンスです

    データサイズとネットワーク帯域幅に基づくAzureからの同様の推奨事項：

    Azureアプライアンスはデータボックスです

    データ移行ページの終わりに向けて、AWSは、ソリューションの推奨事項とともに、期待できることを垣間見ることができます。

    データベースサイズが100GBを超え、ネットワーク帯域幅が制限されている場合、AWSはハードウェアソリューション。

    AWSアプライアンスはSnowballEdgeです

    データのエクスポート/インポート

    ダウンタイムを許容する組織は、PostgreSQLがすぐに利用できる一般的なツールのシンプルさから恩恵を受けることができます。ただし、あるクラウド（またはホスティング）プロバイダーから別のクラウドプロバイダーにデータを移行する場合は、出力コストに注意してください。

    AWS

    移行をテストするために、ホームネットワークサーバーの1つで実行されているNextcloudデータベースのローカルインストールを使用しました：

    postgres=# select pg_size_pretty(pg_database_size('nextcloud_prod'));

pg_size_pretty

----------------

58 MB

(1 row)



nextcloud_prod=# \dt

                     List of relations

Schema |             Name | Type  | Owner

--------+-------------------------------+-------+-----------

public | awsdms_ddl_audit              | table | s9sdemo

public | oc_accounts                   | table | nextcloud

public | oc_activity                   | table | nextcloud

public | oc_activity_mq                | table | nextcloud

public | oc_addressbookchanges         | table | nextcloud

public | oc_addressbooks               | table | nextcloud

public | oc_appconfig                  | table | nextcloud

public | oc_authtoken                  | table | nextcloud

public | oc_bruteforce_attempts        | table | nextcloud

public | oc_calendar_invitations       | table | nextcloud

public | oc_calendar_reminders         | table | nextcloud

public | oc_calendar_resources         | table | nextcloud

public | oc_calendar_resources_md      | table | nextcloud

public | oc_calendar_rooms             | table | nextcloud

public | oc_calendar_rooms_md          | table | nextcloud

...

public | oc_termsofservice_terms       | table | nextcloud

public | oc_text_documents             | table | nextcloud

public | oc_text_sessions              | table | nextcloud

public | oc_text_steps                 | table | nextcloud

public | oc_trusted_servers            | table | nextcloud

public | oc_twofactor_backupcodes      | table | nextcloud

public | oc_twofactor_providers        | table | nextcloud

public | oc_users                      | table | nextcloud

public | oc_vcategory                  | table | nextcloud

public | oc_vcategory_to_object        | table | nextcloud

public | oc_whats_new                  | table | nextcloud

(84 rows)

The database is running PostgreSQL version 11.5:

postgres=# select version();

                                                version

------------------------------------------------------------------------------------------------------------

PostgreSQL 11.5 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1), 64-bit

(1 row)

    PostgreSQLをAmazonRDSにインポートするためのAmazonのサービスであるAWSDMSで使用するPostgreSQLユーザーも作成しました：

    postgres=# \du s9sdemo

            List of roles

Role name | Attributes |  Member of

-----------+------------+-------------

s9sdemo   |   | {nextcloud}

    AWS DMSには、クラウドのマネージドソリューションに期待されるように、多くの利点があります。

    • 自動スケーリング（コンピューティングインスタンスは適切なサイズである必要があるため、ストレージのみ）
    • 自動プロビジョニング
    • 従量課金モデル
    • 自動フェイルオーバー

    ただし、ライブデータベースのデータの一貫性を維持することは最善の努力です。 100％の整合性は、データベースが読み取り専用モードの場合にのみ達成されます。これは、テーブルの変更がどのようにキャプチャされるかによって決まります。

    つまり、テーブルには異なるポイントインタイムカットオーバーがあります：

    クラウド内のすべてのものと同様に、移行サービス。

    移行環境を作成するには、スタートガイドに従って、レプリケーションインスタンス、ソース、ターゲットエンドポイント、および1つ以上のタスクをセットアップします。

    レプリケーションインスタンス

    レプリケーションインスタンスの作成は、AWSのEC2インスタンスに精通している人なら誰でも簡単です。

    デフォルトからの唯一の変更は、AWSDMS3.3.0または後で私のローカルPostgreSQLエンジンが11.5であるため：

    現在利用可能なAWSDMSバージョンのリストは次のとおりです。

    大規模なインストールでは、AWSDMSの制限にも注意する必要があります。

    >

    PostgreSQL論理レプリケーションの結果である一連の制限もあります制限。たとえば、AWSDMSはセカンダリオブジェクトを移行しません：

    PostgreSQLでは、すべてのインデックスがセカンダリインデックスであり、この詳細な説明で述べられているように、これは悪いことではありません。

    ソースエンドポイント

    ウィザードに従って、ソースエンドポイントを作成します。

    セットアップシナリオでは、インターネットを使用したVPCへのネットワークの構成ホームネットワークでは、送信元エンドポイントのIPアドレスが内部サーバーにアクセスできるようにするためにいくつかの調整が必要でした。まず、エッジルーター（173.180.222.170）でポート転送を作成し、ポート30485のトラフィックをポート5432の内部ゲートウェイ（10.11.11.241）に送信しました。ここで、iptablesルールを介して送信元IPアドレスに基づいてアクセスを微調整できます。そこから、ネットワークトラフィックはSSHトンネルを経由してPostgreSQLデータベースを実行しているWebサーバーに流れます。説明されている構成では、pg_stat_activityの出力のclient_addrは127.0.0.1として表示されます。

    着信トラフィックを許可する前に、iptablesログにはip =3.227.167.58のレプリケーションインスタンスからの12回の試行が表示されます）：

    Jan 19 17:35:28 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23973 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:29 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23974 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:31 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23975 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:35 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23976 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:48 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4328 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:49 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4329 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:51 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4330 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:55 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4331 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:08 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8298 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:09 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8299 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:11 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8300 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:16 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8301 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

    送信元エンドポイントのIPアドレス（3.227.167.58）を許可すると、接続テストが成功し、送信元エンドポイントの構成が完了します。パブリックネットワークを介したトラフィックを暗号化するためのSSL接続もあります。これは、以下のクエリを使用してPostgreSQLサーバーとAWSコンソールで確認できます。

    postgres=# SELECT datname, usename, client_addr, ssl, cipher, query, query_start FROM pg_stat_activity a, pg_stat_ssl s where a.pid=s.pid and usename = 's9sdemo';

datname | usename | client_addr | ssl | cipher | query | query_start

---------+---------+-------------+-----+--------+-------+-------------

(0 rows)

    …そして、AWSコンソールから接続を実行している間監視します。結果は次のようになります。

    postgres=# \watch



                                                                           Sun 19 Jan 2020 06:50:51 PM PST (every 2s)



    datname     | usename | client_addr | ssl |           cipher |                 query | query_start

----------------+---------+-------------+-----+-----------------------------+------------------------------------------------------------------------------------+-------------------------------

 nextcloud_prod | s9sdemo | 127.0.0.1   | t | ECDHE-RSA-AES256-GCM-SHA384 | select cast(setting as integer) from pg_settings where name = 'server_version_num' | 2020-01-19 18:50:51.463496-08

(1 row)

    …AWSコンソールは成功を報告する必要があります：

    前提条件のセクションに示されているように、移行オプションを選択した場合フルロード、進行中のレプリケーションでは、PostgreSQLユーザーの権限を変更する必要があります。この移行オプションにはスーパーユーザー権限が必要なため、以前に作成したPostgreSQLユーザーの設定を調整しました：

    nextcloud_prod=# \du s9sdemo

         List of roles

Role name | Attributes | Member of

-----------+------------+-----------

s9sdemo   | Superuser  | {}

    同じドキュメントに、postgresql.confを変更する手順が含まれています。元の差分との違いは次のとおりです。

    --- a/var/lib/pgsql/data/postgresql.conf

+++ b/var/lib/pgsql/data/postgresql.conf

@@ -95,7 +95,7 @@ max_connections = 100                 # (change requires restart)



# - SSL -



-#ssl = off

+ssl = on

#ssl_ca_file = ''

#ssl_cert_file = 'server.crt'

#ssl_crl_file = ''

@@ -181,6 +181,7 @@ dynamic_shared_memory_type = posix  # the default is the first option



# - Settings -



+wal_level = logical

#wal_level = replica                   # minimal, replica, or logical

                                       # (change requires restart)

#fsync = on                            # flush data to disk for crash safety

@@ -239,6 +240,7 @@ min_wal_size = 80MB

#max_wal_senders = 10          # max number of walsender processes

                              # (change requires restart)

#wal_keep_segments = 0         # in logfile segments; 0 disables

+wal_sender_timeout = 0

#wal_sender_timeout = 60s      # in milliseconds; 0 disables



#max_replication_slots = 10    # max number of replication slots

@@ -451,6 +453,7 @@ log_rotation_size = 0                       # Automatic rotation of logfiles will

#log_duration = off

#log_error_verbosity = default         # terse, default, or verbose messages

    最後に、レプリケーションインスタンスのIPアドレスからのSSL接続を許可するために、pg_hba.conf設定を調整することを忘れないでください。

    これで次のステップの準備が整いました。

    ターゲットエンドポイント ウィザードに従ってターゲットエンドポイントを作成します：

    この手順では、指定されたエンドポイントを持つRDSインスタンスが空のデータベースnextcloud_awsdms。データベースは、RDSインスタンスのセットアップ中に作成できます。

    この時点で、AWSネットワーキングが正しくセットアップされていれば、接続テストを実行する準備ができているはずです：

    環境が整ったら、移行タスクを作成します。 ：

    移行タスク

    ウィザードが完了すると、構成は次のようになります。

    ...そして同じビューの2番目の部分：

    >

    タスクが開始されると、進行状況を監視できます—タスクを開きます詳細を表示し、[テーブル統計]まで下にスクロールします：

    AWS DMSは、データベーステーブルを移行するためにキャッシュされたスキーマを使用しています。移行が進行している間、AWSコンソールに加えて、ソースデータベースのクエリとPostgreSQLエラーログを引き続き「監視」できます。

    エラーの場合、障害状態がコンソールに表示されます：

    手がかりを探す場所の1つは、CloudWatchですが、テスト中はログが記録されます。公開されることはありませんでした。これは、AWS DMS 3.3.0のベータ版では、この演習の終わりに近づいていることが判明したため、別の問題である可能性があります。

    移行の進行状況は、AWSDMSコンソールに適切に表示されます。

    >

    移行が完了したら、もう一度確認して、PostgreSQLエラーログ、驚くべきメッセージを明らかにします：

    発生しているように見えるのは、PostgreSQL 9.6、10ではpg_classテーブルです。名前付き列relhaspkeyが含まれていますが、11ではそうではありません。これは、以前に参照したAWSDMS3.3.0のベータバージョンの不具合です。

    GCP

    Googleのアプローチは、オープンソースツールのPgBouncerに基づいています。公式ドキュメントではPostgreSQLをコンピューティングエンジン環境に移行することについて説明しているため、興奮は短命でした。

    AWSDMSに似たCloudSQLへの移行ソリューションをさらに見つける試みは失敗しました。データベース移行戦略には、PostgreSQLへの参照は含まれていません：

    オンプレミスのPostgreSQLインストールは、サービスを使用してCloudSQLに移行できますGoogleCloudパートナーの1つです。

    考えられる解決策は、Cloud SQLに対するPgBouncerかもしれませんが、それはこのブログの範囲内ではありません。

    Microsoftクラウドサービス（Azure）

    オンプレミスからPostgreSQL用のマネージドAzureデータベースへのPostgreSQLワークロードの移行を容易にするために、Microsoftはドキュメントに従って最小限のダウンタイムで移行するために使用できるAzureDMSを提供しています。チュートリアル「DMSを使用してPostgreSQLをオンラインでAzureDatabasefor PostgreSQLに移行する」では、これらの手順について詳しく説明しています。

    Azure DMSのドキュメントでは、PostgreSQLワークロードのAzureへの移行に関連する問題と制限について詳しく説明しています。

    AWS DMSとの顕著な違いの1つは、スキーマを手動で作成する必要があることです。

    このデモは、今後のブログのトピックになります。しばらくお待ちください。


    1. 文字列を連結する方法は？

    2. MariaDBでのSOUNDEX（）のしくみ

    3. SQLclを使用するときにクエリからINSERTステートメントを生成する方法（Oracle）

    4. SQLのデータ型のサイズを変更します