Einführung
Im Allgemeinen können Verbindungsprobleme einem der folgenden drei Bereiche zugeordnet werden:
- Verbindung herstellen: Ist Ihre Instanz über das Netzwerk erreichbar?
- Autorisierung: Sind Sie berechtigt, eine Verbindung zur Instanz herzustellen?
- Authentifizierung: Akzeptiert die Datenbank Ihre Datenbankanmeldedaten?
Jeder dieser Bereiche kann für die Untersuchung weiter in verschiedene Pfade unterteilt werden. Der folgende Abschnitt enthält Beispiele für Fragen, die Sie sich selbst stellen können, um das Problem einzugrenzen:
Checkliste für Verbindungsprobleme
- Wird verbunden
- Private IP-Adresse
- Haben Sie
Service Networking API
für Ihr Projekt aktiviert? - Verwenden Sie eine freigegebene VPC?
- Hat Ihr Nutzer- oder Dienstkonto die erforderlichen IAM-Berechtigungen, um eine Verbindung für den Zugriff auf private Dienste zu verwalten?
- Ist die Verbindung für den Zugriff auf private Dienste für Ihr Projekt konfiguriert?
- Haben Sie für die private Verbindung einen IP-Adressbereich zugewiesen?
- Enthalten Ihre zugewiesenen IP-Adressbereiche mindestens einen /24-Bereich für jede Region, in der Sie planen, postgres-Instanzen zu erstellen?
- Wenn Sie einen zugewiesenen IP-Adressbereich für Ihre postgres-Instanzen angeben, enthält der Bereich mindestens einen /24-Bereich für jede Region, in der Sie postgres-Instanzen in diesem Bereich erstellen möchten?
- Wurde die private Verbindung erstellt?
- Wenn die private Verbindung geändert wurde, wurden vpc-peerings aktualisiert?
- Werden in den VPC-Logs Fehler angezeigt?
- Ist die IP-Adresse Ihrer Quellmaschine eine Adresse außerhalb des RFC 1918-Bereichs?
- Öffentliche IP-Adresse
- Wird Ihre Quell-IP als autorisiertes Netzwerk aufgeführt?
- Sind SSL/TLS-Zertifikate erforderlich?
- Hat Ihr Nutzer- oder Dienstkonto die erforderlichen IAM-Berechtigungen, um eine Verbindung zu einer Cloud SQL-Instanz herzustellen?
- Autorisieren
- Cloud SQL Auth-Proxy
- Ist der Cloud SQL Auth-Proxy auf dem neuesten Stand?
- Wird der Cloud SQL Auth-Proxy ausgeführt?
- Ist der Verbindungsname der Instanz im Cloud SQL Auth-Proxy-Verbindungsbefehl korrekt gebildet?
- Haben Sie die Ausgabe des Cloud SQL Auth-Proxys überprüft? Leiten Sie die Ausgabe in eine Datei oder beobachten Sie das Cloud Shell-Terminal, in dem Sie den Cloud SQL Auth-Proxy gestartet haben.
- Hat Ihr Nutzer- oder Dienstkonto die erforderlichen IAM-Berechtigungen, um eine Verbindung zu einer Cloud SQL-Instanz herzustellen?
- Haben Sie
Cloud SQL Admin API
für Ihr Projekt aktiviert? - Wenn Sie eine Firewallrichtlinie für ausgehende Verbindungen haben, müssen Sie darauf achten, dass sie Verbindungen zu Port 3307 auf der Ziel-Cloud SQL-Instanz zulässt.
- Wenn Sie eine Verbindung über UNIX-Domain-Sockets herstellen, achten Sie darauf, dass die Sockets erstellt wurden. Dazu listen Sie das Verzeichnis auf, das Sie beim Start des Cloud SQL Auth-Proxys mit -dir angegeben haben.
- Cloud SQL-Connectors und sprachspezifischer Code
- Ist der Verbindungsstring richtig gebildet?
- Haben Sie Ihren Code mit dem Beispielcode für Ihre Programmiersprache verglichen?
- Verwenden Sie eine Laufzeit oder ein Framework, für das wir keinen Beispielcode haben?
- Falls ja, haben Sie in der Community nach relevanten Referenzmaterialien gesucht?
- Selbstverwaltete SSL/TLS-Zertifikate
- Ist das Clientzertifikat auf der Quellmaschine installiert?
- Ist das Clientzertifikat in den Verbindungsargumenten richtig geschrieben?
- Ist das Clientzertifikat immer noch gültig?
- Werden Fehler angezeigt, wenn Sie eine Verbindung über SSL herstellen?
- Ist das Serverzertifikat weiterhin gültig?
- Autorisierte Netzwerke
- Ist die Quell-IP-Adresse enthalten?
- Verwenden Sie eine IP-Adresse außerhalb des RFC 1918-Bereichs?
- Verwenden Sie eine nicht unterstützte IP-Adresse?
- Verbindungsfehler
- Sind Sie für die Verbindung autorisiert?
- Werden Verbindungslimit-Fehler angezeigt?
- Schließt die Anwendung Verbindung richtig?
- Authentifizierung
- Authentifizierung der nativen Datenbank (Nutzername/Passwort)
- Werden
access denied
-Fehler angezeigt? - Sind Nutzername und Passwort korrekt?
- Authentifizierung der IAM-Datenbank
- Haben Sie auf Ihrer Instanz das Flag
cloudsql.iam_authentication
aktiviert ? - Haben Sie für das Konto eine Richtlinienbindung hinzugefügt?
- Verwenden Sie den Cloud SQL Auth-Proxy mit dem
-enable_iam_login
oder einem OAuth 2.0-Token als Datenbankpasswort? - Wenn Sie ein Dienstkonto verwenden, wird der verkürzte E-Mail-Name verwendet?
- IAM-Datenbankauthentifizierung in PostgreSQL
Fehlermeldungen
Informationen zu bestimmten API-Fehlermeldungen finden Sie auf der Referenzseite zu Fehlermeldungen.
Fehlerbehebung für weitere Verbindungsfehler
Informationen zu anderen Problemen finden Sie auf der Seite zur Fehlerbehebung im Abschnitt Verbindung.
Häufige Verbindungsprobleme
Prüfen, ob Ihre Anwendung Verbindungen korrekt beendet
Wenn Sie Fehler sehen, die Aborted connection nnnn to db:
enthalten, deutet dies normalerweise darauf hin, dass Ihre Anwendung Verbindungen nicht ordnungsgemäß beendet. Auch Netzwerkprobleme können diesen Fehler verursachen. Der Fehler bedeutet nicht, dass Probleme mit der Cloud SQL-Instanz vorliegen. Sie sollten außerdem tcpdump
ausführen, um die Pakete zu prüfen und die Ursache des Problems zu ermitteln.
Beispiele für Best Practices zum Verbindungsmanagement finden Sie unter Datenbankverbindungen verwalten.
Prüfen, ob die Zertifikate abgelaufen sind
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf und öffnen Sie die Instanz, wenn Ihre Instanz für die Verwendung von SSL konfiguriert ist. Rufen Sie die Seite Verbindungen auf, wählen Sie den Tab Sicherheit aus und prüfen Sie, ob das Serverzertifikat gültig ist. Wenn es abgelaufen ist, müssen Sie ein neues Zertifikat hinzufügen und zu diesem rotieren.
Prüfen, ob Verbindungsaufbau zulässig ist
Wenn Ihre Verbindungen fehlschlagen, überprüfen Sie, dass Sie berechtigt sind, eine Verbindung herzustellen:
- Wenn Sie Schwierigkeiten haben, eine Verbindung über eine bestimmte IP-Adresse herzustellen, beispielsweise eine Verbindung aus Ihrer lokalen Umgebung mit dem psql-Client, achten Sie darauf, dass die verwendete IP-Adresse für die Verbindung zur Cloud SQL-Instanz autorisiert ist.
Verbindungen zu einer Cloud SQL-Instanz mit einer privaten IP-Adresse werden für RFC 1918-Adressbereiche automatisch autorisiert. Auf diese Weise können alle privaten Clients auf die Datenbank zugreifen, ohne den Cloud SQL Auth-Proxy zu verwenden. Adressen außerhalb des RFC 1918-Bereichs müssen als autorisierte Netzwerke konfiguriert sein.
Cloud SQL lernt standardmäßig keine Subnetzrouten außerhalb des RFC 1918-Bereichs von Ihrer VPC. Sie müssen deshalb das Netzwerk-Peering auf Cloud SQL aktualisieren, um alle Routen außerhalb des RFC 1918-Bereichs exportieren zu können. Beispiele:
gcloud compute networks peerings update cloudsql-postgres-googleapis-com \ --network=NETWORK \ --export-subnet-routes-with-public-ip \ --project=PROJECT_ID
Hier finden Sie Ihre aktuelle IP-Adresse.
- Führen Sie den Befehl
gcloud sql connect
aus, um eine Verbindung zur Instanz herzustellen. Mit diesem Befehl autorisieren Sie die IP-Adresse für kurze Zeit. Sie können diesen Befehl in einer Umgebung ausführen, in der die CLI gcloud und der psql-Client installiert sind. Sie können diesen Befehl auch in Cloud Shell ausführen. Cloud Shell ist in der Google Cloud Console verfügbar. Die gcloud CLI und der psql-Client sind dort bereits vorinstalliert. Cloud Shell bietet eine Compute Engine-Instanz, mit der Sie eine Verbindung zu Cloud SQL herstellen können. - Lassen Sie vorübergehend zu, dass von jeder IP-Adresse eine Verbindung zur Instanz hergestellt werden kann. Autorisieren Sie dazu
0.0.0.0/0
.
Verbindungsart prüfen
Wenn Sie eine Fehlermeldung wieFATAL: database `user` does not exist.
Die Seitegcloud sql connect --user
funktioniert nur mit dem Standardnutzer (postgres
). Verwenden Sie die folgende Anweisung, um eine Verbindung mit dem Standardnutzer herzustellen und nutzen den "\c"
psql-Befehl, um die Verbindung wieder herzustellen.
Initialisierungsart von Verbindungen bestimmen
Sie können sich Informationen zu Ihren aktuellen Verbindungen anzeigen lassen, indem Sie eine Verbindung zu Ihrer Datenbank herstellen und den folgenden Befehl ausführen:
SELECT * from pg_stat_activity ;
Verbindungen, die eine IP-Adresse wie 1.2.3.4
haben, werden über IP hergestellt.
Verbindungen mit cloudsqlproxy~1.2.3.4
verwenden den Cloud SQL Auth-Proxy oder stammen von App Engine. Verbindungen von localhost
können von einigen internen Cloud SQL-Prozessen verwendet werden.
Verbindungseinschränkungen
Es gibt keine Beschränkungen hinsichtlich der Abfragen pro Sekunde (QPS) für Cloud SQL-Instanzen. Allerdings gibt es Beschränkungen für die Anzahl der Verbindungen und die Größe sowie App Engine-spezifische Einschränkungen. Weitere Informationen finden Sie unter Kontingente und Limits.
Datenbankverbindungen verbrauchen Ressourcen des Servers und der Anwendung, von der die Verbindung ausgeht. Daher sollten Sie sich bei der Verbindungsverwaltung immer an Best Practices orientieren. So können Sie die Kosten für die Anwendung minimieren und die Wahrscheinlichkeit senken, dass die Verbindungslimits für Cloud SQL überschritten werden. Weitere Informationen finden Sie unter Datenbankverbindungen verwalten.
Verbindungen und Threads ansehen
In der Tabelle pg_stat_activity werden die Prozesse angezeigt, die in Ihrer Datenbank ausgeführt werden:
select * from pg_stat_activity;
Zeitlimit für Verbindungen (von Compute Engine)
Bei Verbindungen mit einer Compute Engine-Instanz tritt nach 10 Minuten Inaktivität eine Zeitüberschreitung auf. Dies kann sich auf langlebige, nicht verwendete Verbindungen zwischen Ihrer Compute Engine-Instanz und Ihrer Cloud SQL-Instanz auswirken. Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Netzwerke und Firewalls.
Um langlebige ungenutzte Verbindungen aufrechtzuerhalten, können Sie TCP keepalive aktivieren. Mit den folgenden Befehlen kann der TCP keepalive-Wert auf eine Minute gesetzt und dafür gesorgt werden, dass die Konfiguration auch nach Neustarts der Instanz bestehen bleibt.
Rufen Sie den aktuellen Wert für tcp_keepalive_time auf.
cat /proc/sys/net/ipv4/tcp_keepalive_time
Setzen Sie tcp_keepalive_time auf 60 Sekunden und legen Sie fest, dass die Konfiguration auch nach einem Neustart bestehen bleibt.
echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf
Übernehmen Sie die Änderung.
sudo /sbin/sysctl --load=/etc/sysctl.conf
Rufen Sie den Wert tcp_keepalive_time auf, um zu prüfen, ob die Änderung angewendet wurde.
cat /proc/sys/net/ipv4/tcp_keepalive_time
Tools zum Debuggen von Verbindungen
tcpdump
tcpdump
ist ein Tool zum Erfassen von Paketen. Es wird dringend empfohlen, tcpdump
auszuführen, um die Pakete zwischen Ihrem Host und den Cloud SQL-Instanzen zu erfassen und zu prüfen, wenn Sie Verbindungsprobleme untersuchen.
Lokale IP-Adresse ermitteln
Wenn Sie die lokale Adresse Ihres Hosts nicht kennen, führen Sie den Befehl ip -br address show
aus. Unter Linux zeigt dies die Netzwerkschnittstelle, den Status der Schnittstelle, die lokale IP-Adresse und die MAC-Adressen. Beispiel: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64
.
Alternativ können Sie ipconfig
oder ifconfig
ausführen, um den Status Ihrer Netzwerkschnittstellen aufzurufen.
Mit Konnektivitätstest testen
Mit dem Diagnosetool Konnektivitätstest können Sie die Konnektivität zwischen den Endpunkten in Ihrem Netzwerk prüfen. Es analysiert Ihre Konfiguration und führt in einigen Fällen auch eine Laufzeitprüfung aus. Es unterstützt jetzt Cloud SQL. Folgen Sie dieser Anleitung, um Tests mit Ihren Cloud SQL-Instanzen auszuführen.
Verbindung testen
Sie können den psql-Client für einen Verbindungstest von der lokalen Umgebung aus verwenden. Weitere Informationen finden Sie unter psql-Client über eine IP-Adresse verbinden und psql-Client über den Cloud SQL Auth-Proxy verbinden.
IP-Adresse für die Anwendung ermitteln
Sie können die IP-Adresse eines Computers ermitteln, auf dem die Anwendung ausgeführt wird, und dann den Zugriff auf die Cloud SQL-Instanz über diese Adresse autorisieren. Verwenden Sie dazu eine der folgenden Methoden:
- Wenn sich der Computer nicht hinter einem Proxy oder einer Firewall befindet, melden Sie sich beim Computer an und verwenden Sie die Option Wie lautet meine IP?, um die IP-Adresse zu ermitteln.
- Wenn sich der Computer hinter einem Proxy oder einer Firewall befindet, melden Sie sich beim Computer an und ermitteln die tatsächliche IP-Adresse mit einem Tool oder Dienst wie whatismyipaddress.com.
Lokale Ports öffnen
Mit dem Befehl ss -tunlp4
können Sie prüfen, ob der Host tatsächlich die Ports überwacht, von denen Sie dies annehmen. So sehen Sie, welche Ports offen und empfangsbereit sind.
Wenn Sie beispielsweise eine PostgreSQL-Datenbank ausführen, sollte Port 5432 für Sie aktiv sein. Für SSH sollten Sie Port 22 sehen.
Alle lokalen Portaktivitäten
Rufen Sie mit dem Befehl netstat
alle lokalen Portaktivitäten auf. Beispiel: netstat -lt
zeigt alle derzeit aktiven Ports an.
Telnet-Verbindung zu Ihrer Cloud SQL-Instanz herstellen
Führen Sie den Befehl telnet
aus, um zu prüfen, ob Sie mit TCP
eine Verbindung zu Ihrer Cloud SQL-Instanz herstellen können. Telnet versucht, eine Verbindung zu der von Ihnen angegebenen IP-Adresse und zum Port herzustellen.
telnet 35.193.198.159 5432
.
Bei Erfolg wird Folgendes angezeigt:
Trying 35.193.198.159...
Connected to 35.193.198.159.
.
Bei einem Fehler hängt telnet
, bis Sie die Schließung des Versuchs erzwingen:
Trying 35.193.198.159...
^C.
.
Clientauthentifizierung
Die Clientauthentifizierung wird durch eine Konfigurationsdatei mit dem Namen pg_hba.conf
gesteuert. HBA steht für die hostbasierte Authentifizierung.
Prüfen Sie, ob der Abschnitt für Replikationsverbindungen der Datei pg_hba.conf
in der Quelldatenbank aktualisiert ist, damit Verbindungen vom IP-Adressbereich des Cloud SQL-VPC-Netzwerks akzeptiert werden.
Cloud Logging
Cloud SQL und Cloud SQL verwenden Cloud Logging. Ausführliche Informationen finden Sie in der Cloud Logging-Dokumentation und in den Cloud SQL-Beispielabfragen.
Logs ansehen
Sie können Logs für Cloud SQL-Instanzen und andere Google Cloud-Projekte wie Cloud VPN- oder Compute Engine-Instanzen aufrufen. So rufen Sie Logs für die Logeinträge Ihrer Cloud SQL-Instanz auf:
Console
-
Wechseln Sie in der Google Cloud Console zur Seite Cloud Logging.
- Wählen Sie oben auf der Seite ein vorhandenes Cloud SQL-Projekt aus.
- Fügen Sie im Query Builder Folgendes hinzu:
- Ressource: Wählen Sie Cloud SQL-Datenbank aus. Wählen Sie im Dialogfeld eine Cloud SQL-Instanz aus.
- Lognamen: Scrollen Sie zum Abschnitt "Cloud SQL" und wählen Sie die entsprechenden Logdateien für Ihre Instanz aus. Beispiel:
- cloudsql.googleapis.com/postgres.log
- Schweregrad: Wählen Sie eine Logebene aus.
- Zeitraum: Wählen Sie eine Voreinstellung aus oder erstellen Sie einen benutzerdefinierten Zeitraum.
gcloud
Rufen Sie Logeinträge mit dem Befehl gcloud logging
auf. Ersetzen Sie im folgenden Beispiel PROJECT_ID
.
Das Flag limit
ist ein optionaler Parameter, der die maximale Anzahl von zurückzugebenden Einträgen anzeigt.
gcloud logging read "projects/PROJECT_ID/logs/cloudsql.googleapis.com/postgres.log" \ --limit=10
Private IP-Adressen
Verbindungen zu einer Cloud SQL-Instanz mit einer privaten IP-Adresse werden für RFC 1918-Adressbereiche automatisch autorisiert. Nicht-RFC 1918-Adressbereiche müssen in Cloud SQL als autorisierte Netzwerke konfiguriert werden. Sie müssen auch das Netzwerk-Peering auf Cloud SQL aktualisieren, um alle Routen außerhalb des RFC 1918-Bereichs exportieren zu können. Beispiele:
gcloud compute networks peerings update cloudsql-postgres-googleapis-com
--network=NETWORK
--export-subnet-routes-with-public-ip
--project=PROJECT_ID
VPN-Fehler beheben
Weitere Informationen finden Sie unter Cloud VPN-Fehlerbehebung.