Mysql: Google Cloud SQL in App Engine – Verbindungszeichenfolge veraltet?

Erstellt am 25. Sept. 2016  ·  35Kommentare  ·  Quelle: go-sql-driver/mysql

Fehlerbeschreibung

In der Readme-Datei für diesen Treiber wird die Verbindungszeichenfolge für die Verbindung mit Google Cloud SQL in App Engine wie folgt angegeben:

user@cloudsql(project-id:instance-name)/dbname

Während die Dokumentation des Cloudsql-Pakets von Google dies auch für Ihren Treiber bestätigt, gibt es Posts auf Stack Overflow wie diesen, die behaupten, dass man projectid:regionname:instancename anstelle von projectid:instancename verwenden muss.

Was ist die richtige Verbindungszeichenfolge? Beides funktioniert derzeit nicht.

Beispielcode

Einen ausführlicheren Beitrag finden Sie hier: http://stackoverflow.com/questions/39668672/trouble-connecting-to-google-cloud-sql-server-from-deployed-app

Fehlerprotokoll

Mein Server gibt eine 500-Antwort zurück, wenn ich einen Endpunkt anrufe, der die Cloud SQL-Datenbank verwendet. Die Datenbankverbindung funktioniert gut, wenn ich mich von einer lokal bereitgestellten Version meiner App mit dem Server verbinde.

Ich habe verschiedene Verbindungszeichenfolgen ausprobiert, und hier sind einige Fehler, die in der Google Cloud Console protokolliert wurden:

5447 [Warning] 'user' entry 'root<strong i="21">@localhost</strong>' ignored in --skip-name-resolve mode.

5447 [Warning] entry 'root'@'localhost' in mysql.user is ignored because it duplicates entry in mysql.system_user

14409 [Note] Aborted connection 14409 to db: 'User' user: 'root' host: 'xxx.xxx.xxx.xxx' (Got an error reading communication packets)

(In der Verbindungszeichenfolge wurde kein Kennwort angegeben, da die Dokumentation die Notwendigkeit eines Kennworts nicht angibt. In diesem Beitrag wird erwähnt, dass das Verbindungskennwort null sein muss, wenn die App versucht, mithilfe root@localhost eine Verbindung zum Server herzustellen.)

6170 [Note] Access denied for user 'root'@'cloudsqlproxy~xx.xxx.xxx.xx' (using password: NO) 

Ich habe auch versucht, mich mit einem anderen Benutzer als dem Root-Benutzer zu verbinden (Benutzername: newuser):

5447 [Warning] 'user' entry 'newuser<strong i="30">@localhost</strong>' ignored in --skip-name-resolve mode.

Aufbau

_Treiberversion (oder git SHA):_ https://github.com/go-sql-driver/mysql/tree/3654d25ec346ee8ce71a68431025458d52a38ac0

_Go-Version:_ Go-Version go1.6.2 Linux/Amd64

_Serverversion:_ Auf der Google Cloud SQL-Instanz wird MySQL 5.7 ausgeführt

_Server-Betriebssystem:_ Auf dem Tab "Compute Engine" sieht es so aus, als würde auf dem Server, auf dem die neueste Version meiner App gehostet wird, Debian 7.11 (Wheezy) ausgeführt.

documentation

Hilfreichster Kommentar

@bagatelli Stellen Sie zur Verdeutlichung sicher, dass Sie das in diesem Kommentar erwähnte Verbindungszeichenfolgenformat verwenden: http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error- with-google-cloud-sql-2nd#comment65140499_38890022

Entschuldigung für die vorherige Kürze. Wir verwenden die 2. Generation in der Produktion von Go auf App Engine ohne Probleme. Lassen Sie einfach den Parameter "tlsConfigName" weg, da der SQL-Proxy diesen hinzufügt, aber so oder so berichten sie, dass TLS jetzt sowieso unterstützt wird.

Alle 35 Kommentare

user@cloudsql (Projekt-ID:Instanzname)/Datenbankname
Ist der alte. Es funktioniert immer noch, weil ich es immer noch benutze.

Vor kurzem hat Gae damit begonnen, die Datenbank auch nach Regionen zu kategorisieren, daher das neue Format. Wenn Ihr Cloudsql in eine Region kategorisiert ist, müssen Sie das neue Format verwenden

