אבחון בעיות

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

צפייה ביומנים

כדי לראות מידע על פעולות אחרונות, אפשר לעיין ביומני הפעולות של מופע Cloud SQL או ביומני השגיאות של MySQL.

המכונה לא מגיבה

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

בעיות בחיבור

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

בעיות במופע

גיבויים

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

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

ייבוא וייצוא

ייבוא וייצוא ב-Cloud SQL זהים לשימוש בכלי mysqldump, אלא שבתכונת הייבוא והייצוא של Cloud SQL, אתם מעבירים נתונים באמצעות קטגוריה של Cloud Storage.

ייבוא ל-Cloud SQL וייצוא מ-Cloud SQL יכולים להימשך זמן רב, בהתאם לגודל הנתונים שעוברים עיבוד. יכולות להיות לכך השפעות כמו:

  • אי אפשר לעצור פעולה של מופע Cloud SQL שפועלת במשך זמן רב.
  • אפשר לבצע רק פעולת ייבוא או ייצוא אחת בכל פעם לכל מופע, וייבוא או ייצוא לזמן ארוך חוסם פעולות אחרות, כמו גיבויים יומיים אוטומטיים. ייצוא ללא שרת (serverless) מאפשר להפעיל פעולות אחרות, כולל עריכת מופעים, ייבוא, מעבר לגיבוי בעת כשל וביטול חסימה של גיבויים אוטומטיים יומיים.

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

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

נקודות נוספות שכדאי לזכור כשמייבאים:

  • אם הייבוא קורס, יכול להיות שזה בגלל שגיאת חוסר זיכרון (OOM). אם זה המצב, אפשר לנסות להשתמש ישירות בפקודות של MySQL כדי להוסיף את הפרמטרים של --extended-insert=FALSE --complete-insert. הפרמטרים האלה מאטים את מהירות הייבוא, אבל גם מפחיתים את כמות הזיכרון שנדרשת לייבוא.

לבעיות אחרות בייבוא ובייצוא, אפשר לעיין בקטע ייבוא וייצוא בדף פתרון הבעיות.

נפח דיסק

אם המופע מגיע למכסת האחסון המקסימלית המותרת, פעולות הכתיבה למסד הנתונים נכשלות. אם מוחקים נתונים, למשל על ידי השמטת טבלה, המקום שמתפנה לא משתקף בערך Storage Used (שטח האחסון בשימוש) שמופיע בדוח של המופע. הסבר על ההתנהגות הזו מופיע בשאלות הנפוצות איך אפשר לפנות את המקום שנוצר ממחיקה של טבלה?

הגעה למגבלת האחסון המקסימלית עלולה גם לגרום למופע להיתקע בהפעלה מחדש.

איך נמנעים מפגיעה בנתונים

מומלץ להימנע מעמודות שנוצרו

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

כיבויים נקיים

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

מנועי מסדי נתונים

‫InnoDB הוא מנוע האחסון היחיד שנתמך במכונות MySQL, כי הוא עמיד יותר בפני פגיעה בטבלה בהשוואה למנועי אחסון אחרים של MySQL, כמו MyISAM.

כברירת מחדל, טבלאות של מסדי נתונים ב-Cloud SQL נוצרות באמצעות מנוע האחסון InnoDB. אם התחביר של CREATE TABLE כולל אפשרות ENGINE שמציינת מנוע אחסון שאינו InnoDB, למשל ENGINE = MyISAM, הטבלה לא נוצרת ומוצגות הודעות שגיאה כמו בדוגמה הבאה:

ERROR 3161 (HY000): Storage engine MyISAM is disabled (Table creation is disallowed).

כדי להימנע מהשגיאה הזו, צריך להסיר את האפשרות ENGINE = MyISAM מהפקודה CREATE TABLE. כך נוצרת הטבלה עם מנוע האחסון InnoDB.

שינויים בטבלאות מערכת

טבלאות המערכת של MySQL משתמשות במנוע האחסון MyISAM, כולל כל הטבלאות במסד הנתונים mysql, לדוגמה mysql.user ו-mysql.db. הטבלאות האלה חשופות לסגירות לא תקינות. צריך להפעיל את הפקודה FLUSH CHANGES אחרי שמבצעים שינויים בטבלאות האלה. אם מתרחש נזק ל-MyISAM, ‏ CHECK TABLE ו-REPAIR TABLE יכולים להחזיר אתכם למצב תקין (אבל לא לשמור נתונים).

מזהי עסקאות גלובליים (GTID)

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

  • CREATE TABLE ... SELECT הצהרות;
  • CREATE TEMPORARY TABLE דפי חשבון בתוך עסקאות;
  • עסקאות או דוחות שמשפיעים על טבלאות של עסקאות וגם על טבלאות של נתונים שאינם עסקאות.

אם משתמשים בעסקה לא בטוחה מבחינת עקביות, מוצגת הודעת שגיאה כמו בדוגמה הבאה:

 Exception: SQLSTATE[HY000]: General error: 1786
 CREATE TABLE ... SELECT is forbidden when @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1.

