Beheben von Problemen mit Verbindungen in Amazon Redshift - Amazon Redshift
Herstellen von Verbindungen von außerhalb von Amazon EC2 und Auftreten von Problemen mit Firewall-ZeitüberschreitungenVerbindung wird zurückgewiesen oder schlägt fehlClient und Treiber sind nicht kompatibelAbfragen scheinen zu hängen und erreichen manchmal den Cluster nichtFestlegen des JDBC-Parameters für die Abrufgröße

Amazon Redshift unterstützt ab dem 1. November 2025 nicht mehr die Erstellung neuer Python-UDFs. Wenn Sie Python-UDFs verwenden möchten, erstellen Sie die UDFs vor diesem Datum. Bestehende Python-UDFs funktionieren weiterhin wie gewohnt. Weitere Informationen finden Sie im Blog-Posting.

Beheben von Problemen mit Verbindungen in Amazon Redshift

Wenn Sie Probleme haben, aus einem SQL-Client-Tool Verbindungen mit Ihrem Cluster herzustellen, gibt es mehrere Dinge, die Sie überprüfen können, um das Problem einzuengen. Wenn Sie SSL oder Serverzertifikate verwenden, entfernen Sie zunächst diese Komplexität, während Sie das Verbindungsproblem untersuchen. Fügen Sie diese Komponenten wieder hinzu, wenn Sie eine Lösung gefunden haben. Weitere Informationen finden Sie unter Konfigurieren von Sicherheitsoptionen für Verbindungen.

Informationen zu Verhaltensänderungen der Amazon-Redshift-Funktionalität, die sich auf Ihre Anwendung auswirken können, finden Sie unterVerhaltensänderungen in Amazon Redshift.

Wichtig

Amazon Redshift hat die Verwaltung von SSL-Zertifikaten verändert. Wenn Sie Probleme mit der Verbindungsherstellung mit SSL haben, müssen Sie unter Umständen die aktuellen vertrauenswürdigen CA-Stammzertifikate aktualisieren. Weitere Informationen finden Sie unter Umstellung auf ACM-Zertifikate für SSL-Verbindungen.

Im folgenden Abschnitt werden einige beispielhafte Fehlermeldungen und mögliche Lösungen für Verbindungsprobleme gezeigt. Da die verschiedenen SQL-Client-Tools verschiedene Fehlermeldungen anzeigen, ist diese Liste nicht vollständig. Sie sollte jedoch einen guten Ausgangspunkt für die Behebung von Problemen darstellen.

Herstellen von Verbindungen von außerhalb von Amazon EC2 und Auftreten von Problemen mit Firewall-Zeitüberschreitungen

Ihre Client-Verbindung mit der Datenbank scheint zu hängen oder Zeitüberschreitungen zu unterliegen, wenn lange Abfragen wie COPY-Befehle ausgeführt werden. Wenn dies der Fall ist, sehen Sie möglicherweise in der Amazon-Redshift-Konsole, dass die Abfrage abgeschlossen ist, aber das Client-Tool scheint die Abfrage noch nicht abgeschlossen zu haben. Je nachdem, wann die Verbindung unterbrochen wurde, fehlen möglicherweise Abfrageergebnisse oder sind unvollständig.

Mögliche Lösungen

Dieses Problem tritt auf, wenn Sie eine Verbindung zu Amazon Redshift von einer anderen Maschine als einer Amazon-EC2-Instance herstellen. In diesem Fall werden Leerlaufverbindungen durch eine Zwischennetzwerkkomponente, z. B. eine Firewall, nach einem Inaktivitätszeitraum beendet. Dieses Verhalten ist typisch, wenn Sie sich über ein Virtual Private Network (VPN) oder Ihr lokales Netzwerk anmelden.

Um diese Zeitüberschreitungen zu vermeiden, werden folgende Änderungen empfohlen:

Ändern der TCP/IP-Einstellungen für Zeitüberschreitungen