Möglicherweise analysiert dieser Treiber das neue Format nicht richtig. Das kann das Problem sein

Betreiben Sie in Ihrem Fall einen Cloud SQL-Server der zweiten Generation?

Keine erste Generation

Ich vermute, dass der Treiber das neue Format nicht analysiert. Der Code muss möglicherweise geändert werden, damit er den Inhalt vor dem ersten Doppelpunkt und den Inhalt nach dem ersten Doppelpunkt unabhängig vom vorhandenen neuen Doppelpunkt verwendet

Es gibt eine Pull-Anfrage, die gerade „Bitte lesen“ aktualisiert

Danke für die Warnung. Ich habe gerade einen Kommentar zu dieser PR hinterlassen.
Als vorübergehende Problemumgehung werde ich einen Server der ersten Generation einrichten, bis das Treiberproblem behoben ist.

Update: Es sieht so aus, als gäbe es ein Problem mit dem Treiber, wenn eine bereitgestellte Google App Engine-Anwendung versucht, eine Verbindung zu einem Google Cloud SQL Server der zweiten Generation herzustellen.

Ich habe einen Cloud SQL Server der ersten Generation erstellt und konnte mithilfe einer bereitgestellten Google App Engine-Anwendung mit dieser Verbindungszeichenfolge erfolgreich eine Verbindung zum Server herstellen:

user@cloudsql(project-id:instance-name)/dbname

Es war kein Regionsname erforderlich.

Parsing sollte kein Problem sein, der Treiber nimmt alles zwischen den Klammern: https://github.com/go-sql-driver/mysql/blob/master/dsn.go#L282
Es wird nur in https://github.com/go-sql-driver/mysql/blob/master/driver.go#L65 verwendet

Kann jemand mit einem Cloudsql-Konto bitte den Treiber herunterladen, https://github.com/go-sql-driver/mysql/blob/master/appengine.go#L14 bearbeiten und "appengine/cloudsql" durch "google.golang.org/appengine/cloudsql" ersetzen

_Leute, als Referenz: _
Die von Google bereitgestellte Lösung zur Verbindung mit der 2. Generation ist hier:
http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error-with-google-cloud-sql-2nd

Die von Google gepostete Dokumentation war (und ist es vielleicht immer noch) falsch , aber die richtige Lösung ist dort gepostet. Wir verwenden Cloud SQL der 2. Generation ohne Probleme in der Produktion.

Gibt es dafür eine Lösung? Funktioniert definitiv nicht mit CloudSQL Second Generation.

@bagatelli siehe meinen Kommentar über deinem

@benguild Ich habe deinen Kommentar an mehreren Stellen gesehen. Sie gehen jedoch davon aus, dass jeder SSL in seinen Verbindungen verwendet, was nicht bei allen der Fall ist. Meins ist es sicher nicht. Die Fehlermeldung, die ich erhalte, lautet "Treiber: Schlechte Verbindung". Die Datenbank wird nicht einmal erreicht, weil der Treiber die Verbindungsparameter nicht richtig erkennen kann. Ich denke, das Problem liegt irgendwo in dem Durcheinander, das mit den Paketen "neue Appengine" und "alte Appengine" herrscht, was dazu führt, dass viele Dinge kaputt gehen und Google sich nicht die Mühe macht, diese Änderung richtig zu dokumentieren.

@bagatelli Stellen Sie zur Verdeutlichung sicher, dass Sie das in diesem Kommentar erwähnte Verbindungszeichenfolgenformat verwenden: http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error- with-google-cloud-sql-2nd#comment65140499_38890022

Entschuldigung für die vorherige Kürze. Wir verwenden die 2. Generation in der Produktion von Go auf App Engine ohne Probleme. Lassen Sie einfach den Parameter "tlsConfigName" weg, da der SQL-Proxy diesen hinzufügt, aber so oder so berichten sie, dass TLS jetzt sowieso unterstützt wird.

