אבחון בעיות

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

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

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

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

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

בעיות בחיבור

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

בעיות שקשורות למופע

גיבויים

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

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

ייבוא וייצוא

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

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

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

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

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

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

  • אם הייבוא קורס, יכול להיות שזה בגלל שגיאת חוסר זיכרון (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 תומך בעומסי עבודה שדורשים ביצועים גבוהים, עם עד 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.

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

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

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

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

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

  • שמירה במטמון חשובה לביצועים של קריאת נתונים. משווים את הגודל של מערך הנתונים לגודל של זיכרון ה-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.

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

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

    פתרון בעיות

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

    הודעות שגיאה

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

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

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

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

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

    מעבר לדף 'חשבונות שירות'

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

    למעבר לדף 'חשבונות IAM'

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

    מעבר לדף Crypto Keys

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

    למעבר לדף 'חשבונות IAM'


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

    מעבר לדף Crypto Keys

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

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

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

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

    מעבר לדף Crypto Keys

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

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