Um die TCP/IP-Einstellungen für Zeitüberschreitungen zu ändern, konfigurieren Sie die Einstellungen für Zeitüberschreitungen entsprechend dem Betriebssystem, das Sie für Verbindung mit Ihrem Cluster verwenden.

  • Linux – Wenn Ihr Client unter Linux ausgeführt wird, führen Sie den folgenden Befehl als Root-Benutzer aus, um die Timeout-Einstellungen für die aktuelle Sitzung zu ändern: 

    /sbin/sysctl -w net.ipv4.tcp_keepalive_time=200 net.ipv4.tcp_keepalive_intvl=200 net.ipv4.tcp_keepalive_probes=5

    Um die Einstellungen dauerhaft festzulegen, erstellen Sie die Datei /etc/sysctl.conf mit den folgenden Werten oder aktualisieren sie entsprechend und starten anschließend Ihr System neu. 

    net.ipv4.tcp_keepalive_time=200
net.ipv4.tcp_keepalive_intvl=200
net.ipv4.tcp_keepalive_probes=5

  • Windows – Wenn Ihr Client unter Windows ausgeführt wird, bearbeiten Sie die Werte für die folgenden Registrierungseinstellungen unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\:

    • KeepAliveTime: 30000

    • KeepAliveInterval: 1000

    • TcpMaxDataRetransmissions: 10

    Diese Einstellungen verwenden den DWORD-Datentyp. Wenn die am Registrierungspfad nicht vorhanden sind, können Sie die Einstellungen erstellen und diese empfohlenen Werte angeben. Weitere Informationen zum Bearbeiten der Windows-Registrierung finden Sie in der Windows-Dokumentation.

    Nachdem Sie diese Werte festgelegt haben, starten Sie Ihren Computer neu, damit die Änderungen wirksam werden.

  • Mac – Wenn Ihr Client auf einem Mac ausgeführt wird, führen Sie die folgenden Befehle aus, um die Timeout-Einstellungen für die aktuelle Sitzung zu ändern: 

    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

    Um die Einstellungen dauerhaft festzulegen, erstellen Sie die Datei /etc/sysctl.conf mit den folgenden Werten: 

    net.inet.tcp.keepidle=200000
net.inet.tcp.keepintvl=200000
net.inet.tcp.keepinit=200000
net.inet.tcp.always_keepalive=1

    Starten Sie Ihren Computer neu und führen Sie anschließend die folgenden Befehle aus, um zu überprüfen, ob die Werte festgelegt wurden. 

    sysctl net.inet.tcp.keepidle
sysctl net.inet.tcp.keepintvl
sysctl net.inet.tcp.keepinit
sysctl net.inet.tcp.always_keepalive

Ändern der DSN-Einstellungen für Zeitüberschreitungen

Sie können das Keepalive-Verhalten auf DSN-Ebene festlegen, wenn Sie dies wünschen. Sie tun dies, indem Sie die folgenden Parameter in der odbc.ini-Datei hinzufügen oder ändern:

KeepAlivesCount

Die Anzahl der TCP-Keepalive-Pakete, die verloren gehen dürfen, bevor die Verbindung als abgebrochen betrachtet wird.

KeepAlivesIdle

Die Anzahl der Inaktivitätsekunden, bevor der Treiber ein TCP-Keepalive-Paket sendet.

KeepAlivesInterval

Die Anzahl der Sekunden zwischen den einzelnen TCP-Keepalive-Übertragungen.

Wenn diese Parameter nicht vorhanden sind oder den Wert 0 aufweisen, verwendet das System die für TCP/IP angegebenen Keepalive-Parameter, um das DSN-Keepalive-Verhalten festzulegen. Unter Windows finden Sie die TCP/IP-Parameter in der Registrierung in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\. Unter Linux und macOS befinden sich die TCP/IP-Parameter in der sysctl.conf-Datei.

Verbindung wird zurückgewiesen oder schlägt fehl

Wenn Ihre Verbindung abgelehnt wird oder fehlschlägt, erhalten Sie möglicherweise eine Fehlermeldung, die einer der folgenden ähnelt.

  • „Fehler bei der Herstellung einer Verbindung mit <endpoint>.“

  • „Keine Verbindung mit dem Server möglich: Zeitüberschreitung für die Verbindung. Wird der Server auf dem Host '<endpoint>' ausgeführt und werden TCP/IP-Verbindungen auf Port '<port>' akzeptiert?“

  • „Verbindung zurückgewiesen. Überprüfen Sie, ob Host-Name und Port korrekt sind und der Postmaster TCP/IP-Verbindungen akzeptiert.“

Mögliche Lösungen

Wenn Sie eine Fehlermeldung erhalten, die besagt, dass keine Verbindung hergestellt werden kann, bedeutet dies im Allgemeinen, dass es ein Problem mit der Berechtigung für den Zugriff auf den Cluster gibt.

Um sich von einem Client-Tool außerhalb des Netzwerks, in dem sich der Cluster befindet, mit dem Cluster zu verbinden, fügen Sie der Sicherheitsgruppe des Clusters eine Eingangsregel hinzu. Die Regelkonfiguration hängt davon ab, ob der Amazon-Redshift-Cluster in einer Virtual Private Cloud (VPC) erstellt wurde:

  • Wenn Sie Ihren Amazon-Redshift-Cluster in einer Virtual Private Cloud (VPC) basierend auf Amazon VPC erstellt haben, fügen Sie in Amazon VPC eine Eingangsregel der VPC-Sicherheitsgruppe hinzu, die die Client-CIDR/IP-Adresse angibt. Weitere Informationen zum Konfigurieren von VPC-Sicherheitsgruppen für Ihren Cluster sowie zu öffentlich zugänglichen Optionen finden Sie unter Redshift-Ressourcen in einer VPC.

  • Wenn Sie Ihren Amazon-Redshift-Cluster außerhalb einer VPC erstellt haben, fügen Sie Ihre Client-CIDR/IP-Adresse der Cluster-Sicherheitsgruppe in Amazon Redshift hinzu. Weitere Informationen zum Konfigurieren von Cluster-Sicherheitsgruppen finden Sie unter Amazon-Redshift-Sicherheitsgruppen.

Wenn Sie versuchen, sich von einem Client-Tool in einer Amazon-EC2-Instance aus mit dem Cluster zu verbinden, fügen Sie ebenfalls eine Zugangsregel hinzu. Fügen Sie in diesem Fall der Cluster-Sicherheitsgruppe eine Regel hinzu. Die Regel muss die Amazon-EC2-Sicherheitsgruppe angeben, die der Amazon-EC2-Instance des Client-Tools zugeordnet ist.

In einigen Fällen haben Sie möglicherweise eine Ebene zwischen dem Client und dem Server, z. B. eine Firewall. Stellen Sie in diesen Fällen sicher, dass die Firewall eingehende Verbindungen über den Port akzeptiert, den Sie für Ihren Cluster konfiguriert haben.

Client und Treiber sind nicht kompatibel

Wenn Ihr Client und Ihr Treiber nicht kompatibel sind, erhalten Sie möglicherweise die folgende Fehlermeldung: „Die Architektur von Treiber und Anwendung im angegebenen DSN stimmt nicht überein.“

Mögliche Lösungen

Wenn Sie versuchen, eine Verbindung herzustellen, und einen Fehler bezüglich einer Architekturunstimmigkeit erhalten, bedeutet dies, dass das Client-Tool und der Treiber nicht kompatibel sind. Dies tritt auf, wenn ihre Systemarchitektur nicht übereinstimmt. Dies kann beispielsweise vorkommen, wenn Sie ein 32-Bit-Client-Tool verwenden, jedoch die 64-Bit-Version des Treibers installiert haben. Manchmal können 64-Bit-Client-Tools 32-Bit-Treiber verwenden. Sie können 32-Bit-Anwendungen jedoch nicht mit 64-Bit-Treibern verwenden. Stellen Sie sicher, dass Treiber und Client-Tool dieselbe Version der Systemarchitektur verwenden.

Abfragen scheinen zu hängen und erreichen manchmal den Cluster nicht

Sie haben ein Problem mit dem Abschluss von Abfragen. Die Abfragen werden anscheinend ausgeführt, hängen jedoch im SQL-Client-Tool. Manchmal erreichen die Abfragen den Cluster anscheinend nicht, beispielsweise in Systemtabellen oder in der Amazon-Redshift-Konsole.

Mögliche Lösungen

Dieses Problem kann aufgrund von Paketverlusten auftreten. In diesem Fall gibt es einen Unterschied in der maximalen Größe der Übertragungseinheit (MTU) im Netzwerkpfad zwischen zwei Internet Protocol (IP) Hosts. Der MTU-Wert legt die maximale Größe für die Übertragung eines Pakets in einem Ethernet-Frame über eine Netzwerkverbindung in Bytes fest. In AWS unterstützen einige Amazon-EC2-Instance-Typen einen MTU-Wert von 1500 (Ethernet v2-Frames). Andere Instance-Typen unterstützen hingegen einen MTU-Wert von 9001 (TCP/IP-Jumbo-Frames).

Um Probleme im Zusammenhang mit unterschiedlichen MTU-Größen zu vermeiden, wird eine der folgenden Aktionen empfohlen:

  • Wenn Ihr Cluster die EC2-VPC-Plattform verwendet, konfigurieren Sie die Amazon-VPC-Sicherheitsgruppe mit einer ICMP-Regel (Inbound Custom Internet Control Message Protocol), die zurückgibt Destination Unreachable. Die Regel weist also den Ursprungshost an, die niedrigste MTU-Größe entlang des Netzwerkpfades zu verwenden. Details zu diesem Ansatz finden Sie unter Konfigurieren von Sicherheitsgruppen, um ICMP „Ziel kann nicht erreicht werden“ zuzulassen.

  • Wenn Ihr Cluster die EC2-Classic-Plattform verwendet oder Sie die ICMP-Eingangsregel nicht zulassen können, deaktivieren Sie TCP/IP-Jumbo-Frames, so dass Ethernet v2-Frames verwendet werden. Details zu diesem Ansatz finden Sie unter Konfigurieren der MTU einer Instance.

Konfigurieren von Sicherheitsgruppen, um ICMP „Ziel kann nicht erreicht werden“ zuzulassen

Wenn es im Netzwerk zwischen zwei Hosts unterschiedliche MTU-Größen gibt, stellen Sie zunächst sicher, dass Ihre Netzwerkeinstellungen die Pfad-MTU-Erkennung (Path MTU Discovery, PMTUD) nicht blockieren. PMTUD ermöglicht dem empfangenden Host, dem sendenden Host mit der folgenden ICMP-Meldung zu antworten: Destination Unreachable: fragmentation needed and DF set (ICMP Type 3, Code 4). Diese Meldung weist den sendenden Host an, die kleinste MTU-Größe zu verwenden, die auf dem Netzwerkpfad zulässig ist, und die Anforderung neu zu senden. Ohne diese Verhandlung können Paketverluste auftreten, da die Anforderung für den empfangenden Host zu groß ist, um sie akzeptieren zu können. Weitere Informationen zu dieser ICMP-Meldung finden Sie unter RFC792 auf der Website Internet Engineering Task Force (IETF).

Wenn Sie diese ICMP-Eingangsregel nicht ausdrücklich für Ihre Amazon-VPC-Sicherheitsgruppe konfigurieren, wird PMTUD blockiert. In AWS sind Sicherheitsgruppen virtuelle Firewalls, die Regeln für den ein- und ausgehenden Datenverkehr für eine Instance angeben. Informationen zu Amazon-Redshift-Cluster-Sicherheitsgruppen finden Sie unter Amazon-Redshift-Sicherheitsgruppen. Im Fall von Clustern, die die EC2-VPC-Plattform verwenden, verwendet Amazon Redshift VPC-Sicherheitsgruppen, um Datenverkehr zum Cluster zuzulassen oder abzulehnen. Standardmäßig sind die Sicherheitsgruppen restriktiv und lehnen jeden eingehenden Datenverkehr ab. Informationen zum Festlegen der Regeln für ein- und ausgehenden Datenverkehr für EC2-Classic- oder EC2-VPC-Instances finden Sie unter Unterschiede zwischen Instances in EC2-Classic und einer VPC im Amazon-EC2-Benutzerhandbuch.

Weitere Informationen zum Hinzufügen von Regeln zu VPC-Sicherheitsgruppen finden Sie unter VPC-Sicherheitsgruppen. Weitere Informationen zu spezifischen PMTUD-Einstellungen, die in dieser Regel erforderlich sind, finden Sie unter Pfad-MTU-Erkennung im Amazon-EC2-Benutzerhandbuch.

Konfigurieren der MTU einer Instance

