Verbindungsprobleme beheben

MySQL   |  PostgreSQL   |  PostgreSQL zu AlloyDB

Verbindungsprobleme beheben

Sie haben eine Verbindung zwischen Ihren Quell- und Zieldatenbanken eingerichtet. Woher wissen Sie aber, dass sie verbunden sind? Wenn die Kommunikation zwischen ihnen fehlschlägt, wie können Sie herausfinden, was und wo schiefgelaufen ist?

Die grundlegendsten Tools sind ping und traceroute.

Ping

Ping führt einen grundlegenden Test durch, um zu ermitteln, ob das Ziel ("Remote-Host") aus der Quelle verfügbar ist. Ping sendet ein ICMP Echo Request-Paket an einen Remote-Host und erwartet eine ICMP Echo Reply als Antwort. Wenn ping nicht erfolgreich ist, gibt es keine Route von der Quelle zum Ziel. Dies bedeutet jedoch nicht, dass Ihre Pakete übertragen werden können, sondern nur, dass im Allgemeinen der Remote-Host erreicht werden kann.

ping kann erkennen, ob ein Host aktiv ist und antwortet, aber es ist nicht garantiert, dass er zuverlässig ist. Einige Netzwerkanbieter blockieren ICMP als Vorsichtsmaßnahme, um das Debugging von Verbindungen zu vereinfachen.

Traceroute

Traceroute prüft die vollständigen Routen-Netzwerkpakete von einem Host zu einem anderen. Es werden alle Schritte ("Hops") angezeigt, die das Paket durchläuft, und wie lange jeder Schritt dauert. Wenn das Paket nicht den gesamten Weg durchläuft, wird traceroute nicht abgeschlossen, endet aber mit einer Reihe von Sternchen. Suchen Sie in diesem Fall die letzte IP-Adresse, die erfolgreich erreicht wurde. Hier ist die Verbindung unterbrochen.

Bei Traceroute kann es zu Zeitüberschreitungen kommen. Es kann möglicherweise auch nicht abgeschlossen werden, wenn ein Gateway nicht korrekt konfiguriert ist, um das Paket an den nächsten Hop zu übergeben.

Wenn traceroute nicht abgeschlossen werden kann, können Sie möglicherweise herausfinden, wo es beendet wurde. Suchen Sie die letzte IP-Adresse, die in der Ausgabe von traceroute aufgeführt ist, und führen Sie eine Browsersuche nach who owns [IP_ADDRESS] durch. Es kann vorkommen, dass der Inhaber der Adresse nicht angezeigt wird, aber ein Versuch lohnt sich.

mtr

Das mtr-Tool ist eine Form von traceroute, die weiterhin aktiv ist und kontinuierlich aktualisiert wird, ähnlich wie der Befehl top für lokale Prozesse.

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.

Ausgehende IP-Adresse ermitteln

Wenn Sie die IP-Adresse nicht kennen, die von den Quell- und Zieldatenbanken für die Kommunikation miteinander verwendet wird (die ausgehende IP-Adresse), führen Sie die folgenden Schritte aus:

1. Rufen Sie in der Google Cloud consoledie Seite „SQL-Instanzen“ auf.

   Zur Seite "Cloud SQL-Instanzen"

2. Klicken Sie auf den Namen der Instanz, die mit dem Migrationsjob verknüpft ist, den Sie debuggen.

3. Scrollen Sie nach unten, bis der Bereich Verbindung zu dieser Instanz herstellen angezeigt wird. In diesem Bereich wird die ausgehende IP-Adresse angezeigt.

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.

Verbindung zum Remote-Host mit Telnet herstellen

Führen Sie den Befehl telnet aus, um zu prüfen, ob Sie mit TCP eine Verbindung zum Remote-Host herstellen können. Telnet versucht, eine Verbindung zu der von Ihnen angegebenen IP-Adresse und zum Port herzustellen.

Wenn auf dem Remote-Host beispielsweise 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.

Bei Erfolg wird Folgendes angezeigt:

Trying 35.193.198.159...

Connected to 35.193.198.159. .

Bei einem Fehler reagieren telnet nicht mehr, bis Sie die Schließung des Versuchs erzwingen:

Trying 35.193.198.159...

^C. .

Cloud Logging

Database Migration Service 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. Zu „Log-Explorer“
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
• 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. Beispiel: gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT.

Der IP-Bereich 172.17.0.0/16 ist für das Docker-Brückennetzwerk reserviert. Cloud SQL-Instanzen, die mit einer IP-Adresse in diesem Bereich erstellt werden, sind nicht erreichbar. Verbindungen von einer beliebigen IP-Adresse innerhalb dieses Bereichs zu Cloud SQL-Instanzen mit privaten IP-Adressen schlagen fehl.

VPN-Fehler beheben

Weitere Informationen finden Sie unter Google Cloud Cloud VPN-Fehlerbehebung.

