Debugging von Verbindungsproblemen

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

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 wie

ERROR 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.

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. Wenn Sie beispielsweise eine PostgreSQL-Datenbank ausführen, sollte Port 5432 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.

Wenn auf der Cloud SQL-Instanz zum Beispiel eine MySQL-Datenbank ausgeführt wird, sollten Sie über Port 3306 eine Verbindung zu dieser Instanz herstellen können: telnet 35.193.198.159 3306. Wenn auf der Cloud SQL-Instanz zum Beispiel eine PostgreSQL-Datenbank ausgeführt wird, sollten Sie über Port 5432 eine Verbindung zu dieser Instanz herstellen können: 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

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud Logging.

    Zu Cloud Logging

  2. Wählen Sie oben auf der Seite ein vorhandenes Cloud SQL-Projekt aus.
  3. 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
      • 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/mysql-general.log" \
--limit=10
 
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-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.