In einigen Fällen verwendet Ihr Cluster möglicherweise die EC2-Classic-Plattform, oder Sie können die benutzerdefinierte ICMP-Regel für eingehenden Datenverkehr nicht zulassen. In diesen Fällen wird empfohlen, die MTU auf der Netzwerkschnittstelle (NIC) der EC2-Instances, von denen Sie eine Verbindung mit dem Amazon-Redshift-Cluster herstellen, auf 1500 zu setzen. Durch diese Einstellung werden TCP/IP-Jumbo-Frames deaktiviert, um sicherzustellen, dass Verbindungen stets dieselbe Paketgröße verwenden. Diese Option reduziert den maximalen Netzwerkdurchsatz für die Instance insgesamt und nicht nur für Verbindungen mit Amazon Redshift. Weitere Informationen finden Sie in den folgenden Verfahren.

So legen Sie die MTU in einem Microsoft Windows-Betriebssystem fest

Wenn Ihr Client in einem Microsoft Windows-Betriebssystem ausgeführt wird, können Sie den MTU-Wert für den Ethernet-Adapter anzeigen und festlegen, indem Sie den Befehl netsh verwenden.

  1. Führen Sie den folgenden Befehl aus, um den aktuellen MTU-Wert zu ermitteln: 

    netsh interface ipv4 show subinterfaces

  2. Überprüfen Sie den MTU-Wert für den Ethernet-Adapter in der Ausgabe.

  3. Wenn der Wert nicht 1500 ist, führen Sie den folgenden Befehl aus, um ihn festzulegen: 

    netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent

    Nachdem Sie diesen Wert festgelegt haben, starten Sie Ihren Computer neu, damit die Änderungen wirksam werden.

So legen Sie die MTU in einem Linux-Betriebssystem fest

Wenn Ihr Client in einem Linux-Betriebssystem ausgeführt wird, können Sie den MTU-Wert für den Ethernet-Adapter anzeigen und festlegen, indem Sie den Befehl ip verwenden.

  1. Führen Sie den folgenden Befehl aus, um den aktuellen MTU-Wert zu ermitteln: 

    $ ip link show eth0

  2. Überprüfen Sie den Wert nach mtu in der Ausgabe.

  3. Wenn der Wert nicht 1500 ist, führen Sie den folgenden Befehl aus, um ihn festzulegen: 

    $ sudo ip link set dev eth0 mtu 1500
So legen Sie die MTU in einem Mac-Betriebssystem fest

  • Folgen Sie den Anweisungen auf der Supportwebsite von MacOS zu How to change the MTU for troubleshooting purposes. Weitere Informationen finden Sie auf der Supportwebsite.

Festlegen des JDBC-Parameters für die Abrufgröße

Der JDBC-Treiber stellt bei Abfragen alle Ergebnisse auf einmal zusammen. Wenn Sie in diesem Fall versuchen, eine große Ergebnismenge über eine JDBC-Verbindung abzurufen, können clientseitig Fehler aufgrund von unzureichendem Arbeitsspeicher auftreten. Um Ihren Client so einrichten, dass er die Ergebnismengen statt in einem einzigen Vorgang – der erfolgreich abgeschlossen wird oder ganz fehlschlägt – in Batches abruft, stellen Sie den Parameter für die JDBC-Abrufgröße in der Clientanwendung ein.

Anmerkung

Abrufgröße wird für ODBC nicht unterstützt

Legen Sie die Abrufgröße auf den höchsten Wert fest, der nicht zu Fehlern aufgrund von unzureichendem Arbeitsspeicher führt, um die Leistung zu optimieren. Wenn der Wert für die Abrufgröße kleiner gewählt wird, führt dies zu mehr Übertragungsvorgängen zwischen Server und Client, was die Ausführungszeit vergrößert. Der Server reserviert Ressourcen wie den WLM-Abfrageplatz und den zugehörigen Arbeitsspeicher, bis der Client die Ergebnismenge abruft oder die Abfrage abgebrochen wird. Wenn die Abrufgröße richtig eingestellt ist, werden diese Ressourcen schneller wieder freigegeben und sind für andere Abfragen verfügbar.

Anmerkung

Wenn Sie große Datensätze extrahieren müssen, sollten Sie eine UNLOAD-Anweisung verwenden, um die Daten zu Amazon S3 zu übertragen. Wenn Sie UNLOAD verwenden, arbeiten die Datenverarbeitungsknoten parallel, um die Übertragung der Daten zu beschleunigen.

Weitere Informationen zum Festlegen des Parameters für die JDBC-Abrufgröße finden Sie unter Getting results based on a cursor in der PostgreSQL-Dokumentation.