עבודה עם טריגרים ופונקציות מאוחסנות

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

מצב מושעה

יכולות להיות סיבות שונות להשעיה של מופע Cloud SQL, כולל:

  • בעיות בחיוב

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

  • בעיות מרכזיות ב-Cloud Key Management Service

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

  • בעיות משפטיות

    לדוגמה, הפרה של Google Cloud מדיניות השימוש המקובל עלולה לגרום להשעיה של המופע. מידע נוסף מופיע בקטע 'השעיות והסרות' בתנאים ובהגבלות שלGoogle Cloud .

  • בעיות תפעוליות

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

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

משתמשי Cloud SQL עם חבילות תמיכה מסוג Platinum,‏ Gold או Silver יכולים לפנות ישירות לצוות התמיכה שלנו בנוגע למופעים מושעים. כל המשתמשים יכולים להיעזר בהנחיות הקודמות ובפורום google-cloud-sql.

ביצועים

סקירה כללית

‫Cloud SQL תומך בעומסי עבודה (workloads) שדורשים ביצועים גבוהים, עם עד 60,000 פעולות קלט/פלט (IOPS) וללא עלות נוספת עבור קלט/פלט. ביצועי ה-IOPS והתפוקה תלויים בגודל הדיסק, במספר ה-vCPU של המופע ובגודל בלוק ה-I/O, בין היתר.

הביצועים של המופע תלויים גם בסוג האחסון ובנפח העבודה.

למידע נוסף על:

הפעלת יומני שאילתות

כדי לשפר את הביצועים של השאילתות, אפשר להגדיר את Cloud SQL כך שיתעד שאילתות איטיות על ידי הוספת הדגלים של מסד הנתונים --log_output='FILE' ו---slow_query_log=on למופע. כך פלט היומן יהיה זמין באמצעות כלי הצפייה ביומנים במסוף Google Cloud . חשוב לזכור שחלים חיובים על רישום ביומן ב-Google Cloud Observability.

אל תגדירו את log_output לערך TABLE. הפעולה הזו עלולה לגרום לבעיות בחיבור, כמו שמתואר בטיפים לעבודה עם דגלים.

במדריך הזה מוסבר איך לרשום ביומן ולעקוב אחרי שאילתות איטיות ב-Cloud SQL ל-MySQL באמצעות Cloud Logging ו-Cloud Monitoring.

הפעלת מעקב אחר נעילה

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

ניגשים למופע באמצעות לקוח MySQL ומקבלים פלט של ניטור לפי דרישה:

SHOW ENGINE INNODB STATUS\G

הסברים על הקטעים בפלט של הכלי לניטור מופיעים במאמר InnoDB Standard Monitor and Lock Monitor Output.

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

שימוש בסכימת ביצועים

‫MySQL Performance Schema הוא תכונה למעקב אחרי הביצוע של שרת MySQL ברמה נמוכה. הדרך הכי נגישה לצרוך את הנתונים הסטטיסטיים שנוצרים ב-performance_schema היא באמצעות הפונקציונליות של דוחות הביצועים ב-MySQL Workbench.

שמירה על מספר סביר של טבלאות במסד הנתונים

טבלאות של מסדי נתונים צורכות משאבי מערכת. מספר גדול מדי עלול להשפיע על הביצועים והזמינות של המופע, ולגרום לכך שהמופע לא יעמוד בתנאי ה-SLA. מידע נוסף

