Google App Engine und Cloud SQL: Lost connection to MySQL server at 'reading initial communication packet'

Habe ich eine Django-app, die auf Google App Engine, die verbunden ist, um ein Google-Cloud-SQL mit dem App Engine-Authentifizierung.

Meiste Zeit funktioniert auch alles Prima, aber von Zeit zu Zeit die folgende Ausnahme ausgelöst:

OperationalError: (2013, "Lost connection to MySQL server at 'reading initial communication packet', system error: 38")

Laut die docs, dieser Fehler wird zurückgegeben, wenn:

Wenn Google Cloud SQL lehnt die Verbindung, zum Beispiel, weil die IP-Adresse Ihres client eine Verbindung herstellt, ist nicht berechtigt.

Nicht viel Sinn in meinem Fall, da die Authentifizierung erfolgt, indem die App-Engine-server.

Was könnte dazu führen, dass diese sporadischen Fehler?

  • Nur um sicherzustellen, dass Ihre Anwendung bereitgestellt wird, um die cloud richtig? Sie läuft nicht localhost?
  • ja, es ist auf der GAME cloud.
  • Ich konnte nicht genau finden viel Informationen über den Fehler 38. Aber die meisten Fehler in Bezug auf den Verlust von verbindungen zum MySQL server at 'reading initial-Befehl.. etc' zu tun hatte mit den SQL-Einstellungen, insbesondere timeouts und Autorisierung, aber diese waren alle localhost Probleme. Werfen Sie einen Blick auf das Dokument: developers.google.com/cloud-sql/docs/admin-api/v1beta1/... und sehen, ob jede Einstellung, die Sie ändern können, die auf Ihre Cloud SQL Instanz, könnte dieses Problem lösen.
  • Haben Sie Ihre app ausgeführt wird, nur auf EU Servern?
  • Danke. Ich konnte Sie nicht finden, eine Einstellung, die scheint im Zusammenhang zu meinem Problem. Die meiste Zeit funktioniert auch alles, damit ich nicht wollen, etwas zu ändern in meinem Produktionsumgebung, es sei denn, ich weiß, es löst mein Problem. Ich habe nicht darauf beschränken, meine app zu EU.
  • Ich habe das gleiche Problem von Zeit zu Zeit. Ich Laufe Django 1.5 AppEngine mit CloudSQL und erhalten die gleiche genaue Fehler gelegentlich.

