Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。 # Amazon Redshift での接続の問題のトラブルシューティング SQL クライアントツールからクラスターへの接続で問題が発生した場合は、問題を絞り込むために確認できるいくつかの点があります。SSL またはサーバー証明書を使用している場合、接続の問題をトラブルシューティングしているときにまずこの複雑さを排除します。その後、解決策を見つけたらもう一度これを追加します。詳細については、「[接続のセキュリティオプションを設定する](connecting-ssl-support.md)」を参照してください。 アプリケーションに影響を与える可能性のある Amazon Redshift 機能の動作の変更については、「[Amazon Redshift の動作の変更](behavior-changes.md)」を参照してください。 **重要** Amazon Redshift は、SSL 証明書の管理方法を変更しました。SSL 接続で問題が発生した場合は、現在の信頼ルート CA 証明書を更新する必要があります。詳細については、「[SSL 接続用 ACM 証明書への移行](connecting-transitioning-to-acm-certs.md)」を参照してください。 次のセクションに、接続の問題のサンプルエラーメッセージと考えられる解決策を示します。SQL クライアントツールによってエラーメッセージが異なるため、このリストは完全ではありませんが、問題のトラブルシューティングに適した開始点です。 ## Amazon EC2 以外からの接続と、ファイアウォールのタイムアウトの問題 COPY コマンドなどの長いクエリを実行すると、データベースへのクライアント接続がハングまたはタイムアウトしているように見えます。この場合、Amazon Redshift コンソールにはクエリが完了したと表示されますが、クライアントツール自体はまだクエリを実行しているように見えることがあります。接続がいつ停止したかに応じて、クエリの結果がないか、不完全になる可能性があります。 ### 考えられる解決策 考えられる解決策 この問題は、Amazon EC2 インスタンス以外のマシンから Amazon Redshift に接続するときに発生します。この場合、アイドル状態の接続は、一定期間非アクティブになった後、ファイアウォールなどの中間ネットワークコンポーネントによって終了します。このような動作は、Virtual Private Network (VPN) やローカルネットワークからログインした場合によく発生します。 このようなタイムアウトを回避するために以下の変更を行うことを推奨します。 + クライアントシステムで TCP/IP タイムアウト値を大きく設定します。この変更は、クラスターへの接続に使用しているコンピュータで行います。クライアントやネットワークに対してタイムアウト期間を調整する必要があります。詳細については、「[TCP/IP タイムアウト設定を変更する](#connecting-firewall-guidance.change-tcpip-settings)」を参照してください。 + 必要に応じて、DSN レベルでキープアライブの動作を設定します。詳細については、「[DSN のタイムアウト設定を変更する](#connecting-firewall-guidance.change-dsn-settings)」を参照してください。 ### TCP/IP タイムアウト設定を変更する TCP/IP タイムアウト設定を変更する TCP/IP タイムアウト設定を変更するには、クラスターへの接続に使用するオペレーティングシステムに応じて、タイムアウト設定を設定します。 + Linux — クライアントが Linux で動作している場合は、次のコマンドをルートユーザーとして実行し、現在のセッションのタイムアウト設定を変更します。 ``` /sbin/sysctl -w net.ipv4.tcp_keepalive_time=200 net.ipv4.tcp_keepalive_intvl=200 net.ipv4.tcp_keepalive_probes=5 ``` 設定を保持するには、次の値を使ってファイル `/etc/sysctl.conf` を作成または変更し、システムを再起動します。 ``` net.ipv4.tcp_keepalive_time=200 net.ipv4.tcp_keepalive_intvl=200 net.ipv4.tcp_keepalive_probes=5 ``` + Windows — クライアントが Windows で動作している場合、HKEY\$1LOCAL\$1MACHINE\$1SYSTEM\$1CurrentControlSet\$1Services\$1Tcpip\$1Parameters\$1 にある次のレジストリ設定の値を編集します。 + KeepAliveTime: 30000 + KeepAliveInterval: 1000 + TcpMaxDataRetransmissions: 10 これらの設定は DWORD のデータの種類を使用します。これらがレジストリパスに存在しない場合、設定を作成し、これらの推奨値を指定できます。Windows レジストリの編集の詳細については、Windows のドキュメントを参照してください。 これらの値を設定したら、コンピュータを再起動して変更を有効にします。 + Mac — クライアントが Mac で動作している場合は、次のコマンドを実行して現在のセッションのタイムアウト設定を変更します。 ``` sudo sysctl net.inet.tcp.keepintvl=200000 sudo sysctl net.inet.tcp.keepidle=200000 sudo sysctl net.inet.tcp.keepinit=200000 sudo sysctl net.inet.tcp.always_keepalive=1 ``` 設定を保持するには、次の値を使ってファイル `/etc/sysctl.conf` を作成または変更します。 ``` net.inet.tcp.keepidle=200000 net.inet.tcp.keepintvl=200000 net.inet.tcp.keepinit=200000 net.inet.tcp.always_keepalive=1 ``` コンピュータを再起動し、次のコマンドを実行して値が設定されていることを確認します。 ``` sysctl net.inet.tcp.keepidle sysctl net.inet.tcp.keepintvl sysctl net.inet.tcp.keepinit sysctl net.inet.tcp.always_keepalive ``` ### DSN のタイムアウト設定を変更する DSN のタイムアウト設定を変更する 必要に応じて、DSN レベルでキープアライブの動作を設定できます。これを行うには、odbc.ini ファイルで以下のパラメータを追加または変更します。 **KeepAlivesCount** 接続が切断されていると見なされる前に失うことが許容される TCP キープアライブパケットの数。 **KeepAlivesIdle** ドライバーが TCP キープアライブパケットを送信する前にアイドル状態である秒数。 **KeepAlivesInterval** TCP キープアライブを再送信する間隔の秒数。 これらのパラメータがない場合、または値が 0 である場合、システムは指定されている TCP/IP キープアライブパラメータを使用して DSN キープアライブの動作を決定します。Windows では、`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\`のレジストリに TCP/IP パラメータ があります。Linux および macOS では、TCP/IP のパラメータは sysctl.conf ファイルにあります。 ## 接続が拒否または失敗する 接続が拒否された場合や失敗した場合、次のいずれかと同様のエラーが表示されることがあります。 + "Failed to establish a connection to **." + "Could not connect to server: Connection timed out。Is the server running on host *''* and accepting TCP/IP connections on port *''*?" + "Connection refused。Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections." ### 考えられる解決策 考えられる解決策 通常、接続の確立に失敗したことを示すエラーメッセージが表示された場合は、クラスターにアクセスするためのアクセス許可の問題またはクラスターへのトラフィックネットワークの問題を示しています。 クラスターが属するネットワークの外部にあるクライアントツールからクラスターに接続するには、クラスターのセキュリティグループにインバウンドルールを追加します。ルールの設定は、Amazon Redshift クラスターを仮想プライベートクラウド (VPC) で作成しているかどうかによって異なります。 + Amazon VPC に基づく仮想プライベートクラウド (VPC) で Amazon Redshift クラスターを作成した場合は、Amazon VPC で クライアント CIDR/IP アドレスを指定するインバウンドルールを VPC セキュリティグループに追加します。クラスターの VPC セキュリティグループの設定とパブリックにアクセス可能なオプションの詳細については、「[VPC での Redshift リソース](managing-clusters-vpc.md)」を参照してください。 + VPC の外で Amazon Redshift クラスターを作成した場合は、Amazon Redshift のクラスターセキュリティグループにクライアント CIDR/IP アドレスを追加します。クラスターセキュリティグループの設定の詳細については、「[Amazon Redshift セキュリティグループ](security-network-isolation.md#working-with-security-groups)」を参照してください。 Amazon EC2 インスタンスで実行するクライアントツールからクラスターに接続する場合も、インバウンドルールを追加します。この場合は、クラスターセキュリティグループにルールを追加します。ルールでは、クライアントツールの Amazon EC2 インスタンスに関連付けられた Amazon EC2 セキュリティグループを指定する必要があります。 場合によっては、ファイアウォールなど、クライアントとサーバーの間にレイヤーが存在することがあります。このような場合は、ファイアウォールがクラスター用に設定したポート経由のインバウンド接続を受け入れることを確認します。 ## クライアントおよびドライバーに互換性がない クライアントとドライバーに互換性がない場合、「指定された DSN にドライバーとアプリケーション間のアーキテクチャの不一致が含まれている」というエラーが表示されることがあります。 ### 考えられる解決策 考えられる解決策 接続を試みてアーキテクチャの不一致に関するエラーが発生する場合、クライアントツールとドライバーに互換性がないことを意味します。これは、システムのアーキテクチャが一致しないために発生します。例えば、32 ビットクライアントツールがあるが、ドライバーの 64 ビットバージョンをインストールした場合にこれが発生することがあります。64 ビットクライアントツールが 32 ビットドライバーを使用できることはありますが、64 ビットドライバーで 32 ビットアプリケーションを使用することはできません。ドライバーとクライアントツールが同じバージョンのシステムアーキテクチャを使用していることを確認します。 ## クエリがハングして、クラスターに達しない場合がある クエリが完了しないという問題に直面します。クエリは実行されますが、SQL クライアント ツールでハングします。クエリは、システムテーブルや Amazon Redshift コンソールなどでクラスターに表示されない場合があります。 ### 考えられる解決策 考えられる解決策 この問題は、パケットドロップが原因で発生する可能性があります。この場合、2 つのインターネットプロトコル (IP) ホスト間のネットワークパスの最大伝送ユニット (MTU) サイズに差があります。MTU サイズにより、ネットワーク接続を介して 1 つのイーサネットフレームで転送できるパケットの最大サイズ (バイト単位) が決まります。AWS では、一部の Amazon EC2 インスタンスタイプが 1500 MTU (Ethernet v2 フレーム) をサポートしており、その他のインスタンスタイプは 9001 MTU (TCP/IP ジャンボフレーム) をサポートしています。 MTU サイズの違いで発生する問題を防ぐために、次のいずれかを行うことをお勧めします: + ご使用のクラスターが EC2-VPC プラットフォームを使用している場合、`Destination Unreachable` を返すインバウンドカスタム Internet Control Message Protocol (ICMP) ルールによって Amazon VPC セキュリティグループを設定します。このルールは、送信側ホストがネットワークパスに沿って最低の MTU サイズを使用するように指示します。この方法の詳細については、「[セキュリティグループを設定して ICMP の「Destination Unreachable」を許可する](#configure-custom-icmp)」を参照してください。 + ご使用のクラスターが EC2-Classic プラットフォームを使用しているか、ICMP インバウンドルールを許可できない場合、TCP/IP ジャンボフレームを無効にして、Ethernet v2 フレームを使用します。この方法の詳細については、「[インスタンスの MTU の設定](#set-mtu)」を参照してください。 ### セキュリティグループを設定して ICMP の「Destination Unreachable」を許可する 2 つのホスト間のネットワークで MTU サイズに違いがある場合、ネットワーク設定がパス MTU 検出 (PMTUD) をブロックしないことをまず確認します。PMTUD は、受信側ホストが次の ICMP メッセージで送信側ホストに応答するのを可能にします: `Destination Unreachable: fragmentation needed and DF set (ICMP Type 3, Code 4)` このメッセージは、送信側ホストがネットワークパスに沿って最低の MTU サイズを使用してリクエストを再送信するように指示します。このネゴシエーションがないと、リクエストが大きすぎて受信側ホストが受け取れないため、パケットドロップが発生する可能性があります。この ICMP メッセージの詳細については、*インターネット技術標準化委員会 (IETF)* のウェブサイトから [RFC792](http://tools.ietf.org/html/rfc792) を参照してください。 この ICMP インバウンドルールを Amazon VPC セキュリティグループのために明示的に設定しない場合、PMTUD はブロックされます。AWS では、セキュリティグループは、インバウンドおよびアウトバウンドトラフィックのルールをインスタンスに指定する仮想ファイアウォールです。Amazon Redshift クラスターセキュリティグループの詳細については、[Amazon Redshift セキュリティグループ](security-network-isolation.md#working-with-security-groups)を参照してください。EC2-VPC プラットフォームを使用するクラスターでは、Amazon Redshift はクラスターへのトラフィックを許可または拒否するために VPC セキュリティグループを使用します。デフォルトでは、セキュリティグループはロックされており、すべてのインバウンドトラフィックを拒否します。EC2-Classic インスタンスまたは EC2-VPC インスタンスのインバウンドルールとアウトバウンドルールを設定する方法については、「Amazon EC2 ユーザーガイド」の「[EC2-Classic と VPC 内のインスタンスの違い](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-classic-platform.html#ec2_classic_platform)」を参照してください。** VPC セキュリティグループにルールを追加する方法については、「[VPC セキュリティグループ](managing-vpc-security-groups.md)」を参照してください。このルールに必要な特定の PMTUD 設定の詳細については、「*Amazon EC2 ユーザーガイド*」の「[パス MTU 検出](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#path_mtu_discovery)」を参照してください。 ### インスタンスの MTU の設定 クラスターで EC2-Classic プラットフォームが使用されている場合や、インバウンドトラフィックにカスタム ICMP ルールを許可できない場合があります。このような場合、Amazon Redshift クラスターに接続する EC2 インスタンスのネットワークインターフェイス (NIC) で MTU を 1500 に調整することをお勧めします。この調整によって TCP/IP ジャンボフレームが無効になるため、同じパケットサイズが一貫して接続に使用されるようになります。ただし、このオプションでは、Amazon Redshift への接続だけでなく、インスタンス全体の最大ネットワークスループットを減らすことに注意してください。詳細については、次の手順を参照してください。 **Microsoft Windows のオペレーティング システムで MTU を設定する** クライアントが Microsoft Windows オペレーティングシステムで動作している場合、`netsh`コマンドを使用してイーサネットアダプターの MTU 値を確認し、設定できます。 1. 現在の MTU 値を調べるには、次のコマンドを実行します。 ``` netsh interface ipv4 show subinterfaces ``` 1. 出力で `MTU` アダプタの `Ethernet` の値を確認します。 1. 値が `1500` ではない場合、次のコマンドを実行して設定します。 ``` netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent ``` この値を設定したら、コンピュータを再起動して変更を有効にします。 **Linux オペレーティング システムで MTU を設定する** クライアントが Linux オペレーティング システムで動作している場合、`ip`コマンドを使用して MTU 値を確認し、設定できます。 1. 現在の MTU 値を調べるには、次のコマンドを実行します。 ``` $ ip link show eth0 ``` 1. 出力で次の `mtu` の値を確認します。 1. 値が `1500` ではない場合、次のコマンドを実行して設定します。 ``` $ sudo ip link set dev eth0 mtu 1500 ``` **Mac オペレーティング システムで MTU を設定する** + `How to change the MTU for troubleshooting purposes` については macOS サポートサイトの指示に従ってください。詳細については、[サポートサイト](https://support.apple.com)を検索してください。 ## JDBC フェッチサイズパラメータの設定 デフォルトでは、Redshift JDBC ドライバーはリングバッファを使用してメモリを効率的に管理し、メモリ不足エラーを防止します。フェッチサイズパラメータは、リングバッファが明示的に無効になっている場合にのみ適用できます。詳細については、「[link](https://docs.aws.amazon.com/redshift/latest/mgmt/jdbc20-configuration-options.html#jdbc20-enablefetchringbuffer-option)」を参照してください。この設定では、各バッチで取得される行数を制御するようにフェッチサイズを設定する必要があります。 次の場合は、フェッチサイズパラメータを使用します。 + 行ベースのバッチ処理をきめ細かく制御する必要がある + 従来のフェッチサイズ動作を必要とするレガシーアプリケーションを使用している リングバッファが無効な場合、デフォルトでは、JDBC ドライバーはクエリに対して一度にすべての結果を収集します。大きな結果セットを返すクエリは、過剰なメモリを消費する可能性があります。一度にすべてではなくバッチで結果セットを取得するには、アプリケーションで JDBC フェッチサイズパラメータを設定します。 **注記** フェッチサイズは ODBC ではサポートされません。 最適なパフォーマンスのためには、メモリ不足エラーが発生しない最大の値にフェッチサイズを設定します。フェッチサイズの値を低く設定すると、サーバートリップが増え、それにより実行時間が長くなります。サーバーは、クライアントが結果セット全体を取得するまで、WLM クエリスロットおよび関連メモリを含むリソースを予約します。そうでない場合、クエリはキャンセルされます。フェッチサイズを適切に調整すると、それらのリソースはより迅速に解放され、他のクエリに利用できるようになります。 **注記** 大きなデータセットを抽出する必要がある場合は、[UNLOAD](https://docs.aws.amazon.com/redshift/latest/dg/r_UNLOAD.html) ステートメントを使用してデータを Amazon S3 に転送することをお勧めします。UNLOAD を使用するときは、コンピューティングノードは並行してデータの転送を高速化します。 JDBC フェッチサイズパラメータの詳細については、PostgreSQL のドキュメントで「[Getting results based on a cursor](https://jdbc.postgresql.org/documentation/query/#getting-results-based-on-a-cursor)」を参照してください。