טיפים כלליים לשיפור הביצועים

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

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

  • הוספה של נתונים למטמון חשובה לביצועי קריאה. משווים את גודל מערך הנתונים לגודל ה-RAM של המופע. מומלץ שכל מערך הנתונים יתאים ל-70% מזיכרון ה-RAM של המופע. במקרה כזה, השאילתות לא מוגבלות לביצועי קלט/פלט. אם לא, כדאי להגדיל את ה-RAM של המופע.
  • אם העומס שלכם מורכב משאילתות שדורשות הרבה משאבי CPU (מיון, ביטויים רגולריים, פונקציות מורכבות אחרות), יכול להיות שהמופע שלכם יוגבל. במקרה כזה, כדאי להגדיל את מספר ליבות ה-CPU הווירטואליות.
  • בודקים את המיקום של הקורא ומסד הנתונים – זמן האחזור משפיע על ביצועי הקריאה אפילו יותר מאשר על ביצועי הכתיבה.
  • כדאי לבדוק שיפורים בביצועים שלא ספציפיים ל-Cloud SQL, כמו הוספת אינדקס מתאים, צמצום הנתונים שנסרקים והימנעות מסיבובי הלוך ושוב מיותרים.

    • אם אתם רואים שהביצועים של שאילתות נמוכים, אתם יכולים להשתמש ב-EXPLAIN. ‫EXPLAIN היא הצהרה שמוסיפים להצהרות אחרות, כמו SELECT, והיא מחזירה מידע על האופן שבו MySQL מבצעת את ההצהרה. היא פועלת עם הפקודות SELECT,‏ DELETE,‏ INSERT,‏ REPLACE ו-UPDATE. לדוגמה, EXPLAIN SELECT * FROM myTable;.

    אפשר להשתמש ב-EXPLAIN כדי לזהות איפה אפשר:

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

    • לשפר את ORDER BY התפעול. אם הערך EXPLAIN הוא Using temporary; Using filesort בעמודה Extra של הפלט, התוצאות הזמניות מאוחסנות בקובץ ואז ממוינות, מה שבדרך כלל גורם לביצועים ירודים. במקרה כזה, צריך לבצע אחת מהפעולות הבאות:

      • אם אפשר, כדאי להשתמש באינדקסים במקום במיון. מידע נוסף זמין במאמר ORDER BY Optimization.

      • מגדילים את הגודל של המשתנה sort_buffer_size של סשן השאילתה.

      • כדי להשתמש בפחות RAM לכל שורה, צריך להגדיר את העמודות רק בגודל הנדרש.

    פתרון בעיות

    לבעיות אחרות ב-Cloud SQL, אפשר לעיין בדף פתרון בעיות.

    הודעות שגיאה

    הודעות שגיאה ספציפיות של API מפורטות בדף ההפניה הודעות שגיאה.

    פתרון בעיות שקשורות למפתחות הצפנה בניהול הלקוח (CMEK)

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

    טבלת פתרון בעיות שקשורות למפתחות הצפנה בניהול הלקוח

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

    עוברים לדף Service Accounts.

    אי אפשר לתת גישה לחשבון השירות לחשבון המשתמש אין הרשאה להעניק גישה לגרסה הזו של המפתח. מוסיפים את התפקיד Organization Administrator לחשבון המשתמש או לחשבון השירות.

    לדף IAM Accounts

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

    מעבר לדף Crypto Keys

    אין מספיק הרשאות לשימוש במפתח Cloud KMS התפקיד cloudkms.cryptoKeyEncrypterDecrypter חסר אצל המשתמש או בחשבון השירות שמשמשים להפעלת פעולות במופעי Cloud SQL, או שגרסת מפתח Cloud KMS לא קיימת. בפרויקט Google Cloud שבו מאוחסן המפתח, מוסיפים את התפקיד cloudkms.cryptoKeyEncrypterDecrypter למשתמש או לחשבון השירות.

    לדף IAM Accounts


    אם התפקיד כבר הוענק לחשבון שלכם, במאמר יצירת מפתח מוסבר איך ליצור גרסה חדשה של מפתח. ראו הערה.
    מפתח Cloud KMS לא נמצא גרסת המפתח לא קיימת. יוצרים גרסה חדשה של המפתח. איך יוצרים מפתח ראו הערה.
    אי אפשר לגשת למפתח EKM אי אפשר לגשת למפתח External Key Manager (EKM) במשך כמה שעות. גם אחרי כמה ניסיונות חוזרים, אי אפשר לגשת למפתח ה-EKM. צריך לבדוק את סטטוס החיבור של EKM ולפתור את הבעיה עם ספק EKM.

    מעבר לדף Crypto Keys

    מופע Cloud SQL וגרסת מפתח Cloud KMS נמצאים באזורים שונים גרסת המפתח של Cloud KMS והמופע של Cloud SQL חייבים להיות באותו אזור. היא לא פועלת אם גרסת המפתח של Cloud KMS נמצאת באזור גלובלי או במספר אזורים. יוצרים גרסת מפתח באותו אזור שבו רוצים ליצור מכונות. איך יוצרים מפתח ראו הערה.
    גרסת המפתח של Cloud KMS משוחזרת, אבל המופע עדיין מושעה כמה דקות לאחר מכן. תהליך האימות הפנימי של המופע יכול להימשך עד 10 דקות לפני שהמופע יהיה זמין שוב. ממתינים 10 דקות עד שהמופע יהיה זמין.
    גרסת המפתח של Cloud KMS משוחזרת, אבל המופע עדיין מושעה יותר מ-10 דקות לאחר מכן. גרסת המפתח מושבתת או שלא מעניקה את ההרשאות המתאימות. מפעילים מחדש את גרסת המפתח ומעניקים את התפקיד cloudkms.cryptoKeyEncrypterDecrypter למשתמש או לחשבון השירות בפרויקט Google Cloud שבו מתארח המפתח.

    טבלת פתרון בעיות בהצפנה מחדש

    לשגיאה הזו... יכול להיות שהבעיה היא... אפשר לנסות את הפעולות הבאות…
    ההצפנה מחדש של משאב CMEK נכשלה כי אין גישה למפתח Cloud KMS. חשוב לוודא שהגרסה של המפתח הראשי מופעלת ושההרשאה ניתנה בצורה תקינה. הגרסה של המפתח מושבתת או שלא מעניקה את ההרשאות המתאימות.

    מפעילים מחדש את גרסת המפתח של Cloud KMS:

    לדף Crypto Keys

    בפרויקט Google Cloud שבו מאוחסן המפתח, מוודאים שהתפקיד cloudkms.cryptoKeyEncrypterDecrypter הוקצה למשתמש או לחשבון השירות:

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