@benguild . Vielen Dank für all Ihre Bemühungen, mir bei all diesen Problemen zu helfen.
Verwenden Sie die „neue App-Engine“ oder die „alte App-Engine“? Ich habe gerade den ganzen Tag damit verbracht, meinen gesamten Code in diesen neuen Albtraum zu konvertieren, nämlich die neuen AppEngine-Pakete, und wie Sie vielleicht aus meinem anderen Beitrag wissen, kann ich meinen Code nicht mehr bereitstellen und daher nicht richtig testen, was Sie oben vorgeschlagen haben . Ich werde es erneut versuchen, sobald ich eine Lösung zum Bereitstellen meiner App gefunden habe.
Danke!

@bagatelli Wenn Sie Probleme bei der Bereitstellung haben, versuchen Sie, Ihren Code auf eine VM zu ziehen, oder verwenden Sie die Google Cloud Console.

@bagatelli Was ich sagen wollte, war ... es auf einem neuen Computer auszuprobieren oder ihre Cloud-Konsole (die bereits über die Entwicklungstools verfügt) zu verwenden, bevor Sie die Tatsache abschreiben, dass es definitiv nicht mit der Umgebung zusammenhängt.

Ich kann derzeit aufgrund eines 4 Monate alten Fehlers nicht mit macOS Sierra bereitstellen, aber wir können problemlos von einer VM aus bereitstellen.

Ich bin mir sicher, dass es mehr Arbeit für Sie ist, die Umgebung vollständig zu verlassen, also würde ich das zumindest ausschließen, bevor ich ganz aufhöre.

@pjebs . Ich bin mir nicht sicher, woher Sie diese Annahme haben, aber ich verwende keine flexible Umgebung.

@pjebs Das ist falsch. So stellen Sie derzeit den Standard bereit.

@pjebs appcfg.py update funktioniert auch.

@bagatelli Ich höre Sie – ich neige im Allgemeinen dazu, meine Abhängigkeiten von Drittanbietern und auch API-Abhängigkeiten zu minimieren, da das, was Sie sagen, wahr ist ... Google ist nicht verpflichtet, Support zu leisten, obwohl sie sonst ihren Ruf riskieren würden.

Ich bin mir nicht sicher, was genau das Problem für Sie ist (abgesehen von der Verwendung alter APIs, denke ich?), aber jede Software, die ich für App Engine entwickelt habe, habe ich auch mit der Absicht entwickelt, App Engine zu verlassen, wenn und bei Bedarf. Zum Beispiel schreibe ich für jede Google-API, mit der ich schnittstelle, einen "Helfer", der die Methoden tatsächlich aufruft und dem Rest der Anwendung seine eigenen bereitstellt, sodass und nur dieser bei Bedarf an eine neue Umgebung angepasst werden muss und [ hoffentlich], ohne den Rest der Anwendung zu beschädigen.

Für mich ist App Engine eher praktisch, da es sich um eine Umgebung handelt, die neben der Skalierung und den Einstellungen wenig Konfiguration erfordert und einige großartige APIs bietet. Es ist ärgerlich, wenn etwas schief geht, aber sie bieten Premium-Support, wenn Sie Probleme haben, von denen Sie sprechen?

@pjebs. Soweit ich weiß, ist goapp nur ein Wrapper für appcfg.py. Irgendwann wird appcfg.py aufgerufen.

@bagatelli Klar, schick mir eine E-Mail. Kein Problem

@benguild . Ich habe es endlich geschafft, meine App bereitzustellen, habe jedoch immer noch kein Glück beim Herstellen einer Verbindung zu CloudSQL.
Ich habe meine gesamte App aktualisiert, um die "new appengine"-Pakete zu verwenden, und den Import von clousql auf google.golang.org/appengine/clousql in "appengine.go" im mysql-driver-Paket festgelegt.
Ich habe dann ein Clientzertifikat aus dem CloudSQL Control Panel erstellt und meinen Code entsprechend mit RegisterTLSConfig aktualisiert, wie in der Treiberdokumentation beschrieben, wobei die tls-Konfiguration als Parameter bereitgestellt wird, wie in Ihren Beiträgen zu stackoverflow angegeben. Meine URL-Verbindung sieht so aus:

root:password@cloudsql (instance-connection-name-copy-from-cloud-console)/myDatabase?tls=customTls

Immer noch kein Glück. Fehler:

