אבחון בעיות

בדף הזה מפורטות הבעיות הנפוצות ביותר שאתם עלולים להיתקל בהן כשאתם עובדים עם מכונות 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 של המכונה. הסבר על ההתנהגות הזו מופיע בשאלות הנפוצות, בקטע How can I reclaim the space from a dropped table?‎.

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

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

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

בגלל בעיה ב-MySQL, שימוש בעמודות שנוצרו עלול לגרום לפגיעה בנתונים. למידע נוסף, קראו את באג מספר 82736 ב-MySQL.

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

כש-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 של המכונה ובגודל הבלוק של הקלט/פלט, בין גורמים אחרים.

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

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

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

כדי לשפר את הביצועים של השאילתות, אתם יכולים להגדיר את 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 היא תכונה למעקב אחרי הביצועים של שרת MySQL ברמה נמוכה. הדרך הנגישה ביותר לצרוך את הנתונים הסטטיסטיים שנוצרו ב-performance_schema היא באמצעות הפונקציונליות של דוחות הביצועים של MySQL Workbench.

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

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

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

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

אם שאילתות SELECT של מסד הנתונים איטיות, כדאי לבדוק את הדברים הבאים:

  • שמירה במטמון חשובה לביצועי הקריאה. משווים בין הגודל של מערך הנתונים לבין גודל ה-RAM של המכונה. באופן אידיאלי, כל מערך הנתונים מתאים ל-70% מה-RAM של המכונה, ובמקרה כזה השאילתות לא מוגבלות לביצועי קלט/פלט. אם לא, כדאי להגדיל את נפח ה-RAM של המכונה.
  • אם עומס העבודה כולל שאילתות שדורשות שימוש אינטנסיבי במעבד (CPU) (מיון, ביטויים רגולריים, פונקציות מורכבות אחרות), יכול להיות שהמכונה תוגבל. במקרה כזה, צריך להגדיל את מספר המעבדים הווירטואליים (vCPU).
  • בדקו את המיקום של הקורא ומסד הנתונים – זמן האחזור משפיע על ביצועי הקריאה אפילו יותר מאשר על ביצועי הכתיבה.
  • לבדוק שיפורים בביצועים שלא ספציפיים ל-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. אתם יכולים להיעזר בטבלה הבאה כדי לאבחן ולפתור בעיות נפוצות.

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

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

    כניסה לדף 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.

    אם המכונה מושעית כי המפתח לא זמין, אבל המפתח מוצג כפעיל וזמין במסוף Google Cloud , כנראה שהבעיה היא בחיבור או באימות של ה-EKM.    		 בודקים את סטטוס החיבור של ה-EKM ופותרים את הבעיה מול ספק ה-EKM.
    • מוודאים שיומני הביקורת של Cloud KMS Data Access מופעלים בפרויקט.
    • כדי לראות את השגיאה הספציפית שהוחזרה על ידי ספק ה-EKM, צריך לחפש ביומני הביקורת של Cloud פעולות Decrypt שנכשלו.
    • בודקים את היומנים הפנימיים של מנהל המפתחות החיצוני (לדוגמה, יומני המכשיר של Thales) כדי לראות אם יש ניתוקים או כשלים באימות של אסימון האינטרנט בפורמט JSON‏ (JWT). בודקים את כללי חומת האש של הרשת כדי לוודא שה-EKM יכול להתחבר לאינטרנט ולהוריד את אישורי האימות הציבוריים של Google.

    כניסה לדף 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.