Probleme mit umgekehrten SSH-Tunneln beheben

SSH-Tunneling ist eine Methode, um einen Teil der Kommunikation über eine SSH-Verbindung weiterzuleiten. Mit umgekehrtem SSH-Tunneling können Sie einen SSH-Tunnel einrichten, aber das Zielnetzwerk initiiert die Tunnelverbindung. Das ist nützlich, wenn Sie aus Sicherheitsgründen keinen Port in Ihrem eigenen Netzwerk öffnen möchten.

Sie möchten Folgendes einrichten: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Obwohl Database Migration Service Daten von einer Quelle zu einem Ziel migriert, sollten Sie die Verbindung vom Ziel zur Quelle aktivieren.

Es wird davon ausgegangen, dass:

• Die Compute Engine VM bastion kann auf die Cloud SQL DB zugreifen.

• Die source network bastion kann auf die source DB zugreifen. Das wird erreicht, indem das Cloud SQL-Netzwerk mit dem Compute Engine-VM-Netzwerk per Peering verbunden wird.

Anschließend richten Sie einen SSH-Tunnel von der source network bastion zur Compute Engine VM bastion ein, der alle eingehenden Verbindungen zu einem Port auf der Compute Engine VM bastion über den Tunnel zur source DB weiterleitet.

Jede Verbindung im obigen Szenario kann falsch eingerichtet sein und verhindern, dass der gesamte Ablauf funktioniert. Beheben Sie die Fehler für jede Verbindung einzeln:

source network bastion ---> source DB

1. Stellen Sie eine SSH-Verbindung zur source network bastion her oder verwenden Sie das Terminal, wenn es sich um den lokalen Computer handelt.
2. Testen Sie die Verbindung zur Quelldatenbank mit einer der folgenden Methoden:
   • telnet [source_db_host_or_ip] [source_db_port] - Sie sollten die MySQL-Passwortaufforderung sehen (etwa 5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection).
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] - Sie sollten eine Fehlermeldung sehen, dass der Zugriff verweigert wurde (etwa ERROR 1045 (28000): Access denied for user...)

Wenn das nicht funktioniert, müssen Sie prüfen, ob Sie den Zugriff von dieser Bastion auf die Quelldatenbank aktiviert haben.

Compute Engine VM bastion ---> source DB

1. Stellen Sie eine SSH-Verbindung zur Compute Engine VM bastion her (mit gcloud compute ssh VM_INSTANCE_NAME)
2. Testen Sie die Verbindung zur Quelldatenbank mit einer der folgenden Methoden:
   • telnet 127.0.0.1 [tunnel_port] - Sie sollten die MySQL Passwortaufforderung sehen (etwa 5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection).
   • [db_client] -h127.0.0.1 -P[tunnel_port] - Sie sollten eine Fehlermeldung sehen, dass der Zugriff verweigert wurde (etwa ERROR 1045 (28000): Access denied for user...)

Wenn das nicht funktioniert, müssen Sie prüfen, ob der Tunnel ordnungsgemäß eingerichtet und aktiv ist. Wenn Sie sudo netstat -tupln ausführen, werden alle Überwachungsprozesse auf dieser VM angezeigt. Sie sollten sshd listening on the tunnel_port sehen.

Cloud SQL DB ---> source DB

Am besten testen Sie das, indem Sie testing the migration job von Database Migration Service aus testen. Wenn das nicht funktioniert, gibt es ein Problem mit dem VPC-Peering oder dem Routing zwischen dem Cloud SQL-Netzwerk und dem Compute Engine VM bastion Netzwerk.

Die Firewall des Quelldatenbankservers muss so konfiguriert sein, dass sie den gesamten internen IP-Bereich zulässt, der für die private Dienstverbindung des VPC-Netzwerk zugewiesen ist, das die Cloud SQL-Zielinstanz als das privateNetwork-Feld ihrer ipConfiguration-Einstellungen verwendet.

So finden Sie den internen IP-Bereich in der Console:

1. Rufen Sie in der Console die Seite „VPC-Netzwerke“ auf. in der Google Cloud Console.

2. Wählen Sie das VPC-Netzwerk aus, das Sie verwenden möchten.

3. Wählen Sie Privater Dienstzugriff > Diensten zugewiesene IP-Bereiche aus.

4. Suchen Sie den internen IP-Bereich , der mit der Verbindung verknüpft ist, die von servicenetworking-googleapis-com erstellt wurde.

Sie können den Traffic zwischen der Cloud SQL-Instanz und der Compute Engine-VM-Instanz auch in der Cloud Logging Console im Cloud VPN gateway Projekt aufrufen. Suchen Sie in den Compute Engine-VM-Logs nach Traffic von der Cloud SQL-Instanz. Suchen Sie in den Logs der Cloud SQL-Instanz nach Traffic von der Compute Engine-VM.