InformationsquelleAutor Tzach | 2014-08-05
  1. 15

    Ich hatte ein ähnliches Problem und endete Google Kontaktieren, um Hilfe. Sie erklärten, es passiert, wenn Sie neu starten oder verschieben einer Instanz. Wenn die client-Instanz neu gestartet werden oder wurde verschoben auf einen anderen host-server (für verschiedene Versionen) die IP ' s nicht übereinstimmen und werfen diesen Fehler. Sie erwähnt, dass der Server möglicherweise neu starten, um patches, Fehler-und slow-downs verursacht ein ähnliches Verhalten (sei es die selben Fehler oder ähnliche). Der server bewegt sich auch, um zu versuchen und näher an die Instanzen zu erhöhen, Reaktionszeiten. Wenn Sie eine Anfrage senden während des Umzugs wird es Fehler auslösen.

    Sagten Sie mir ich brauche code wiederholen Fänge incase das passiert, ähnlich wie du handhaben datastore-timeouts. Halten Sie im Verstand zu bauen, die in zurück aus mechanik, senden, zu viele Anfrage zu schnell, nach einem Neustart könnte einen Absturz verursachen.

    Wie oft geschieht dies?

    • developers.google.com/cloud-sql/faq#maintenancerestart developers.google.com/appengine/articles/... en.wikipedia.org/wiki/Exponential_backoff
    • Danke, Es ist sehr interessant zu hören, Google ' s Antwort. Wir eigentlich zu tun haben-Wiederholungen in unserem code und exponentielle backoff als gut, aber vielleicht zu wenige Wiederholungen.. Wie viele Wiederholungen macht Ihr code tun und mit dem, was backoff? Habe die Wiederholungen, die das problem vollständig?
    • Für mich habe ich 3 ausscheidet, wenn es dennoch nicht, ich schickte es an eine taskqueue. Sie können höher gehen, je nachdem, ob Ihr das schlagen der globalen timeout für die Instanz. Die sehr selten bei mir schlagen die taskqueue, aber ich habe es einmal oder zweimal. Wie lange werden Sie warten und geschieht es mehr als ein paar mal im Monat, die wird es durch die Rente geht?
    • Es passiert viel mehr als zweimal im Monat.. 5 Wiederholungen mit 5 Sek Verzögerung und x2 backoff. Es ist eine sehr einfache Skalierung der Instanz also keine Globale timeout.
    • Gerade herausgefunden, dass es einige code-Bibliothek, die war nicht verpackt mit den Wiederholungen. Ich bin das hinzufügen von Wiederholungen, lasst uns warten und sehen, ob dies das problem löst.
    • Das ist eine Menge mehr, als ich immer war. Lassen Sie mich wissen, wenn die neue back-offs helfen.
    • Bisher sieht es aus wie nach hinzufügen der fehlenden Wiederholungen es das problem gelöst. Sie haben es verdient, dein bounty mit Ehre 🙂
    • Es war mir ein Vergnügen zu helfen 😉
    • *wiederholen-wrapper-Beispiel: stackoverflow.com/a/34267951/1731460

    InformationsquelleAutor Ryan
  2. 3

    In unserem Fall mussten wir umbenannt in die Instanzen falsch im code. Wenn wir wieder zurück geändert auf den richtigen Namen alles geklappt hat. Stellen Sie sicher, dass Ihre Cloud SQL Instanz ist richtig benannt, sowohl innerhalb der Google Cloud Console und innerhalb der code, den Sie verwenden, auf ihn zugreifen, und stellen Sie sicher, dass Ihre Cloud-SQL-Instanz können Sie Ihre Google App Engine-Instanz, um eine Verbindung herzustellen es ist Access control.

    • Dies steht in keinem Zusammenhang zur ursprünglichen Frage. 99% der Zeit seine Arbeit einfach gut
    InformationsquelleAutor Omar Trejo
  3. 0

    In meinem Fall das Problem verursacht wurde meine abgelaufene server-SSL-Zertifikat auf dem CloudSQL Instanz. Seltsamerweise war es nicht in der Google Cloud Console und es herausgefunden nach dem herunterladen auf das Zertifikat-und Entschlüsselung mit openssl (openssl x509 -in server-ca.pem -text -noout).

    War ich in der Lage, um herauszufinden, die Ursache des Problems nach der Verbindung mit cloud_sql_proxy; zum Glück gab es mehr aussagekräftige Fehlermeldung couldn't connect to "...": x509: certificate has expired or is not yet valid.

    Verbindung von AppEngine Standard-Anwendung zu arbeiten begann unmittelbar nach dem zurücksetzen SSL-Konfiguration von Google Cloud Console. Ich habe bemerkt, dass nach dem reset das Gültigkeitsdatum auf der Konsole erschien.

    InformationsquelleAutor Fedor
  4. -1

    Hatte ich auch dieses problem mit Django 1.10 und GAE. Die Anwendung gearbeitet, feines lokal (Verbindung der cloud-sql über cloud_sql_proxy), aber ich bekommen würde, der 38 Fehler bei der Verwendung der GAME-Instanz der Anwendung.

    Mein problem stellte sich heraus, dass meine Datenbank-Benutzer. Der user hatte einen Bindestrich drin. Einmal erstellte ich einen neuen Benutzer ohne Bindestrich und änderte meine Anwendung zu verwenden der neue Benutzer, die GAME-Instanz der Anwendung gearbeitet, wenn

    • Dies steht in keinem Zusammenhang zur ursprünglichen Frage. 99% der Zeit seine Arbeit einfach gut
    InformationsquelleAutor E Smith
Schreibe einen Kommentar