Treiber: Schlechte Verbindung

@arnehormann . Dies beantwortet Ihre Frage aus Ihrem obigen Beitrag.

@bagatelli Versuchen Sie es ohne TLS.

@benguild . Versucht ohne tls. Kein Glück.

Treiber: Schlechte Verbindung

@pjebs . Ich bin mir nicht sicher, ob Sie das Problem hier vollständig verstehen. Der Treiber erreicht nicht einmal die Datenbank. Ich verstehe, was Sie oben erwähnt haben, kann auf eine Produktionsumgebung zutreffen, aber ich kann nicht einmal eine einzige Verbindung zur Datenbank herstellen, sodass das oben Genannte in meinem Fall überhaupt nicht zutrifft.

@bagatelli Was ich tun würde, ist, wie ich es getan habe, auf Stack Overflow zu posten und es zu taggen mit: google-cloud-sql ... Jemand von Google sollte antworten, hoffe ich.

Wenn Sie dieses Problem haben, möchten sie, dass es für andere indiziert wird, die dasselbe Problem haben. Antworten Sie hier mit einem Link zu der Frage, sobald sie gelöst ist.

Höchstwahrscheinlich hat es immer noch mit Ihrer Implementierung zu tun, denn wie ich bereits sagte, verwenden die Leute die 2. Generation in der Produktion und es ist aus der Beta heraus.

@bagatelli Haben Sie daran gedacht, die Einstellung „TLS erforderlich“ für die Instanz in der Cloud Console zu deaktivieren?

Danke @benguild und @pjebs . Werde auf SO posten und hier ein Update geben, wenn ich die Ursache finde.

@benguild . Ich kann in der Cloud Console keine Erwähnung von TLS sehen

Ich denke, du meinst "Nur SSL-Verbindung zulassen". Wenn du das meinst, dann ja, es ist aus.

Ok Leute, ich habe das Problem gefunden. Und es lag weder am Treiber noch an meiner App oder CloudSQL. Das Projekt, für das ich die App bereitstelle, wurde vor vielen Jahren über die alte Entwicklerkonsole erstellt.
Auf der Registerkarte „Zugriffssteuerung“ in der Cloud Console befindet sich ein Label mit der Aufschrift „Apps in diesem Projekt: Alle autorisiert“. und wenn ein Projekt erstellt wird, erstellt es auch die standardmäßigen AppEngine- und Compute-Engine-Konten. Das Problem ist, dass dieses spezielle Projekt nicht beide Standardkonten hatte und ziemlich sicher ist, dass das das Problem ist. Was wahrscheinlich passiert ist, ist, dass Google diese Konten nicht erstellt hat, als sie AppEngine zur Cloud-Konsole migriert haben, die IAM & Admin verwendet, um Zugriffskonten zu verwalten.
Ich gehe davon aus, dass ich, als ich bemerkte, dass die Standardkonten fehlten, ein neues Projekt und eine neue Cloud-SQL-Datenbank erstellt und genau denselben Code für dieses neue Projekt und _voila_ bereitgestellt habe ... Alles funktioniert einwandfrei.
@benguild @pjebs Vielen Dank für all Ihre Bemühungen, mir bei der Lösung dieses Problems zu helfen.
@benguild Ich habe alle nicht verwandten Kommentare aus unserem vorherigen Gespräch gelöscht, da ich denke, dass wir uns in Bezug auf AppEngine/Google auf derselben Seite befinden. Werde dir dazu später eine E-Mail schicken.
Ich habe diese Frage auf StackOverflow gepostet und werde sie mit dieser Entdeckung beantworten, damit andere Personen mit demselben Problem davon profitieren können.
http://stackoverflow.com/questions/40020782/connect-to-google-sql-cloud-2nd-generation-with-go-on-appengine

Danke noch einmal!

Ja, wenn App Engine keinen Zugriff auf die SQL-Instanz hat, werden Sie ein Problem haben. 👍🏻

Behoben durch #485

Ich kann nur Danke sagen @benguild ! Sie haben mir geholfen, nach 500 geöffneten Chrome-Tabs und 5 Stunden Googeln nicht mehr mit dem Kopf gegen die Tastatur zu schlagen! Halleluja!!!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen