Mysql: Google Cloud SQL on App Engine - سلسلة الاتصال قديمة؟

تم إنشاؤها على ٢٥ سبتمبر ٢٠١٦  ·  35تعليقات  ·  مصدر: go-sql-driver/mysql

وصف المشكلة

في الملف التمهيدي لبرنامج التشغيل هذا ، يتم تقديم سلسلة الاتصال للاتصال بـ Google Cloud SQL على App Engine على النحو التالي:

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

بينما تؤكد وثائق حزمة cloudql من Google هذا أيضًا لبرنامج التشغيل الخاص بك ، هناك منشورات على Stack Overflow مثل هذه التي تدعي أن المرء يحتاج إلى استخدام projectid:regionname:instancename بدلاً من projectid:instancename .

ما هي سلسلة الاتصال الصحيحة؟ لا يعمل أي من هذه حاليا.

مثال على الكود

يمكن العثور على مشاركة أكثر تفصيلاً هنا: http://stackoverflow.com/questions/39668672/trouble-connecting-to-google-cloud-sql-server-from-deployed-app

سجل الخطأ

يعرض خادمي استجابة 500 عندما أجري اتصالاً بنقطة نهاية تستخدم قاعدة بيانات Cloud SQL. يعمل اتصال قاعدة البيانات بشكل جيد عندما أقوم بالاتصال بالخادم من إصدار يتم تقديمه محليًا من تطبيقي.

لقد جربت مجموعة متنوعة من سلاسل الاتصال ، وإليك بعض الأخطاء التي تم تسجيلها في Google Cloud Console:

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)

(لم يتم تحديد كلمة مرور في سلسلة الاتصال لأن الوثائق لا تحدد الحاجة إلى كلمة مرور. يذكر هذا المنشور أن كلمة مرور الاتصال يجب أن تكون فارغة عندما يحاول التطبيق الاتصال بالخادم باستخدام root@localhost .)

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

حاولت أيضًا الاتصال بمستخدم آخر غير المستخدم الجذر (اسم المستخدم: مستخدم جديد):

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

إعدادات

_ إصدار السائق (أو بوابة SHA): _ https://github.com/go-sql-driver/mysql/tree/3654d25ec346ee8ce71a68431025458d52a38ac0

_Go الإصدار: _ go version go1.6.2 linux / amd64

_ إصدار الخادم: _ يقوم مثيل Google Cloud SQL بتشغيل MySQL 5.7

_Server OS: _ من علامة التبويب Compute Engine ، يبدو أن الخادم الذي يستضيف أحدث إصدار من تطبيقي يعمل بنظام Debian 7.11 (Wheezy)

documentation

التعليق الأكثر فائدة

bagatelli للتوضيح ، تأكد من استخدام تنسيق سلسلة الاتصال المذكور في هذا التعليق: http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error- مع google-cloud-sql-2nd # comment65140499_38890022

آسف للإيجاز السابق. نحن نستخدم الجيل الثاني في الإنتاج من Go on App Engine بدون مشكلة. فقط اترك معلمة "tlsConfigName" لأن وكيل SQL سيضيف ذلك ، ولكن في كلتا الحالتين يبلغون أن TLS مدعوم الآن على أي حال.

ال 35 كومينتر

user @ cloudql (معرّف المشروع: اسم المثيل) / dbname
هو القديم. لا يزال يعمل لأنني ما زلت أستخدمه.

بدأ gae مؤخرًا في تصنيف قاعدة البيانات إلى مناطق أيضًا ومن هنا جاء التنسيق الجديد. إذا تم تصنيف cloudql الخاصة بك إلى منطقة ، فستحتاج إلى استخدام التنسيق الجديد

ربما لا يقوم برنامج التشغيل هذا بتحليل التنسيق الجديد بشكل صحيح. وهذا قد يكون قضية

في حالتك ، هل تقوم بتشغيل خادم Cloud SQL من الجيل الثاني؟

لا الجنرال الأول

أظن أن السائق لا يقوم بتحليل التنسيق الجديد. قد تحتاج الشفرة إلى التغيير بحيث تأخذ المحتوى قبل النقطتين الأولى والمحتوى بعد القولون الأول بغض النظر عن القولون الجديد الموجود

هناك طلب سحب يتم تحديثه حاليًا اقرأ لي

وذلك بفضل لرؤساء متابعة. لقد تركت للتو تعليقًا على ذلك العلاقات العامة.
كحل مؤقت ، سأقوم بإعداد خادم الجيل الأول حتى يتم إصلاح مشكلة برنامج التشغيل.

تحديث: يبدو أن هناك مشكلة في برنامج التشغيل عندما يحاول تطبيق Google App Engine المنشور الاتصال بالجيل الثاني من Google Cloud SQL Server.

لقد أنشأت الجيل الأول من Cloud SQL Server وتمكنت من الاتصال بالخادم بنجاح باستخدام تطبيق Google App Engine المنشور باستخدام سلسلة الاتصال هذه:

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

لم يكن مطلوب اسم المنطقة.

لا ينبغي أن يكون التحليل مشكلة ، فالسائق يأخذ كل شيء بين الأقواس: https://github.com/go-sql-driver/mysql/blob/master/dsn.go#L282
يتم استخدامه فقط في https://github.com/go-sql-driver/mysql/blob/master/driver.go#L65

هل يمكن لشخص لديه حساب cloudql ، يرجى تنزيل برنامج التشغيل ، وتعديل https://github.com/go-sql-driver/mysql/blob/master/appengine.go#L14 واستبدال "appengine/cloudsql" بـ "google.golang.org/appengine/cloudsql" جربها بالإصدار القديم والجديد مع المنطقة وبدونها وأبلغ ما الذي يعمل؟ شكرا!

_الرجال ، كمرجع: _
الحل الذي قدمته Google للاتصال بالجيل الثاني موجود هنا:
http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error-with-google-cloud-sql-2nd

كانت وثائق Google المنشورة (وربما لا تزال) خاطئة ، ولكن تم نشر الحل الصحيح هناك. نحن نستخدم الجيل الثاني من Cloud SQL في الإنتاج بدون مشاكل.

هل هناك حل لهذا؟ بالتأكيد لا يعمل مع CloudSQL Second Generation.

bagatelli انظر تعليقي فوق تعليقاتك

benguild لقد رأيت تعليقك في أماكن متعددة. ومع ذلك ، فأنت تفترض أن الجميع يستخدمون طبقة المقابس الآمنة في اتصالاتهم وهذا ليس هو الحال بالنسبة للجميع. بالتأكيد ليس لي. رسالة الخطأ التي أحصل عليها هي "برنامج التشغيل: اتصال غير صالح". لم يتم الوصول إلى قاعدة البيانات لأن برنامج التشغيل لا يمكنه التعرف على معلمات الاتصال بشكل صحيح. أعتقد أن المشكلة تكمن في مكان ما في الفوضى التي كانت موجودة مع حزم "appengine الجديدة" و "محرك التطبيقات القديم" والتي تتسبب في تعطل الكثير من الأشياء ولا تهتم Google بتوثيق هذا التغيير بشكل صحيح.

bagatelli للتوضيح ، تأكد من استخدام تنسيق سلسلة الاتصال المذكور في هذا التعليق: http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error- مع google-cloud-sql-2nd # comment65140499_38890022

آسف للإيجاز السابق. نحن نستخدم الجيل الثاني في الإنتاج من Go on App Engine بدون مشكلة. فقط اترك معلمة "tlsConfigName" لأن وكيل SQL سيضيف ذلك ، ولكن في كلتا الحالتين يبلغون أن TLS مدعوم الآن على أي حال.

تضمين التغريدة نشكرك على كل ما تبذلونه من جهود في مساعدتي في كل هذه القضايا.
هل تستخدم "محرك التطبيقات الجديد" أم "محرك التطبيقات القديم"؟ لقد أمضيت اليوم للتو في تحويل كل الكود الخاص بي إلى هذا الكابوس الجديد وهو حزم appengine الجديدة ، وكما تعلم من رسالتي الأخرى ، لم يعد بإمكاني نشر الكود الخاص بي ، وبالتالي لا يمكنني اختبار ما اقترحته أعلاه بشكل صحيح . سأحاول مرة أخرى بمجرد أن أجد حلاً لنشر تطبيقي.
شكرا لك!

bagatelli إذا كنت تواجه مشكلة في النشر ، فحاول سحب الرمز الخاص بك إلى جهاز افتراضي أو استخدم Google Cloud Console.

bagatelli ما كنت أقوله هو ... لتجربته على جهاز جديد ، أو استخدام وحدة التحكم السحابية (التي تحتوي على أدوات التطوير بالفعل) قبل شطب حقيقة أنها بالتأكيد لا علاقة لها بالبيئة.

لا يمكنني حاليًا النشر باستخدام macOS Sierra نظرًا لوجود خطأ عمره 4 أشهر ، ولكن يمكننا النشر بشكل جيد من جهاز افتراضي.

أنا متأكد من أن الأمر يتطلب المزيد من الجهد بالنسبة لك للتخلص من البيئة تمامًا ، لذا سأكون على الأقل متأكدًا من استبعاد ذلك قبل الإقلاع تمامًا.

تضمين التغريدة لست متأكدًا من أين حصلت على هذا الافتراض ولكني لا أستخدم بيئة مرنة.

pjebs هذا غير صحيح. هذه هي الطريقة التي يتم نشرها حاليًا وفقًا للمعيار.

pjebs appcfg.py update يعمل أيضًا.

bagatelli أسمعك - أميل عمومًا إلى تقليل تبعيات الطرف الثالث وأيضًا تبعيات واجهة برمجة التطبيقات لأن ما تقوله صحيح ... Google ليست ملزمة بتقديم الدعم ، على الرغم من أنها قد تخاطر بسمعتها بخلاف ذلك.

لست متأكدًا مما هي المشكلة حاليًا بالنسبة لك بالضبط (إلى جانب استخدام واجهات برمجة التطبيقات القديمة ، على ما أعتقد؟) ، ولكن كل جزء من البرامج التي قمت بتطويرها من أجل App Engine قمت أيضًا بتطويره بهدف الخروج من App Engine إذا وعند الحاجة. على سبيل المثال ، بالنسبة إلى كل واجهة Google API I ، أكتب "المساعد" لذلك يستدعي الأساليب ويوفر طرقًا خاصة به لبقية التطبيق بحيث يحتاج فقط إلى تعديل لبيئة جديدة عند الضرورة و [ نأمل] دون كسر بقية التطبيق.

بالنسبة لي ، يعد App Engine أكثر ملاءمة لأنه بيئة تتطلب القليل من التكوين إلى جانب التوسع والتفضيلات ، وتوفر بعض واجهات برمجة التطبيقات الرائعة. إنه أمر مزعج عندما يحدث خطأ ما ، لكنهم يقدمون دعمًا متميزًا إذا كانت لديك مشكلات مثل ما تتحدث عنه؟

تضمين التغريدة كما أفهم ، فإن goapp مجرد غلاف لـ appcfg.py. سينتهي الأمر باستدعاء appcfg.py في مرحلة ما.

bagatelli بالتأكيد ، أرسل لي بريدًا إلكترونيًا. لا مشكلة

تضمين التغريدة تمكنت أخيرًا من نشر تطبيقي ، ولكن لم يحالفني الحظ في الاتصال بـ CloudSQL.
لقد قمت بتحديث تطبيقي بالكامل لاستخدام حزم "appengine الجديدة" بالإضافة إلى تعيين استيراد clousql إلى google.golang.org/appengine/clousql في "appengine.go" في حزمة mysql-driver.
قمت بعد ذلك بإنشاء شهادة عميل من لوحة تحكم CloudSQL وقمت بتحديث الكود الخاص بي وفقًا لذلك باستخدام RegisterTLSConfig كما هو موضح في وثائق برامج التشغيل التي توفر تكوين tls كمعامل كما هو مذكور في مشاركاتك على stackoverflow. يبدو اتصال url الخاص بي كما يلي:

الجذر: كلمة المرور @ cloudql (مثيل اتصال اسم نسخ من وحدة تحكم سحابة) / myDatabase؟ tls = customTls

لم يحالفنا الحظ بعد. خطأ:

السائق: اتصال سيء

تضمين التغريدة هذا يجيب على سؤالك من منشورك أعلاه.

bagatelli جربها بدون TLS.

تضمين التغريدة حاولت بدون tls. لا حظ.

السائق: اتصال سيء

تضمين التغريدة لست متأكدًا مما إذا كنت تفهم المشكلة تمامًا هنا. السائق لا يصل حتى إلى قاعدة البيانات. أفهم أن ما ذكرته أعلاه قد يكون صحيحًا في بيئة الإنتاج ولكني لست قادرًا حتى على إنشاء اتصال واحد بقاعدة البيانات ، لذلك في حالتي لا ينطبق ما سبق على الإطلاق.

bagatelli ما سأفعله هو النشر على Stack Overflow كما فعلت ووضع علامة عليه بـ: google-cloud-sql ... يجب أن يرد شخص ما من Google ، كما آمل.

إذا كنت تواجه هذه المشكلة ، فقد يرغبون في فهرستها للآخرين الذين لديهم نفس المشكلة. قم بالرد هنا مع رابط إلى السؤال بمجرد حله.

على الأرجح لا يزال الأمر متعلقًا بالتنفيذ الخاص بك لأنه كما قلت ، يستخدم الناس الجيل الثاني في الإنتاج وهو خارج الإصدار التجريبي.

bagatelli هل تذكرت إيقاف تشغيل إعداد "TLS Required" للمثيل في Cloud Console؟

شكرا benguild و pjebs . سوف أنشر على SO وأعطي تحديثًا هنا إذا وجدت السبب.

تضمين التغريدة لا يمكنني رؤية أي إشارة إلى TLS في وحدة التحكم السحابية

أعتقد أنك تقصد "السماح باتصال SSL فقط". إذا كان هذا هو ما تتحدث عنه ، فحينئذٍ نعم ، تم إيقافه.

حسنًا يا رفاق ، لقد وجدت المشكلة. ولم يكن هو السائق أو تطبيقي أو CloudSQL. تم إنشاء المشروع الذي أنشر التطبيق فيه منذ سنوات عديدة من خلال وحدة تحكم المطورين القديمة.
في علامة التبويب التحكم في الوصول في Cloud Console ، هناك تسمية تقول "التطبيقات في هذا المشروع: جميعها مرخصة". وعندما يتم إنشاء المشروع فإنه يقوم أيضًا بإنشاء محرك التطبيقات الافتراضي وحساب حسابات المحرك. تكمن المشكلة في أن هذا المشروع بالذات لم يكن لديه كلا الحسابين الافتراضيين ومن المؤكد أن هذه هي المشكلة. ما حدث على الأرجح هو أن Google لم تنشئ هذه الحسابات عندما قامت بترحيل appengine إلى وحدة التحكم السحابية التي تستخدم IAM & Admin لإدارة حسابات الوصول.
أفترض ذلك لأنني عندما لاحظت الحسابات الافتراضية المفقودة ، قمت بإنشاء مشروع جديد وقاعدة بيانات سحابية جديدة SQL ونشرت نفس الكود بالضبط في هذا المشروع الجديد و _voila _... كل شيء يعمل بشكل جيد.
benguildpjebs نقدر حقًا كل جهودك لمساعدتي في معالجة هذه المشكلة.
benguild لقد حذفت جميع التعليقات غير ذات الصلة من محادثتنا السابقة حيث أعتقد أننا على نفس الصفحة المتعلقة بـ AppEngine / Google. سوف نرسل لك بريدًا إلكترونيًا بشأن ذلك لاحقًا.
لقد قمت بنشر هذا السؤال على StackOverflow وسأجيب عليه بهذا الاكتشاف حتى يستفيد منه الأشخاص الآخرون الذين يعانون من نفس المشكلة.
http://stackoverflow.com/questions/40020782/connect-to-google-sql-cloud-2nd-generation-with-go-on-appengine

شكرا لك مرة أخرى!

نعم ، إذا لم يكن لدى App Engine إمكانية الوصول إلى مثيل SQL ، فستواجه مشكلة. 👍🏻

ثابت ب # 485

كل ما يمكنني قوله هو الشكر benguild ! لقد ساعدتني في التوقف عن ضرب رأسي بلوحة المفاتيح بعد 500 علامة تبويب كروم مفتوحة و 5 ساعات من البحث على Google! الحمد لله!!!

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات