19147¶

2024-08-05 Incoming¶

お世話になっております、ヘルスベイシスの鈴木と申します。

現在弊社ではCloudSQL for Postgres(9.6)を使用しているのですが、この度CloudSQL for Postgres(13)へのアップデートを検討しています。

データベースの移行に際してGCPのサービスであるDatabase Migration Serviceを使用することを検討しているのですが、このサービスを利用することによってどう言った料金が発生するかがわかりません。

https://cloud.google.com/database-migration/pricing?hl=ja ドキュメントを見る限りではCloudSQL for Mysqlについては追加料金は発生しないと書いてあるのですが、Postgresについてはどう言った料金が発生するのでしょうか？

お手数ですが、上記ご回答をお願いできればと思います。

よろしくお願い致します。

2024-08-07 Sent¶

株式会社ヘルスベイシス鈴木様

お世話になっております、株式会社G-genサポートの高井です。お問い合わせいただきありがとうございます。ご案内にお時間いただいており恐れ入ります。

ご質問いただいた内容について下記にご案内いたします。

ドキュメントを見る限りではCloudSQL for Mysqlについては追加料金は発生しないと書いてあるのですが、Postgresについてはどう言った料金が発生するのでしょうか？

日本語の料金ページには MySQL のみの記載となっておりますが、英語版ページ[1]を参照いただくと PostgreSQL 同士の移行でも料金が発生しない記載がございます。

[1] Homogenous Use cases pricing (同種移行の場合の料金) - Database Migration Service pricing (Database Migration Service 公式ページ) https://cloud.google.com/database-migration/pricing#homogenous_use_cases_pricing

ご質問いただいております内容への回答は以上となりますが、認識の相違ある場合や不明点などありましたらお知らせくださいませ。引き続きどうぞよろしくお願いいたします。

2024-08-08 Incoming¶

高井様

ご確認頂きありがとうございます。

こちらですが実際にデータベースの移行をするとなった場合、 DMS自体は無料かと思いますが他にはどう言った料金が発生する可能性がありますでしょうか？

新しく立てたデータベースの料金や、データベース間のデータ通信量など、どこで料金が発生する可能性があるかが気になっています。

2024-08-13 Sent¶

株式会社ヘルスベイシス鈴木様

お世話になっております、株式会社G-genサポートの高井です。ご確認いただきありがとうございます。また、ご案内にお時間いただいており恐れ入ります。

追加でご質問いただいた内容について下記にご案内いたします。

DMS自体は無料かと思いますが他にはどう言った料金が発生する可能性がありますでしょうか？

移行で作成した新規インスタンスの料金(ネットワーク含む)が発生することが想定されております。また、Compute Engine の料金がリバース SSH 接続セットアップのコンテキスト[1]で作成したインスタンスに発生する可能性も留意いただけますと幸いです。

[1] Configure connectivity using reverse SSH tunnel (Database Migration Service 公式英語ドキュメント) https://cloud.google.com/database-migration/docs/mysql/configure-connectivity-reverse-ssh-tunnel

2024-08-14 Incoming¶

高井様

お世話になっております、鈴木です。

Compute Engine の料金がリバース SSH 接続セットアップのコンテキスト[1]で作成したインスタンスに発生する可能性

こちらについては発生するかどうかはどのように判断すればよろしいでしょうか？

またネットワークの料金について、CloudSQL間の通信料金についてはどこかに記載されていたりしますでしょうか？

2024-08-15 Sent¶

株式会社ヘルスベイシス鈴木様

お世話になっております、株式会社G-genサポートの高井です。ご確認いただきありがとうございます。追加でご質問いただいた内容について下記にご案内いたします。

Compute Engine の料金がリバース SSH 接続セットアップのコンテキスト[1]で作成したインスタンスに発生する可能性こちらについては発生するかどうかはどのように判断すればよろしいでしょうか？

こちらについては添付リンク先に記載されている図のような、SSH トンネルを経由してアクセスする必要があるような構成をされている場合が対象となります。

またネットワークの料金について、CloudSQL間の通信料金についてはどこかに記載されていたりしますでしょうか？

こちらにつきましては公式料金ページ[1]を添付いたしますので、参照いただければと存じます。

[1] ストレージとネットワークの料金 - Cloud SQL の料金 (Cloud SQL 公式料金ページ) https://cloud.google.com/sql/docs/postgres/pricing?hl=ja#storage-networking-prices

2024-08-16 Incoming¶

高井様

お世話になっております、鈴木です。

料金発生するかの判断方法について、ありがとうございます。こちら承知いたしました。

また、DMSについて追加で質問させてください。実際にDMSを使用してテスト用のデータベースを移行してみたのですが、移行元と移行先でDBストレージ使用量にかなり違いが出ているようです。 DMSはレプリケーションを実行するのでデータ量は同じになる想定だったのですが、これはどういった理由から差分が出ているかわかりますでしょうか？

