בעיות מוכרות

בדף הזה מפורטות בעיות מוכרות ב-Cloud SQL ל-MySQL, ומוסבר איך אפשר להימנע מהן או לפתור אותן.

אם נתקלתם בבעיות במופע, חשוב לעיין גם בהנחיות התפעוליות ובמידע שבקטע אבחון בעיות.

בעיות בזמינות ובעמידות של נתונים

  • עמודות שנוצרו (רק במכונות MySQL 5.7)

    בגלל בעיה ב-MySQL, שימוש בעמודות שנוצרו עשוי לגרום לשיבוש בנתונים. מידע נוסף זמין במאמר MySQL bug #82736.

בעיות בחיבור למופע

  • אישורי SSL/TLS שפג תוקפם

    אם המופע מוגדר לשימוש ב-SSL, עוברים אל הדף Cloud SQL Instances במסוף Google Cloud ופותחים את המופע. פותחים את הדף Connections (חיבורים), בוחרים בכרטיסייה Security (אבטחה) ומוודאים שאישור השרת תקף. אם התוקף שלו פג, צריך להוסיף אישור חדש ולעבור אליו.

  • גרסת שרת proxy ל-Cloud SQL Auth

    אם אתם מתחברים באמצעות שרת proxy ל-Cloud SQL Auth, ודאו שאתם משתמשים בגרסה העדכנית ביותר. מידע נוסף זמין במאמר שמירה על עדכניות של Cloud SQL Auth Proxy.

  • אין הרשאה להתחבר

    אם מנסים להתחבר למופע שלא קיים בפרויקט, הודעת השגיאה תציין רק שאין לכם הרשאה לגשת למופע הזה.

  • אי אפשר ליצור מכונה של Cloud SQL

    אם מופיעה הודעת השגיאה Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID], נסו ליצור שוב את מכונת Cloud SQL.

בעיות אדמיניסטרטיביות

  • בכל מופע אפשר להריץ רק פעולת ייבוא או ייצוא אחת של Cloud SQL לטווח ארוך בכל פעם. כשמתחילים פעולה, חשוב לוודא שלא צריך לבצע פעולות אחרות במופע. בנוסף, כשמתחילים את הפעולה, אפשר לבטל אותה.

  • מערכת MySQL מבצעת אישור אוטומטי (auto-commit) בכל הצהרת DDL. ‫Cloud SQL שומר את כל השלבים של הייבוא עד לביטול המכונה. לכן, יכול להיות שתצטרכו לנקות את הנתונים במופע באופן ידני.

בעיות בייבוא ובייצוא של נתונים

  • בייצוא CSV, הערכים NULL ושורות חדשות לא מפורמטים בצורה נכונה.

    כשמייצאים נתונים כ-CSV באמצעות תכונת הייצוא של Cloud SQL, ערכי NULL מיוצאים כ-"N, מה שעלול לגרום לקובץ ה-CSV להכיל מרכאות לא מאוזנות. בנוסף, אם נתוני הטקסט מכילים תו של שורה חדשה, מתווסף סימן מירכאות בסוף השורה.

    כשמייבאים קובץ שייצאתם באמצעות תו בריחה שמוגדר כברירת מחדל, המערכת מתייחסת לערך כאל "NULL" במקום NULL. כדי לשנות את ברירת המחדל כשמייצאים את הקובץ, משתמשים ב---escape="5C".

  • ההגדרה של מצב SQL משפיעה על האופן שבו Cloud SQL מפרש שאילתות SQL.

    לדוגמה, אם מייצאים ממסד נתונים בלי להפעיל את Strict SQL, ואז מנסים לייבא ל-Cloud SQL (שבו Strict SQL מופעל כברירת מחדל), יכול להיות שהייבוא ייכשל. השיטה המומלצת היא להשתמש באותו מצב SQL בייבוא כמו בייצוא.

  • הסעיף DEFINER עלול לגרום לכשל בייבוא

    סעיף DEFINER עלול לגרום לכשל בפעולת ייבוא אם המשתמש שהוגדר ב-DEFINER הוא משתמש SUPER או משתמש מערכת, והוא שונה מהמשתמש שמבצע את הייבוא ל-Cloud SQL. מידע נוסף על השימוש ב-DEFINER ופתרונות אפשריים ב-Cloud SQL

  • אם אתם מנסים לייבא ולייצא נתונים ממסד נתונים גדול (לדוגמה, מסד נתונים עם 500GB של נתונים או יותר), יכול להיות שפעולות הייבוא והייצוא יימשכו זמן רב. בנוסף, לא תוכלו לבצע פעולות אחרות (לדוגמה, פעולת הגיבוי) בזמן הייבוא או הייצוא. אפשרות פוטנציאלית לשיפור הביצועים של תהליך הייבוא והייצוא היא שחזור גיבוי קודם באמצעות gcloud או ה-API.

  • ב-Cloud Storage יש תמיכה ב גודל אובייקט יחיד של עד חמישה טביבייט (5 TiB). מכיוון ש-Cloud SQL דוחס את הנתונים לפני ההעלאה ל-Cloud Storage, פעולת ייצוא נכשלת רק אם הגודל הדחוס של קובץ הייצוא חורג מ-5 TiB.

    יחס הדחיסה תלוי בסוגי הנתונים במסד הנתונים. לדוגמה, נתוני טקסט נדחסים טוב יותר מנתונים בינאריים כמו BLOB. לכן, יכול להיות שייצוא של מסד נתונים או טבלה בגודל של יותר מ-5 TiB לא ייכשל אם הנתונים ניתנים לדחיסה גבוהה, אבל ייצוא של נתונים לא דחוסים שמתקרבים ל-5 TiB עלול להיכשל.

    אם מבצעים פעולת ייצוא רגילה, בדרך כלל Cloud SQL יוצר קובץ ייצוא יחיד. אם משתמשים בייצוא מקביל, Cloud SQL יוצר כמה קובצי ייצוא. בייצוא מסוג כזה, פעולת הייצוא נכשלת אם יש טבלה גדולה מספיק כך שקובץ הייצוא הדחוס שלה חורג מ-5 TiB.

    אם הייצוא נכשל בגלל המגבלה של 5 TiB, צריך לפצל את הייצוא לפלחים קטנים יותר. אם אתם משתמשים בייצוא רגיל ונתקלתם במגבלה הזו, כדאי לעבור לייצוא מקביל.

יומני עסקאות וגידול בנפח האחסון בדיסק

היומנים נמחקים פעם ביום, ולא באופן רציף. אם מספר הימים של שמירת היומן מוגדר להיות זהה למספר הגיבויים, יכול להיות שיום של רישום ביומן יאבד, בהתאם למועד הגיבוי. לדוגמה, אם מגדירים את שמירת היומנים ל-7 ימים ואת שמירת הגיבויים ל-7 גיבויים, היומנים יישמרו למשך 6 עד 7 ימים.

מומלץ להגדיר את מספר הגיבויים כך שיהיה לפחות אחד יותר ממספר הימים של שמירת היומנים, כדי להבטיח שמירה של היומנים למשך מספר הימים שצוין.

בעיות בשדרוג מופע MySQL

אם אתם משתמשים ב-Database Migration Service כדי לשדרג את מופע MySQL מגרסה 5.7 לגרסה 8.0, ויש לכם פרוצדורות מאוחסנות שנוצרו במסד הנתונים בשם mysql במופע גרסה 5.7, יכול להיות שהפרוצדורות המאוחסנות לא יועתקו למסד הנתונים mysql במופע המשודרג של גרסה 8.0. בנוסף, יכול להיות שלא תוכלו ליצור פרוצדורות מאוחסנות במסד הנתונים mysql במופע המשודרג.

בעיות בדחיסת דפים ב-InnoDB

דחיסת דפים ב-InnoDB יכולה לשפר את הביצועים של שאילתות עדכון על ידי צמצום כמות הנתונים שצריך לקרוא ולכתוב בדיסק. עם זאת, דחיסת דפים יכולה להשפיע על הביצועים של שאילתות עדכון בטבלאות שמתעדכנות לעיתים קרובות. כדי להעריך את ההשפעה של דחיסת הדף על שאילתות העדכון, אפשר להריץ בדיקת ביצועים עם דחיסת הדף ובלי דחיסת הדף. כך תוכלו לראות איך דחיסת הדפים משפיעה על הביצועים של עומס העבודה.

כדי לשפר את ביצועי הדחיסה של הדף, אפשר:

  • משתמשים באלגוריתם דחיסה שמתאים לסוג הנתונים. לדוגמה, משתמשים ב-LZ4 לנתוני טקסט וב-ZLIB לנתונים בינאריים.

  • לא מומלץ להשתמש בדחיסה לנתונים שמתעדכנים לעיתים קרובות. דחיסה ופריסה של נתונים עלולות להאט את שאילתות העדכון.

בעיות שקשורות ל-Cloud Monitoring או ל-Cloud Logging

מקרים שבהם שמות האזורים הבאים מוצגים בצורה שגויה בהקשרים מסוימים:

  • הערך us-central1 מוצג כ-us-central
  • הערך europe-west1 מוצג כ-europe
  • הערך asia-east1 מוצג כ-asia

הבעיה הזו מתרחשת בהקשרים הבאים:

  • התראות ב-Cloud Monitoring
  • Metrics Explorer
  • Cloud Logging

כדי לפתור את הבעיה ב-Alerting ב-Cloud Monitoring וב-Metrics Explorer, אפשר להשתמש בתוויות של מטא-נתונים של משאבים. במקום תווית המשאב המפוקח cloudsql_database ‏[region], צריך להשתמש בתווית המטא-נתונים של המערכת region.