このトピックでは、ApsaraDB RDS for MySQL インスタンスへの接続に関する問題を解決する方法について説明します。
ワークロードを構築およびデバッグする際に、ApsaraDB RDS for MySQL インスタンスに接続できない場合があります。一般的な原因には、ネットワークタイプの不一致や IP アドレスホワイトリストの誤った設定などがあります。このトピックでは、これらの原因とその解決策について説明します。
ネットワークタイプの不一致
Elastic Compute Service (ECS) インスタンスが VPC 内にあり、ApsaraDB RDS for MySQL インスタンスがクラシックネットワーク内にある場合
解決策 1 (推奨)：ApsaraDB RDS for MySQL インスタンスのネットワークタイプをクラシックネットワークから VPC に切り替えます。詳細については、「ApsaraDB RDS インスタンスのネットワークタイプの変更」をご参照ください。
説明切り替え後、両方のインスタンスが内部ネットワーク経由で通信するには、同じ VPC 内に存在する必要があります。
解決策 2：クラシックネットワーク内に新しい ECS インスタンスを購入します。ECS インスタンスを VPC からクラシックネットワークに移行することはできません。VPC はクラシックネットワークよりも高いセキュリティを提供するため、VPC の使用を推奨します。
解決策 3：ECS インスタンスからパブリックエンドポイントを使用して RDS インスタンスに接続します。この方法は、パフォーマンス、セキュリティ、安定性が劣ります。
ECS インスタンスがクラシックネットワーク内にあり、ApsaraDB RDS for MySQL インスタンスが VPC 内にある場合
解決策 1 (推奨)：ECS インスタンスをクラシックネットワークから VPC に移行します。
説明移行後、両方のインスタンスが内部ネットワーク経由で通信するには、同じ VPC 内に存在する必要があります。
解決策 2：RDS インスタンスのネットワークタイプを VPC からクラシックネットワークに切り替えます。VPC はクラシックネットワークよりも高いセキュリティを提供するため、VPC の使用を推奨します。
解決策 3：ClassicLink を使用して、クラシックネットワーク内の ECS インスタンスを内部ネットワーク経由で VPC リソースに接続します。
解決策 4：ECS インスタンスからパブリックエンドポイントを使用して RDS インスタンスに接続します。この方法は、パフォーマンス、セキュリティ、安定性が劣ります。
異なる VPC
VPC は Alibaba Cloud 上に構築された論理的に分離されたネットワーク環境です。内部ネットワーク経由で通信するには、ECS インスタンスと ApsaraDB RDS for MySQL インスタンスが同じ VPC 内に存在する必要があります。
解決策 1 (推奨)：RDS インスタンスと ECS インスタンスを同じ VPC に移動します。
これを行うには、RDS インスタンスの VPC を変更するか、ECS インスタンスの VPC を変更することができます。
解決策 2：Cloud Enterprise Network (CEN) を使用して、2 つの VPC 間に接続を確立します。
解決策 3：インターネット経由で接続します。この方法は、パフォーマンス、セキュリティ、安定性が劣ります。
異なるリージョン
パブリック接続：RDS インスタンスの パブリックエンドポイント を使用して、リージョン間またはアカウント間でインターネット経由で接続します。RDS インスタンスのインバウンドおよびアウトバウンドのインターネットトラフィックに対しては課金されません。
プライベート接続：デフォルトでは、ECS インスタンスと RDS インスタンスが異なるリージョンにあるか、異なるアカウントに属している場合、VPC が分離されているため、内部ネットワーク経由で接続することはできません。ただし、VPC ピアリング接続または Cloud Enterprise Network (CEN) を使用して 2 つの VPC を接続し、ECS インスタンスがリージョン間またはアカウント間で RDS インスタンスにアクセスできるようにすることができます。
VPC ピアリング接続：この機能は、リージョン間およびアカウント間の VPC 接続をサポートします。コスト効率は高いですが、設定が比較的複雑なため、少数の VPC を持つ単純なシナリオに適しています。
CEN：この製品は、リージョン間およびアカウント間の VPC 接続をサポートします。設定は簡単ですが、より高価なため、複数の VPC を持つ複雑なシナリオに適しています。
IP アドレスホワイトリストの誤った設定
デフォルトの IP アドレスホワイトリストには、アドレス 127.0.0.1 のみが含まれています。このアドレスは、いかなるデバイスからの RDS インスタンスへのアクセスも防ぎます。クライアントの IP アドレスをホワイトリストに追加する必要があります。詳細については、「ApsaraDB RDS for MySQL インスタンスの IP アドレスホワイトリストの設定」をご参照ください。
ホワイトリストが 0.0.0.0 に設定されています。正しい形式は 0.0.0.0/0 です。
重要IP アドレス 0.0.0.0/0 は、あらゆるデバイスからのアクセスを許可します。この設定は注意して使用してください。
高セキュリティホワイトリストモード を有効にした場合は、以下を確認してください：
VPC 内のインスタンスの内部エンドポイントを使用している場合は、ECS インスタンスのプライベート IP アドレスが VPC ホワイトリストグループに追加されていることを確認してください。
クラシックネットワーク内のインスタンスの内部エンドポイントを使用している場合は、ECS インスタンスのプライベート IP アドレスがクラシックネットワークホワイトリストグループに追加されていることを確認してください。
インターネット経由で接続している場合は、デバイスのパブリック IP アドレスがクラシックネットワークホワイトリストグループに追加されていることを確認してください。VPC ホワイトリストグループはパブリック接続には適用されません。
ホワイトリストに追加したパブリック IP アドレスが、デバイスの実際の送信元 IP アドレスではない可能性があります。考えられる理由として、以下が挙げられます：
パブリック IP アドレスは動的であり、変更される可能性があります。
パブリック IP アドレスを照会するために使用したツールまたはウェブサイトが、不正確な結果を返すことがあります。
名前解決の失敗またはエラー
DNS サーバーの障害やネットワークインターフェイスカード (NIC) の設定変更により、名前解決が失敗したり、不正な IP アドレスが返されたりすることがあります。ping コマンドと telnet コマンドを使用して、RDS インスタンスへの接続をテストします。
ping <domain_name>
telnet <domain_name> <port_number>
例：
# ping 成功の例
[root@xxx ~]# ping rm-xxx.mysql.rds.aliyuncs.com
PING rm-xxx.mysql.rds.aliyuncs.com (192.168.0.176) 56(84) bytes of data.
64 bytes from 192.168.0.176 (192.168.0.176): icmp_seq=1 ttl=64 time=0.151 ms
64 bytes from 192.168.0.176 (192.168.0.176): icmp_seq=2 ttl=64 time=0.141 ms
64 bytes from 192.168.0.176 (192.168.0.176): icmp_seq=3 ttl=64 time=0.107 ms
64 bytes from 192.168.0.176 (192.168.0.176): icmp_seq=4 ttl=64 time=0.108 ms
# ping 失敗の例
[root@izbpxxx ~]# ping rm-bp1xxx.mysql.rds.aliyuncs.com
ping: rm-bp1xxx.mysql.rds.aliyuncs.com: Name or service not known
[root@izbpxxx ~]## telnet 接続成功の例
[root@xxx ~]# telnet rm-xxx.mysql.rds.aliyuncs.com 3306
Trying 192.168.0.176...
Connected to rm-xxx.mysql.rds.aliyuncs.com.
Escape character is '^]'.
N
5.6.16-logtEkkVNd-0!)\}\4/,/GXfu<mysql_native_password
# telnet 接続失敗の例 (名前解決の失敗)
[root@izbpxxx ~]# telnet rm-bp1xxx.mysql.rds.aliyuncs.com 3306
telnet: rm-bp1xxx.mysql.rds.aliyuncs.com: Name or service not known
rm-bp1xxx.mysql.rds.aliyuncs.com: Host name lookup failure
[root@izbpxxx ~]#テストに失敗した場合は、NIC 設定ファイルを変更して問題を解決します：
NIC 設定ファイルを変更します：
vi /etc/sysconfig/network-scripts/<nic_configuration_file_name>説明<nic_configuration_file_name> は ECS サーバーで使用される NIC の設定ファイル名です。
ifconfigコマンドを実行して、ファイル名を確認します。デフォルトはifcfg-eth0です。ファイルの末尾に次の行を追加します：
DNS1=100.100.XX.XX DNS2=100.100.XX.XX説明DNS1 と DNS2 が既に設定されている場合は、上記のように IP アドレスを更新してください。
DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes DNS1=100.100.2.136 DNS2=100.100.2.138次のコマンドを実行して、ネットワークサービスを再起動します：
sudo systemctl restart network次のコマンドを実行して、変更が成功したかどうかを確認します：
cat /etc/resolv.conf[root@xxx ~]# cat /etc/resolv.conf options timeout:2 attempts:3 rotate single-request-reopen : generated_by /usr/sbin/dhclient-script nameserver 100.100.2.136 nameserver 100.100.2.138 [root@xxx ~]#
ポート接続性のテスト
名前解決が正常に機能している場合は、telnet コマンドを使用して RDS インスタンスへのポートへの接続をテストします。
telnet <RDS_endpoint> <port_number>たとえば、ApsaraDB RDS for MySQL インスタンスのデフォルトポート 3306 をテストします：
telnet rm-xxxx.mysql.rds.aliyuncs.com 3306出力に
Connected toとEscape character isが含まれている場合、ポートがネットワークレイヤーでアクセス可能であることを意味します。Connection timed outエラーは、ネットワークに到達できないか、ファイアウォールによってブロックされていることを示します。次の設定を確認してください：RDS の IP アドレスホワイトリストにクライアントの IP アドレスが含まれていることを確認してください。
セキュリティグループのルールが対応するポートでのトラフィックを許可していることを確認してください。
クライアントと RDS インスタンスが同じ VPC 内にあることを確認してください。内部エンドポイントは、その VPC 内からのみアクセス可能です。
Connection refusedエラーは、ポートがリッスンされていないことを示します。RDS インスタンスの実行ステータスとポート設定を確認してください。
ping コマンドと telnet コマンドの両方が正常に実行されても、アプリケーションで依然として接続タイムアウトが発生する場合、問題はネットワークレイヤーではなくアプリケーションレイヤーにあります。tcpdump を使用してパケットをキャプチャし、TCP 3 ウェイハンドシェイクと 4 ウェイハンドシェイクを分析して、タイムアウトの根本原因を特定します。
tcpdump -i eth0 host <RDS_endpoint> -w rds_capture.pcapパケットキャプチャファイルを分析します：SYN パケットへの応答がない場合は、ネットワークに到達できないか、ブロックされていることを示します。3 ウェイハンドシェイクが成功した後にデータ交換がない場合は、アプリケーションレベルの異常を示します。
インスタンスが「ネットワーク接続を作成中」の状態でスタック
コンソールで、[タスク] ページに移動します。タスクを見つけ、[再試行] または [切り替え時間の変更] をクリックします。詳細については、「タスクセンターの使用」をご参照ください。
FIN パケットへの無応答による読み取りタイムアウト
VPN や専用線などの中間ネットワークを介して ApsaraDB RDS for MySQL インスタンスに接続すると、最初は接続が機能しても、その後タイムアウトすることがあります。これは、クライアントが FIN パケットを送信した後にサーバーが応答しない場合に発生する可能性があります。
この問題をトラブルシューティングするには、次の手順に従います：
ApsaraDB RDS コンソールで、インスタンス詳細ページに移動します。左側のナビゲーションペインで、パラメーターの設定 をクリックし、
wait_timeoutおよびinteractive_timeoutパラメーターの値を確認します。ApsaraDB RDS for MySQL では、wait_timeoutのデフォルト値は 86,400 秒です。このパラメーターが低い値に設定されている場合、サーバーはアイドル接続を早期に切断します。VPN や専用線などの中間ネットワークリンクで、パケット損失や高遅延がないか確認してください。
telnet <RDS_endpoint> <port_number>コマンドを使用して、RDS インスタンスへのポートへの接続をテストし、ネットワークレイヤーでのアクセス可能性を確認します。tcpdumpまたは Wireshark を使用して、クライアントとサーバーの両方で同時にパケットをキャプチャします。TCP の FIN/RST パケットのシーケンスを分析して、切断がネットワークトランスポートレイヤーで発生したのか、データベースアプリケーションレイヤーで発生したのかを判断します。
ログを使用したタイムアウトのトラブルシューティング
RDS インスタンスのエラーログと低速ログを確認して、接続タイムアウトの問題を調査します。
ApsaraDB RDS コンソールにログインします。インスタンス ページで、対象のインスタンスを見つけ、その管理ページに移動します。左側のナビゲーションペインで、ログ管理 > エラーログ を選択します。
エラーログで
Host is blocked、connect timeout、Aborted connectionなどのレコードを確認し、接続失敗の理由を特定します。スロークエリログの詳細を選択し、新しい接続をブロックしている可能性のある、長時間実行されているスロークエリがないか確認します。
インスタンスの
wait_timeoutおよびinteractive_timeoutパラメーター設定を確認し、タイムアウトによってアイドル状態の接続が自動的に切断されているかどうかを判断します。