Verbindungsprobleme beheben

MySQL   |  PostgreSQL   |  PostgreSQL zu AlloyDB

Verbindungsprobleme beheben

Sie haben eine Verbindung zwischen Ihren Quell- und Zieldatenbanken eingerichtet. Woher wissen Sie aber, ob 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 „AlloyDB-Cluster“ auf.

   Seite „AlloyDB-Cluster“ aufrufen

2. Suchen Sie den Cluster, der mit dem Migrationsjob verknüpft ist, den Sie debuggen.

3. Die ausgehende IP-Adresse sollte neben dem Namen der primären Instanz des Clusters angezeigt werden.

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.

Mit Telnet eine Verbindung zum Remote-Host 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 Ihrem Remote-Host beispielsweise 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 reagieren telnet nicht mehr, 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 AlloyDB-VPC-Netzwerks akzeptiert werden.

Cloud Logging

Database Migration Service und AlloyDB 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 AlloyDB-Instanzen und andere Google Cloud Projekte wie Cloud VPN- oder Compute Engine-Instanzen aufrufen. So rufen Sie Logs für die Logeinträge Ihrer AlloyDB-Instanz auf:

Console

1. Zu „Log-Explorer“
2. Wählen Sie oben auf der Seite ein vorhandenes AlloyDB-Projekt aus.
3. Fügen Sie im Query Builder Folgendes hinzu:
• Ressource: Wählen Sie AlloyDB-Datenbank aus. Wählen Sie im Dialogfeld eine AlloyDB-Instanz aus.
• Lognamen: Scrollen Sie zum Abschnitt „AlloyDB“ und wählen Sie entsprechende Logdateien für Ihre Instanz aus. Beispiel:
  • alloydb.googlapis.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 limit Flag ist ein optionaler Parameter, der die maximale Anzahl von zurückzugebenden Einträgen anzeigt.

gcloud logging read "projects/[PROJECT_ID]/logs/alloydb.googleapis.com/postgres.log" --limit=10

VPN-Fehler beheben

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

TCP-Proxy-Fehler beheben

Auch die Einrichtung des TCP-Proxys kann Fehler verursachen. Informationen zur Fehlerbehebung bei TCP-Proxy-Fehlern finden Sie in den folgenden Beispielen für Probleme und deren Lösungen:

Fehler beim Starten der virtuellen Maschine (VM)

Beim Starten der VM-Instanz in Compute Engine wird die folgende Meldung angezeigt:

You do not currently have an active account selected.

Das können Sie versuchen

Führen Sie einen der folgenden Befehle aus, um ein aktives Konto zu konfigurieren:

• Führen Sie den folgenden Befehl aus, um neue Anmeldedaten zu erhalten:

  gcloud auth login
  

• Führen Sie den folgenden Befehl aus, um ein bereits authentifiziertes Konto auszuwählen:

  gcloud config set account ACCOUNT
  

  Ersetzen Sie ACCOUNT durch den Namen des Kontos, das Sie konfigurieren möchten.

Fehler beim Herstellen einer Verbindung zur Quelldatenbankinstanz

Beim Testen des Migrationsjobs wird die folgende Fehlermeldung angezeigt:

Failure connecting to the source database. Make sure the connectivity information on the connection profile is correct and the source database is reachable.

Das können Sie versuchen

Gehen Sie die folgenden Schritte durch, um die Ursache des Problems zu ermitteln:

1. Prüfen Sie, ob die VM, auf der der TCP-Proxy-Container gehostet wird, ausgeführt wird:

   1. Öffnen Sie in der Console die Seite Compute Engine-VM-Instanzen.

      Zu "VM-Instanzen"

   2. Suchen Sie nach der VM, die im Rahmen der Proxy-Einrichtung erstellt wurde. Wenn sie nicht aufgeführt ist oder nicht ausgeführt wird, konfigurieren Sie Ihren TCP-Proxy von Grund auf neu und aktualisieren Sie die Einstellungen der Quellinstanz im Migrationsjob mit der richtigen IP-Adresse.

2. Wenn die VM ausgeführt wird, prüfen Sie, ob beim Herunterladen des TCP-Proxy-Container-Images ein Fehler aufgetreten ist:

   1. Wählen Sie die VM aus, die im Rahmen der TCP-Proxy-Einrichtung erstellt wurde. Klicken Sie unter Logs auf Serieller Port 1 (Konsole).

   2. Wenn der Eintrag Launching user container 'gcr.io/dms-images/tcp-proxy' nicht in den Logs zu sehen ist, konnte Ihre Instanz das Image möglicherweise nicht aus Container Registry abrufen. Um zu prüfen, ob dies der Fall ist, stellen Sie eine Verbindung zur VM her und versuchen Sie, das Image manuell mit dem folgenden Befehl aus Container Registry abzurufen:

      docker pull gcr.io/dms-images/tcp-proxy

      Wenn der folgende Fehler angezeigt wird: Error response from daemon: Get "https://gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers), konnte Ihre VM keine Verbindung zu Container Registry herstellen. Wenn Ihre VM nur eine private IP-Adresse hat, müssen Sie den privaten Google-Zugriff für das Subnetz aktivieren, zu dem die IP-Adresse gehört. Andernfalls hat die VM keinen Zugriff auf Google Enterprise APIs wie Container Registry.

3. Prüfen Sie, ob der Container eine Verbindung zur Quellinstanz herstellen kann:

   1. Wählen Sie die VM aus, die im Rahmen der Proxy-Einrichtung erstellt wurde. Klicken Sie unter Logs auf Cloud Logging.

   2. Wenn die folgende Meldung angezeigt wird: Connection refused, please verify that the machine you are using to run the script can connect to the source database at, konnte der TCP-Proxy-Container keine Verbindung zur Quelldatenbankinstanz herstellen. Dafür kann es mehrere Gründe geben:

      • Die IP-Adresse der Quellinstanz ist falsch.
      • Es gibt eine Firewallrichtlinie, die Verbindungen vom TCP-Proxy zur Quellinstanz ablehnt.
      • Die Quellinstanz befindet sich in einem anderen VPC-Netzwerk (Virtual Private Cloud) als die VM, auf der der TCP-Proxy gehostet wird.

   Sie können das Verbindungsproblem mit den Konnektivitätstests von Google Cloudbeheben, um sicherzustellen, dass eine Verbindung zwischen der Zieldatenbank und der VM besteht, auf der der TCP-Proxy gehostet wird:

   1. Rufen Sie in der Console die Seite Konnektivitätstests auf.

      Zu Konnektivitätstests

   2. Klicken Sie auf Konnektivitätstest erstellen.

   3. Geben Sie einen Namen für den Test ein.

   4. Wählen Sie TCP als Protokoll aus.

   5. Wählen Sie in der Liste Quellendpunkt die Option IP-Adresse aus. Geben Sie die öffentliche IP-Adresse des neu erstellten TCP-Proxys ein, wenn die Quellendatenbank über eine öffentliche IP-Adresse zugänglich ist. Andernfalls geben Sie die private IP-Adresse des TCP-Proxys ein.

   6. Wählen Sie in der Liste Zielendpunkt die Option IP-Adresse aus und geben Sie die IP-Adresse der Quellendatenbank ein.

   7. Geben Sie im Feld Zielport die Portnummer ein, die für die Verbindung zur Quellendatenbank verwendet wird.

   8. Klicken Sie auf Erstellen.

   Führen Sie den Konnektivitätstest aus und beheben Sie alle Verbindungsprobleme, die auftreten. Nachdem Sie das Verbindungsproblem behoben haben, prüfen Sie, ob der TCP-Proxy eine Verbindung zur Quellinstanz herstellen kann:

   1. Öffnen Sie in Compute Engine die Seite VM-Instanzen.

      Zu "VM-Instanzen"

   2. Wählen Sie die VM aus, die im Rahmen der Proxy-Einrichtung erstellt wurde. Klicken Sie unter Logs auf Cloud Logging.

   3. Wenn der Logeintrag Connection to source DB verified angezeigt wird, kann der TCP-Proxy jetzt eine Verbindung zur Quellinstanz herstellen.