2024-08-19 Sent¶

株式会社ヘルスベイシス鈴木様

お世話になっております、株式会社G-genサポートの高井です。ご確認いただきありがとうございます。追加でお問い合わせいただいた内容につきまして、現在弊社にて内容を確認しております。

お待たせしており恐れ入りますが、ご案内まで少々お時間いただけますと幸いです。引き続きよろしくお願いいたします。

2024-08-22 Sent¶

株式会社ヘルスベイシス鈴木様

お世話になっております、株式会社G-genサポートの高井です。ご案内にお時間いただいており恐れ入ります。追加でご質問いただいた内容について下記にご案内いたします。

DMSはレプリケーションを実行するのでデータ量は同じになる想定だったのですが、これはどういった理由から差分が出ているかわかりますでしょうか？

お待たせしている中恐れ入りますが、現在当サポートにて検証・確認作業に時間を要しております。なお一部ご案内できる情報が得られておりますので、下記にご案内いたします。

レプリケーション先のリードレプリカにおいて pg_catalog などのログデータが削除されデータベース容量が少なくなっている可能性があることが判明いたしました。

つきましては、より詳細な調査について Google による調査を並行して実施依頼いたしますので、以下の情報についてご教示いただけますでしょうか。

該当する Database Migration Service 並びに Cloud SQL が属するプロジェクト ID は本ケース起票時に連携いただいた umail-254601 (プロジェクト名 dev-umail )でしょうか
添付いただいている Cloud SQL 画面のスクリーンショットは以下が対象インスタンスの認識でよろしいでしょうか
- レプリケーション元インスタンス ID: dev-sql
- レプリケーション先インスタンス ID: test3-sql-master (リードレプリカ test3-sql が付随)

ご不便おかけしている中大変恐縮でございますが、ご確認よろしくお願いいたします。

2024-08-23 Incoming¶

高井様

お世話になっております、鈴木です。

調査内容の状況連絡ありがとうございます。

・該当する Database Migration Service 並びに Cloud SQL が属するプロジェクト ID は本ケース起票時に連携いただいた umail-254601 (プロジェクト名 dev-umail )でしょうか => はい、こちらはその認識であっております。

・添付いただいている Cloud SQL 画面のスクリーンショットは以下が対象インスタンスの認識でよろしいでしょうか => はい、こちらもあっております。ただ、大変申し訳ございませんが、test3-sql-masteとtest3-sqlについては誤って削除してしまったようで、現在は残っていない状況となっております。

また、DMSについて追加で質問をさせて下さい。上記とは別のプロジェクト(stg-umail-64373)においてcloudsqlのインスタンスstg-sqlに対してDMSを用いたデータベース移行ジョブを作成したのですが、下記の様なエラーが出てしまいジョブ作成を完了することができませんでした。

The extensions installed on the source database are either not supported or having unsupported versions.
database django has unsupported extensions installed: amcheck_next; database postgres has unsupported extensions installed: amcheck_next

こちらについて解決方法がわからないため、お手数ですが何かわかることがあれば教えていただければと思います。

よろしくお願い致します。

2024-08-27 Sent¶

株式会社ヘルスベイシス鈴木様

=> はい、こちらもあっております。ただ、大変申し訳ございませんが、test3-sql-masteとtest3-sqlについては誤って削除してしまったようで、現在は残っていない状況となっております。

大変恐れ入りますが、削除済みのインスタンスについての調査はできかねてしまいますこと、ご理解賜わりますようお願い申し上げます。

上記とは別のプロジェクト(stg-umail-64373)においてcloudsqlのインスタンスstg-sqlに対してDMSを用いたデータベース移行ジョブを作成したのですが、下記の様なエラーが出てしまいジョブ作成を完了することができませんでした。

こちらについては独自に定義している amcheck_next という PostgreSQL 拡張機能が移行できない旨のエラーメッセージとお見受けしております。移行元インスタンスの django データベースにて当該の拡張機能が有効になっているが、移行先の Cloud SQL ではサポートされていない拡張機能であるためエラーが表示されている状況かと存じます。こちらにつきましてもご案内できる内容が限られており恐れ入りますが、Cloud SQL でサポートされている PostgreSQL の拡張機能の一覧[1]を添付いたしますので、参考にいただければ幸いです。

[1] Cloud SQL でサポートされている PostgreSQL 拡張機能 - PostgreSQL の拡張機能を構成する (Cloud SQL for PostgreSQL 公式ドキュメント) https://cloud.google.com/sql/docs/postgres/extensions?hl=ja#postgresql-extensions-supported-by-cloud-sql

2024-08-29 Incoming¶

高井様

ありがとうございます。

amcheck_nextについて、下記の記事を見つけました。 https://cloud.google.com/sql/docs/postgres/find-fix-inconsistent-indexes?hl=ja

postgres9.6ではamcheck_next、それ以降のバージョンではamcheckをインストールすると記載あります。

これについて質問なのですが、・この機能が有効化されたのがいつであるか、誰によって実行されたかを調べる方法はありますか？・この機能が有効になっている限り、DMSを用いて9.6 -> 13への移行は実施することができないと言う認識であっていますか？また、その場合回避策などはありますでしょうか？

お手数おかけしてしまい申し訳ございませんが、ご確認をお願い致します。

2024-08-30 Sent¶

株式会社ヘルスベイシス鈴木様

ご確認いただきありがとうございます。追加でお問い合わせいただいた内容につきまして、現在弊社にて内容を確認しております。

お待たせしており恐れ入りますが、ご案内まで少々お時間いただけますと幸いです。引き続きよろしくお願いいたします。

2024-09-03 Sent¶

株式会社ヘルスベイシス鈴木様

この機能が有効化されたのがいつであるか、誰によって実行されたかを調べる方法はありますか？

Cloud SQL のデータアクセス監査ログ[1]が有効であれば確認可能となっております。

データアクセス監査ログはデフォルトで無効になっており、明示的に有効にしない限り書き込まれません（例外は BigQuery のデータアクセス監査ログで、これは無効にすることができません）。

ただし、上記(公式ドキュメントより引用[2])にございますようにデフォルトでは無効となっておりますため、拡張機能が有効な時点から有効になっている必要がございます。

[1] 監査ログ (Cloud SQL for PostgreSQL 公式ドキュメント) https://cloud.google.com/sql/docs/postgres/audit-logging?hl=ja

[2] 監査ロギングの有効化 - 監査ログ (Cloud SQL for PostgreSQL 公式ドキュメント) https://cloud.google.com/sql/docs/postgres/audit-logging?hl=ja#enabling_audit_logging

この機能が有効になっている限り、DMSを用いて9.6 -> 13への移行は実施することができないと言う認識であっていますか？また、その場合回避策などはありますでしょうか？

ご認識に相違ございません。現在、回避策について弊社にて確認しております。お待たせしており恐縮ですが、今しばらくお待ちいただけますようお願いいたします。

引き続きよろしくお願いいたします。

2024-09-06 Sent¶

株式会社ヘルスベイシス鈴木様

お世話になっております、株式会社G-genサポートの高井です。ご案内にお時間いただいており恐れ入ります。保留となっておりました件について下記にご案内いたします。

この機能が有効になっている限り、DMSを用いて9.6 -> 13への移行は実施することができないと言う認識であっていますか？また、その場合回避策などはありますでしょうか？

当サポートにて検証・調査いたしましたが、こちらの DMS を使用した回避策について情報が確認できなかったため、ご案内できかねる状況でございます。つきましては、代替案といたしまして直接の移行ではございませんが手動でバックアップ・復旧する方法を下記にご案内いたしますので、検討いただけますと幸いです。

移行元インスタンスからバックアップを取得し PostgreSQL 9.6 の新規インスタンスとして復元
上記によって複製されたインスタンスにて拡張機能 amcheck_next を無効にしテストなどを実施
PostgreSQL 13 へのアップグレード
1. (問題ない場合) 複製されたインスタンスから Database Migration Service を使用し移行を実施
2. (エラーが発生する場合) 一度 amcheck_next 拡張を無効化した状態で Postgres 13 の新規インスタンスを作成し手動でリストア実施、再度 PostgreSQL 13側インスタンスにて amcheck 拡張を有効化

2024-09-10 Incoming¶

高井様

確認と代替案のご提示ありがとうございます、承知致しました。

Postgres 13 の新規インスタンスを作成し手動でリストア実施こちらは9.6のインスタンスで取得したバックアップを13のインスタンスに投入するイメージであっておりますでしょうか？

また追加で質問させていただきたいのですが、 Potgresの延長サポートについて具体的な料金が公開されるのはいつ頃になりそうか分かりますでしょうか？

2024-09-12 Sent¶

株式会社ヘルスベイシス鈴木様

こちらは9.6のインスタンスで取得したバックアップを13のインスタンスに投入するイメージであっておりますでしょうか？

概ねご認識どおりでございます。一度 PostgreSQL 9.6 のインスタンスにて拡張機能を無効化いただき、手動にて PostgreSQL 13 のインスタンスへ移行を実施するような手順でございます。

Potgresの延長サポートについて具体的な料金が公開されるのはいつ頃になりそうか分かりますでしょうか？

こちらにつきましては英語版の料金ページ[1]に記載がございます。東京リージョン(asia-northeast1)ですと、以下のようになっております。

HA 構成でない場合: $0.091 (1,2年目), $0.182 (3年目) / vCPU / 時間
HA 構成の場合: $0.182 (1,2年目), $0.364 (3年目) / vCPU / 時間