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, mysql-Instanzen zu erstellen?
- Wenn Sie einen zugewiesenen IP-Adressbereich für Ihre mysql-Instanzen angeben, enthält der Bereich mindestens einen /24-Bereich für jede Region, in der Sie mysql-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, prüfen Sie, ob 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 MySQL-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-mysql-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 mysql-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 mysql-Client sind dort bereits vorinstalliert. Cloud Shell bietet eine Compute Engine-Instanz, mit der Sie eine Verbindung zu Cloud SQL herstellen können. - Gestatten Sie vorübergehend allen IP-Adressen den Verbindungsaufbau zu einer Instanz. Autorisieren Sie für IPv4
0.0.0.0/0
(und für IPv6::/0
).
Verbindungsart prüfen
Wenn Sie eine Fehlermeldung wieERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: NO)
beim Verbindungsaufbau erhalten, prüfen Sie, ob Sie ein Passwort eingegeben haben.
Wenn Sie eine Fehlermeldung wie
ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: YES)
erhalten, prüfen Sie, ob das eingegebene Passwort korrekt ist und ob die Verbindung über SSL hergestellt wird, falls die Instanz dies erfordert.
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:
SHOW PROCESSLIST;
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
Wenn Sie eine Fehlermeldung erhalten, dass zu viele Verbindungen vorhanden sind, oder die Aktivitäten einer Instanz untersuchen möchten, können Sie die Anzahl der Verbindungen und Threads mit SHOW PROCESSLIST
anzeigen lassen.
Führen Sie aus einem MySQL-Client folgenden Befehl aus:
mysql> SHOW PROCESSLIST;
Die Ausgabe sollte in etwa so aussehen:
+----+-----------+--------------+-----------+---------+------+-------+----------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------+--------------+-----------+---------+------+-------+----------------------+ | 3 | user-name | client-IP | NULL | Query | 0 | NULL | SHOW processlist | | 5 | user-name | client-IP | guestbook | Sleep | 1 | | SELECT * from titles | | 17 | user-name | client-IP | employees | Query | 0 | NULL | SHOW processlist | +----+-----------+--------------+-----------+---------+------+-------+----------------------+ 3 rows in set (0.09 sec)
Informationen zur Auswertung der von PROCESSLIST
zurückgegebenen Spalten finden Sie in der MySQL-Referenz.
Sie können die Anzahl der Threads so abrufen:
mysql> SHOW STATUS WHERE Variable_name = 'Threads_connected';
Die Ausgabe sollte in etwa so aussehen:
+-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Threads_connected | 7 | +-------------------+-------+ 1 row in set (0.08 sec)
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
Mit IPv6 verbinden
Wenn Sie beim Verbindungsaufbau eine der folgenden Fehlermeldungen erhalten:
Can't connect to MySQL server on '2001:1234::4321' (10051) Can't connect to MySQL server on '2001:1234::4321' (101)
haben Sie wahrscheinlich versucht, eine Verbindung zur IPv6-Adresse Ihrer Instanz aufzubauen, während an Ihrer Workstation jedoch kein IPv6 verfügbar ist. Wenn Sie prüfen möchten, ob IPv6 auf Ihrer Workstation aktiv ist, öffnen Sie ipv6.google.com. Lädt die Seite nicht, ist IPv6 nicht verfügbar. Stellen Sie stattdessen eine Verbindung zur IPv4-Adresse oder zu Ihrer Cloud SQL-Instanz her. Möglicherweise müssen Sie Ihrer Instanz zuvor eine IPv4-Adresse hinzufügen.
Gelegentliche Verbindungsfehler (Legacy-HA)
Wenn Cloud SQL eine Instanz aufgrund von Wartungsereignissen neu startet, werden Verbindungen möglicherweise zum Failover-Replikat weitergeleitet. Beim Herstellen einer Verbindung zum Failover-Replikat:
- Funktionieren Leseanfragen von Clients, die unverschlüsselte Verbindungen verwenden, wie gewohnt. Schlagen Schreibanfragen jedoch fehl und geben eine Fehlermeldung zurück, z. B. "Error 1290: The MySQL server is running with the --read-only option so it cannot execute this statement." (Fehler 1290: Der MySQL-Server wird mit der Option "--read-only" ausgeführt, deshalb kann diese Anweisung nicht ausgeführt werden.)
- Schlagen Lese- und Schreibanfragen von Clients, die verschlüsselte Verbindungen verwenden, fehl und geben eine Fehlermeldung zurück, z. B. "x509: certificate is valid for master-instance, not failover-instance" (x509: Zertifikat ist für die Masterinstanz gültig, nicht für die Failover-Instanz).
Nach Ablauf des Ereignisses setzt Cloud SQL die Verbindung zurück. Erstellen Sie die Verbindung neu. Es empfiehlt sich, Anwendungen so zu entwickeln, dass sie gelegentliche Fehler beim Verbindungsaufbau verarbeiten können. Hierzu kann eine Fehlerbehandlungsstrategie wie exponentieller Backoff implementiert werden. Weitere Informationen finden Sie unter Anwendungsimplementierung.
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 mit dem MySQL-Client das Herstellen einer Verbindung von der lokalen Umgebung testen. Weitere Informationen finden Sie unter MySQL-Client über eine öffentliche IP-Adresse verbinden und MySQL-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 sind und überwacht werden.
Wenn Sie beispielsweise eine MySQL-Datenbank ausführen, sollte Port 3306 aktiviert sein und überwacht werden. 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 3306
.
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.
.
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.googlapis.com/mysql-general.log
- cloudsql.googleapis.com/mysql.err
- 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/mysql-general.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-mysql-googleapis-com
--network=NETWORK
--export-subnet-routes-with-public-ip
--project=PROJECT_ID
VPN-Fehler beheben
Weitere Informationen finden Sie unter Cloud VPN-Fehlerbehebung.