4. Prüfen Sie, ob der Migrationstest aufgrund von Verbindungsproblemen fehlschlägt.

Fehler beim Herstellen einer Verbindung zur Zieldatenbankinstanz

Wenn der TCP-Proxy-Container eine Verbindung zur Quellinstanz herstellen kann, der Migrationstest aber aufgrund von Verbindungsproblemen immer noch fehlschlägt, liegt das Problem möglicherweise an der Verbindung zwischen der Zielinstanz und der VM, auf der der TCP-Proxy-Container gehostet wird.

Problem beheben

Sie können das Problem mit den Google CloudKonnektivitätstests von beheben, um sicherzustellen, dass eine Verbindung zwischen der Zieldatenbank und der VM besteht, auf der der TCP-Proxy gehostet wird:

1. Rufen Sie in der Console die Seite Konnektivitätstests auf.

   Zu Konnektivitätstests

2. Klicken Sie auf Konnektivitätstest erstellen.

3. Legen Sie die folgenden Parameter für den Test fest:

   1. Geben Sie einen Namen für den Test ein.
   2. Wählen Sie TCP als Protokoll aus.
   3. Wählen Sie in der Liste Quellendpunkt die Option IP-Adresse aus und geben Sie die IP-Adresse des neu erstellten AlloyDB-Clusters ein.
   4. Wählen Sie in der Liste Zielendpunkt die Option IP-Adresse aus und geben Sie die private IP-Adresse des TCP-Proxys ein.
   5. Geben Sie im Feld Zielport die Portnummer 5432 ein.

4. Klicken Sie auf Erstellen.

5. Führen Sie den Konnektivitätstest aus und beheben Sie alle Verbindungsprobleme, die auftreten.

Mögliche Ursachen

Es gibt eine Firewallregel, die die Kommunikation zwischen der Zielinstanz und der TCP-Proxy-VM ablehnt.

Das können Sie versuchen

Fügen Sie eine Firewallregel hinzu, die der Zielinstanz die Kommunikation mit dem TCP-Proxy über Port 5432 ermöglicht.

Mögliche Ursachen

Es gibt eine VPC-Abweichung zwischen der Zielinstanz und der VM, auf der der TCP-Proxy-Container ausgeführt wird.

Das können Sie versuchen

Wählen Sie für die Zielinstanz dieselbe VPC aus.

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 kann ein SSH-Tunnel eingerichtet werden, wobei das Zielnetzwerk die Tunnelverbindung initiiert. Das ist nützlich, wenn Sie aus Sicherheitsgründen keinen Port in Ihrem eigenen Netzwerk öffnen möchten.

Sie möchten Folgendes einrichten: AlloyDB 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.

Dabei wird Folgendes vorausgesetzt:

• Das AlloyDB destination kann auf die Compute Engine VM bastion zugreifen.

• Der source network bastion kann auf die source DB zugreifen (dies wird durch Peering des AlloyDB-Netzwerks mit dem Compute Engine-VM-Netzwerk erreicht).

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 Probleme 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 Telnet Verbindungsstrings sehen, die mit Connected to x.x.x.x enden.
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] - Sie sollten die Meldung „Zugriff verweigert“ sehen.

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 (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 Telnet Verbindungsstrings sehen, die mit Connected to x.x.x.x enden.
   • [db_client] -h127.0.0.1 -P[tunnel_port] - Sie sollten die Meldung „Zugriff verweigert“ sehen.

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

AlloyDB DB ---> source DB

Am besten testen Sie das, indem Sie testing the migration job von Database Migration Service ausführen. Wenn das nicht funktioniert, gibt es ein Problem mit dem VPC-Peering oder dem Routing zwischen dem AlloyDB-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 AlloyDB-Zielinstanz als 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 Zugriff auf Dienste > 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 AlloyDB-Instanz und der Compute Engine-VM-Instanz auch in der Cloud Logging Console im Cloud VPN gateway Projekt ansehen. Suchen Sie in den Compute Engine-VM-Logs nach Traffic von der AlloyDB-Instanz. Suchen Sie in den Logs der AlloyDB-Instanz nach Traffic von der Compute Engine-VM.