接続をデバッグする
移行元データベースと移行先データベース間の接続を設定しましたが、接続されていることを確認するにはどうすればよいですか？これらの間で通信が失敗した場合、何が問題でどこで問題が発生しているかをどのように確認できますか？
最も基本的なツールは ping と traceroute です。
Ping
Ping は、宛先（リモートホスト）が送信元から使用可能かどうかを判断する基本的なテストを行います。Ping は、ICMP Echo Request パケットをリモートホストに送信し、ICMP Echo Reply が返ってくることを想定しています。ping が正常に通らない場合、送信元から宛先へのルートはありません。ただし、成功した場合でも、パケットが宛先に到達できたという意味ではなく、一般的には、単にリモートホストに到達できるというだけです。
ping によってホストが稼働中で応答することは確認できますが、信頼性は保証されません。一部のネットワーク プロバイダでは、セキュリティ保護のため ICMP をブロックしているため、接続のデバッグは難しい場合があります。
traceroute
Traceroute は、あるホストから別のホストへのネットワーク パケットの完全なルートをテストします。パケットが通過するすべてのステップ（「ホップ」）と、各ステップでの所要時間が表示されます。パケットが宛先まで到達できない場合、traceroute は完了せず、後ろには連続したアスタリスクが続きます。この場合、途中で正常に到達した最後の IP アドレスを確認します。ここが接続の途切れた場所になります。
Traceroute は、タイムアウトする場合があります。また、経路中のゲートウェイがパケットをネクストホップに渡すように正しく構成されておらず、完了しない場合もあります。
traceroute が完了しなかった場合、停止した場所を特定できる可能性があります。traceroute の出力に表示された最後の IP アドレスを見つけて、ブラウザで who owns [IP_ADDRESS] を検索します。結果にアドレスの所有者が表示されないこともありますが、試してみる価値はあります。
mtr
mtr ツールは traceroute の形式で、ローカル プロセスの top コマンドと同じように動作し続けて継続的に更新されます。
ローカル IP アドレスを確認する
ホストのローカル アドレスがわからない場合は、ip -br address show コマンドを実行します。Linux では、ネットワーク インターフェース、インターフェースのステータス、ローカル IP、MAC アドレスが表示されます。例: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64。
あるいは、ipconfig や ifconfig を実行して、ネットワーク インターフェースのステータスを確認することもできます。
送信 IP アドレスを確認する
ソース データベースと宛先データベースが相互通信に使用する IP アドレス（送信 IP アドレス）がわからない場合は、次の手順を完了します。
Google Cloud コンソールで [SQL インスタンス] ページに移動します。
デバッグする移行ジョブに関連付けられているインスタンスの名前をクリックします。
[このインスタンスに接続する] ペインが表示されるまで下にスクロールします。このペインに、送信 IP アドレスが表示されます。
開いているローカルポート
ホストがリッスンしていると思われるポートを確認するには、ss -tunlp4 コマンドを実行します。これにより、開いているポートとリッスンしているポートがわかります。たとえば、動作している MySQL データベースがある場合は、ポート 3306 が開いており、リッスンしています。SSH の場合は、ポート 22 が表示されます。
すべてのローカルポート アクティビティ
すべてのローカルポート アクティビティを表示するには、netstat コマンドを使用します。たとえば、netstat -lt を使用すると、現在アクティブなポートがすべて表示されます。
telnet を使用してリモートホストに接続する
TCP を使用してリモートホストに接続できることを確認するには、telnet コマンドを実行します。Telnet は、指定された IP アドレスとポートに接続しようとします。
telnet 35.193.198.159 3306 と指定すると、ポート 3306 でインスタンスに telnet 接続できます。成功すると、次のように表示されます。
Trying 35.193.198.159...
Connected to 35.193.198.159.
。
失敗すると、試行を強制終了するまで telnet が応答しなくなります。
Trying 35.193.198.159...
^C.
。
Cloud Logging
Database Migration Service と Cloud SQL は、Cloud Logging を使用します。詳細については、Cloud Logging のドキュメントをご覧ください。また、Cloud SQL のサンプルクエリもご覧ください。ログを表示
Cloud SQL インスタンスと、Cloud VPN や Compute Engine インスタンスなどのその他の Google Cloudプロジェクトのログを表示できます。Cloud SQL インスタンスのログエントリのログを表示するには:コンソール
- [ログ エクスプローラ] に移動
- ページの上部で既存の Cloud SQL プロジェクトを選択します。
- クエリビルダーに以下のクエリを追加します。
- リソース: [Cloud SQL データベース] を選択します。ダイアログで、Cloud SQL インスタンスを選択します。
- ログ名: Cloud SQL セクションまでスクロールし、インスタンスに適したログファイルを選択します。例:
- cloudsql.googlapis.com/mysql-general.log
- cloudsql.googleapis.com/mysql.err
- 重大度: ログレベルを選択します。
- 時間範囲: プリセットを選択するか、カスタム範囲を作成します。
gcloud
gcloud logging コマンドを使用して、ログエントリを表示します。次の例では、PROJECT_ID を置き換えます。
limit フラグは、返されるエントリの最大数を示すオプションのパラメータです。
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/mysql-general.log" --limit=10
プライベート IP アドレス
プライベート IP アドレスを使用して Cloud SQL インスタンスへ接続すると、RFC 1918 アドレス範囲が自動的に承認されます。RFC 1918 以外のアドレス範囲は、Cloud SQL で認可済みネットワークとして構成される必要があります。また、RFC 1918 以外のルートをエクスポートするには、Cloud SQL へのネットワーク ピアリングを更新する必要もあります。例: gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
IP 範囲 172.17.0.0/16 は、Docker ブリッジ ネットワーク用に予約されています。この範囲内の IP アドレスで作成された Cloud SQL インスタンスはすべて到達不能になります。プライベート IP アドレスを使用して、この範囲内の IP アドレスから Cloud SQL インスタンスに接続することもできません。
VPN のトラブルシューティング
Google Cloud Cloud VPN のトラブルシューティングのページをご覧ください。
リバース SSH トンネルの問題のトラブルシューティング
SSH トンネリングは、SSH 接続上で通信を転送する方法です。リバース SSH トンネリングでは、SSH トンネルを設定できますが、トンネル接続を開始するのは宛先ネットワークです。これは、セキュリティ上の理由から独自のネットワークでポートを開きたくない場合に便利です。
設定しようとしているのは次のとおりです。 Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
次のことを前提としています。
Compute Engine VM bastion は Cloud SQL DB にアクセスできます。
source network bastion は source DB にアクセスできます（これは、Cloud SQL ネットワークを Compute Engine VM ネットワークにピアリングすることで実現されます）。
次に、source network bastion から Compute Engine VM bastion への SSH トンネルを設定します。これにより、受信接続が Compute Engine VM bastion のポートからトンネルを経由して source DB に転送されます。
上記のシナリオの各リンクが正しく設定されていないと、フロー全体が機能しなくなる可能性があります。各リンクを 1 つずつトラブルシューティングします。
source network bastion ---> source DB
- SSH を使用して source network bastion に接続します。ローカルマシンの場合は、ターミナルから接続します。
- 次のいずれかの方法で、ソース DB への接続をテストします。
telnet [source_db_host_or_ip] [source_db_port]- mysql パスワード プロンプト（5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnectionなど）が表示されることを想定[db_client] -h[source_db_host_or_ip] -P[source_db_port]- アクセスが拒否されることを想定（ERROR 1045 (28000): Access denied for user...など）
失敗した場合は、この踏み台からソース DB へのアクセスを有効にしたことを確認する必要があります。
Compute Engine VM bastion ---> source DB
- Compute Engine VM bastion に SSH 接続する（
gcloud compute ssh VM_INSTANCE_NAMEを使用） - 次のいずれかの方法で、ソース DB への接続をテストします。
telnet 127.0.0.1 [tunnel_port]- mysql パスワード プロンプト（5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnectionなど）が表示されます。[db_client] -h127.0.0.1 -P[tunnel_port]- アクセスが拒否されることを想定（ERROR 1045 (28000): Access denied for user...など）
失敗した場合は、トンネルが正しく稼働していることを確認する必要があります。sudo netstat -tupln を実行すると、この VM 上のすべてのリッスン プロセスが表示され、sshd listening on the tunnel_port が表示されます。
Cloud SQL DB ---> source DB
これは、Database Migration Service の testing the migration job でテストするのが最適です。失敗した場合は、Cloud SQL ネットワークと Compute Engine VM bastion ネットワーク間の VPC ピアリングまたはルーティングに問題があることを意味します。
ソース データベース サーバーのファイアウォールは、Cloud SQL の宛先インスタンスが IPConfiguration 設定の privateNetwork フィールドとして使用する VPC ネットワークのプライベート サービス接続に割り振られた内部 IP 範囲全体を許可するように構成する必要があります。
Console で内部 IP 範囲を確認するには:
Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
使用する VPC ネットワークを選択します。
[プライベート サービス接続] タブを選択します。
Cloud SQL インスタンスと Compute Engine VM インスタンス間のトラフィックも、Cloud VPN gateway プロジェクトの Cloud Logging コンソールで確認できます。Compute Engine VM のログで、Cloud SQL インスタンスからのトラフィックを探します。Cloud SQL インスタンスのログで、Compute Engine VM からのトラフィックを探します。