פתרון בעיות ב-Cloud SQL

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

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

כדאי לבדוק אם השאלה או הבעיה שלך כבר קיבלו מענה באחד מהדפים הבאים:

הנושאים בדף הזה:

גיבוי ושחזור

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

מריצים את הפקודה gcloud sql operations list כדי להציג רשימה של כל הפעולות עבור המכונה הנתונה של Cloud SQL.
אתם רוצים לגלות מי ביצע פעולת גיבוי לפי דרישה. בממשק המשתמש לא מוצג המשתמש שהתחיל פעולה.

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

  • אם Cloud Audit Logs מופעלות ויש לכם את ההרשאות הנדרשות לצפייה בהן, יכול להיות שגם cloudaudit.googleapis.com/activity יהיה זמין.
אחרי שמוחקים מופע, אי אפשר לגבות אותו.

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

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

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

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

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

פעולות שכדאי לנסות:

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

CREATE UNLOGGED TABLE ....

הטבלאות האלה לא נכללות בשחזור מגיבוי:

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

הפתרון הוא להימנע משימוש בטבלאות שלא נרשמו ביומן אם רוצים לשחזר את הטבלאות האלה באמצעות גיבוי. אם אתם משחזרים ממסד נתונים שכבר מכיל טבלאות לא מתועדות, אתם יכולים להעביר את מסד הנתונים לקובץ ואז לטעון מחדש את הנתונים אחרי שתשנו את הקובץ שהועבר מ-ALTER TABLE ל-SET LOGGED בטבלאות האלה.
אי אפשר למחוק מופע כשבוחרים לבצע גיבוי סופי בזמן מחיקת המופע. כשמוחקים מופע, צריך לאשר אם רוצים ליצור גיבוי סופי של המופע לפני המחיקה. אם הפעלתם גיבוי סופי באמצעות הגדרת המופע final-backup, הבחירה שתבצעו כשאתם מוחקים את המופע חייבת להיות זהה להגדרת המופע של הגיבוי הסופי שהגדרתם כשהפעלתם גיבוי סופי למופע. כדי לפתור את הבעיה, אפשר לנסות את הפתרונות הבאים:
  • מגדירים את ערך הגיבוי הסופי כך שיתאים להגדרת הגיבוי הקיימת של המופע.
  • כשמוחקים את המופע, משאירים את השדה של הגיבוי הסופי ריק. אם משאירים את השדה ריק, Cloud SQL משתמש בהגדרות הגיבוי הסופיות שמוגדרות בהגדרות המופע כדי ליצור גיבוי סופי ולהגדיר את תקופת השמירה שלו.
כדי לראות את הגדרת הגיבוי הסופית של המופע, אפשר לעיין במאמר בנושא הצגת פרטי המופע.
לא ניתן ליצור מופע משוכפל אחרי יצירה מוצלחת של מופע ראשי עם הגדרת הגיבוי הסופית. אם יוצרים מופע חדש עם ההגדרה של מופע הגיבוי הסופי מופעלת, צריך לעדכן את מדיניות הארגון של הגיבוי הסופי כדי להחיל את הגדרות הגיבוי רק על המופע הראשי. אין תמיכה בגיבויים סופיים של מופעי העתקה.
מידע נוסף זמין במאמר מדיניות הארגון של Cloud SQL.

שכפל

שגיאה פתרון בעיות
השיבוט נכשל עם השגיאה constraints/sql.restrictAuthorizedNetworks. הפעולה של שיבוט נחסמת על ידי ההגדרה של Authorized Networks. Authorized Networks מוגדרות לכתובות IP ציבוריות בקטע Connectivity (קישוריות) במסוף Google Cloud , ושיבוט לא מותר בגלל שיקולי אבטחה.

אם אפשר, מסירים את כל הערכים של Authorized Networks ממופע Cloud SQL. אחרת, יוצרים העתק בלי ערכים של Authorized Networks.
הודעת שגיאה: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Help Token: [help-token-id].

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

משתמשים ב-gcloud כדי לשכפל את המופע ומספקים ערך לפרמטר
--allocated-ip-range-name. מידע נוסף זמין במאמר בנושא שיבוט של מופע עם כתובת IP פרטית.

חיבור

שגיאה פתרון בעיות
Aborted connection. הבעיה יכולה להיות:
  • חוסר יציבות ברשת.
  • אין תגובה לפקודות TCP keep-alive (יכול להיות שהלקוח או השרת לא מגיבים, אולי בגלל עומס יתר)
  • החיבור למנוע מסד הנתונים חרג ממגבלת הזמן שהוקצתה לו, והשרת מסיים את החיבור.

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

כדי לנסות שוב להתחבר, מומלץ להשתמש בשיטות הבאות:

  1. השהיה מעריכית לפני ניסיון חוזר (exponential backoff). להגדיל את מרווח הזמן בין כל ניסיון חוזר, באופן מעריכי.
  2. כדאי גם להוסיף השהיה אקראית.

שילוב של השיטות האלה עוזר לצמצם את ההגבלה.
הודעת שגיאה: Login failed for user "" יכול להיות שתיתקלו בשגיאת ההתחברות הזו במהלך אימות ב-Microsoft Entra ID. כדי לפתור את הבעיה, ודא שקיימת התחברות ל-SQL Server עבור משתמש Microsoft Entra ID זה.
בעיות בקישוריות לרשת עם מופעים של כתובות IP פרטיות יכול להיות שתיתקלו באחת מהבעיות הבאות במהלך ההגדרה של השילוב:
  • פעולות איטיות ליצירת התחברויות ל-Microsoft Entra ID
  • אי אפשר ליצור כניסות ל-Microsoft Entra ID
  • אי אפשר להתחבר למופע באמצעות אימות של Microsoft Entra ID

מידע נוסף על פתרון הבעיות האלה זמין במאמר בנושא פתרון בעיות בשילוב עם Microsoft Entra ID.
FATAL: database 'user' does not exist. ‫gcloud sql connect --user פועל רק עם משתמש ברירת המחדל postgres.

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

SELECT datname,
usename,
application_name as appname,
client_addr,
state,
now() - backend_start as conn_age,
now() - state_change as last_activity_age
FROM pg_stat_activity
WHERE backend_type = 'client backend'
ORDER BY 6 DESC
LIMIT 20

יצירת מופעים

שגיאה פתרון בעיות
הודעת שגיאה: The zone or region does not have sufficient resources to handle the request at the moment.

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

כדי לפתור את הבעיה, נסו שוב ליצור את המכונה באזור אחר, או נסו שוב ליצור את המכונה באותו אזור שבו התקבלה השגיאה, בשעה אחרת ביום.
הודעת שגיאה: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. אין יותר כתובות זמינות בטווח כתובות ה-IP שהוקצה. יכולים להיות כמה תרחישים אפשריים:
  • הגודל של טווח כתובות ה-IP שהוקצה לחיבור הפרטי לשירות קטן מ-‎ /24.
  • הגודל של טווח כתובות ה-IP שהוקצה לחיבור הפרטי לשירות קטן מדי ביחס למספר המכונות של Cloud SQL.
  • הדרישה לגבי הגודל של טווח כתובות ה-IP שהוקצה תהיה גדולה יותר אם המכונות הווירטואליות נוצרות בכמה אזורים. הצגת גודל הטווח שהוקצה

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

אם השתמשתם בדגל --allocated-ip-range-name כשיצרתם את מופע Cloud SQL, תוכלו להרחיב רק את טווח כתובות ה-IP שצוין.

אם מקצים טווח חדש, צריך לוודא שההקצאה לא חופפת להקצאות קיימות.

אחרי שיוצרים טווח IP חדש, מעדכנים את הקישור בין רשתות ה-VPC באמצעות הפקודה הבאה:

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=OLD_RESERVED_RANGE_NAME,NEW_RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID \
--force

אם מרחיבים הקצאה קיימת, חשוב להגדיל רק את טווח ההקצאה ולא להקטין אותו. לדוגמה, אם ההקצאה המקורית הייתה 10.0.10.0/24, ההקצאה החדשה צריכה להיות לפחות 10.0.10.0/23.

באופן כללי, אם מתחילים מהקצאה של ‎ /24, מומלץ להקטין את ‎ /mask ב-1 לכל תנאי (קבוצת סוגי מופעים נוספת, אזור נוסף). לדוגמה, אם מנסים ליצור שתי קבוצות של סוגי מופעים באותו הקצאה, מעבר מ-‎ /24 ל-‎ /23 מספיק.

אחרי שמרחיבים טווח IP קיים, מעדכנים את ה-VPC Peering באמצעות הפקודה הבאה:

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
הודעת שגיאה: Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID]. נסו ליצור שוב את המכונה של Cloud SQL.
הודעת שגיאה: HTTPError 400: Invalid request: Incorrect Service Networking config for instance: PROJECT_ID:INSTANCE_NAME:SERVICE_NETWORKING_NOT_ENABLED.

מפעילים את Service Networking API באמצעות הפקודה הבאה ומנסים שוב ליצור את מכונת Cloud SQL.

gcloud services enable servicenetworking.googleapis.com \
--project=PROJECT_ID
הודעת שגיאה: Failed to create subnetwork. Required 'compute.projects.get' permission for PROJECT_ID. כשיוצרים מופע באמצעות כתובת IP פרטית, נוצר חשבון שירות בדיוק בזמן באמצעות Service Networking API. אם הפעלתם את Service Networking API רק לאחרונה, יכול להיות שחשבון השירות לא ייווצר ויצירת המופע תיכשל. במקרה כזה, צריך לחכות עד שחשבון השירות יתעדכן בכל המערכת או להוסיף אותו ידנית עם ההרשאות הנדרשות.
הודעת שגיאה: More than 3 subject alternative names are not allowed. אתם מנסים להשתמש ב-SAN בהתאמה אישית כדי להוסיף יותר משלושה שמות DNS לאישור השרת של מופע Cloud SQL. אי אפשר להוסיף למופע יותר משלושה שמות DNS.
הודעת שגיאה: Subject alternative names %s is too long. The maximum length is 253 characters. מוודאים ששמות ה-DNS שרוצים להוסיף לאישור השרת של מופע Cloud SQL לא מכילים יותר מ-253 תווים.
הודעת שגיאה: Subject alternative name %s is invalid.

מוודאים ששמות ה-DNS שרוצים להוסיף לאישור השרת של מופע Cloud SQL עומדים בקריטריונים הבאים:

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

ייצוא

שגיאה פתרון בעיות
HTTP Error 409: Operation failed because another operation was already in progress. כבר יש פעולה בהמתנה למכונה. מותר לבצע רק פעולה אחת בכל פעם. כדאי לנסות לשלוח את הבקשה אחרי שהפעולה הנוכחית תסתיים.
HTTP Error 403: The service account does not have the required permissions for the bucket. מוודאים שהקטגוריה קיימת ושלחשבון השירות של מכונת Cloud SQL (שמבצעת את הייצוא) הוקצה התפקיד Storage Object Creator (roles/storage.objectCreator) כדי לאפשר ייצוא לקטגוריה. תפקידי IAM ל-Cloud Storage
ייצוא ה-CSV פעל אבל ייצוא ה-SQL נכשל. פורמטים של CSV ו-SQL מיוצאים באופן שונה. בפורמט SQL מתבצע ייצוא של כל מסד הנתונים, ולכן סביר להניח שהתהליך יימשך זמן רב יותר. בפורמט CSV אפשר להגדיר אילו רכיבים במסד הנתונים ייכללו בייצוא.

שימוש בייצוא של קובצי CSV כדי לייצא רק את מה שצריך.
הייצוא נמשך יותר מדי זמן. ‫Cloud SQL לא תומך בפעולות סינכרוניות מקבילות.

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

עורכים את קובץ ה-dump כדי להסיר את ההפניות.
שגיאה בשימוש ב-pg_dumpall. כדי להשתמש בכלי pg_dumpall עם הדגל --global, צריך להיות לכם תפקיד של משתמש על, אבל התפקיד הזה לא נתמך ב-Cloud SQL. כדי למנוע שגיאות במהלך פעולות ייצוא שכוללות שמות משתמשים, צריך להשתמש גם בדגל --no-role-passwords.
פעולת הייצוא נכשלת בגלל חריגה מזמן קצוב לתפוגה לפני שמתבצע ייצוא כלשהו, ומופיעה הודעת השגיאה Could not receive data from client: Connection reset by peer. אם Cloud Storage לא מקבל נתונים בפרק זמן מסוים, בדרך כלל כ-7 דקות, החיבור מתאפס. יכול להיות ששאילתת הייצוא הראשונית פועלת יותר מדי זמן.

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

אפשר ליצור מערכת ייצוא אוטומטית משלכם באמצעות מוצרים כמו Cloud Scheduler,‏ Pub/Sub ופונקציות Cloud Run, בדומה למאמר הזה בנושא גיבוי אוטומטי. Google Cloud

חיצוני וראשי

שגיאה פתרון בעיות
Lost connection to MySQL server during query when dumping table. יכול להיות שהמקור הפך ללא זמין, או שה-dump הכיל מנות גדולות מדי.

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

מידע נוסף על שימוש בדגלים mysqldump להעברת ייבוא מנוהל זמין במאמר דגלים מותרים ודגלי ברירת מחדל לסנכרון ראשוני
הגיבוי הראשוני נכשל בגלל שגיאות שקשורות לזמן קצוב לתפוגה או לחיבור שאבד (לדוגמה, Dump timeout או Lost connection to MySQL server). השגיאה הזו יכולה להתרחש אם הצהרת DDL אחת או יותר מבצעת אינטראקציה עם תהליך ה-dump המקביל, וגורמת לתהליך להמתין ללא הגבלת זמן.

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

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

מוודאים שדגלי השכפול, כמו binlog-do-db,‏ binlog-ignore-db,‏ replicate-do-db או replicate-ignore-db, לא מוגדרים בצורה שיוצרת התנגשות.

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

פעולות שכדאי לנסות:

  • בודקים את מדדי השכפול של מופע הרפליקה בקטע Cloud Monitoring במסוף Google Cloud .
  • השגיאות משרשור הקלט/פלט או משרשור ה-SQL של MySQL מופיעות בCloud Logging בקובצי היומן mysql.err.
  • השגיאה יכולה להופיע גם כשמתחברים למופע המשוכפל. מריצים את הפקודה SHOW REPLICA STATUS ובודקים את השדות הבאים בפלט:
    • Replica_IO_Running
    • Replica_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error

אם מופיעה השגיאה Unknown database DATABASE_NAME on query. Error_code: MY-001049, המשמעות היא שהשכפול נכשל כי הצהרת SQL משוכפלת ניסתה להפנות למסד נתונים שלא נבחר להעברה. כדי לשחזר את השכפול, צריך לקבוע אם השגיאה מבוססת על הודעה שנובעת מ-DDL באחד מהאובייקטים הבאים:

  • אירוע או פעולה שגרתית. אפשר להריץ את הפקודה CALL mysql.skipReplicationError() ברפליקה, וכך למנוע את השכפול של האירוע או השגרה ולהמשיך את השכפול.
  • אילוץ או תצוגה של מפתח זר. אחרי שקובעים באיזה מסד נתונים נמצא האובייקט ששונה על ידי ההצהרה, יש שתי אפשרויות לשחזור. אפשר להסיר את מסד הנתונים ממסדי הנתונים שנבחרו להעברה, או להריץ את הפקודה CALL mysql.skipReplicationError() על העותק המשוכפל כדי להמשיך את השכפול תוך דילוג על האילוץ או על ההפצה של התצוגה לעותק המשוכפל.
mysqld check failed: data disk is full. דיסק הנתונים של מופע הרפליקה מלא.

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

עותק משוכפל חיצוני

שגיאה פתרון בעיות
הודעת שגיאה: The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires. במופע הראשי של Cloud SQL יש גיבויים אוטומטיים ויומנים בינאריים, והופעלה האפשרות לשחזור מערכת מנקודה מסוימת בזמן (PITR), כך שצריכים להיות בו מספיק יומנים כדי שהרפליקה תוכל להתעדכן. עם זאת, במקרה הזה, למרות שקיימים יומני בינאריים, העותק לא יודע מאיזו שורה להתחיל לקרוא.

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

  1. מתחברים ללקוח mysql דרך מכונה של Compute Engine.
  2. מריצים את הפקודה mysqldump ומשתמשים בדגלים --master-data=1 ו---flush-privileges.

    חשוב: אל תכללו את הדגל --set-gtid-purged=OFF.

    מידע נוסף

  3. מוודאים שקובץ ה-dump שנוצר מכיל את השורה SET @@GLOBAL.GTID_PURGED='...'.
  4. מעלים את קובץ ה-dump לקטגוריה של Cloud Storage ו מגדירים את הרפליקה באמצעות קובץ ה-dump.

דגלים

שגיאה פתרון בעיות

זמינות גבוהה

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

עורכים את המכונה כדי לשדרג לגודל מכונה גדול יותר ולקבל יותר מעבדי CPU וזיכרון.

ייבוא

שגיאה פתרון בעיות
HTTP Error 409: Operation failed because another operation was already in progress. כבר יש פעולה בהמתנה למכונה. מותר לבצע רק פעולה אחת בכל פעם. כדאי לנסות לשלוח את הבקשה אחרי שהפעולה הנוכחית תסתיים.
פעולת הייבוא נמשכת יותר מדי זמן. יותר מדי חיבורים פעילים עלולים להפריע לפעולות ייבוא.

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

הפעלה מחדש:

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

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

פעולות שכדאי לנסות:

מוסיפים את השורה הבאה בתחילת קובץ ה-dump:

SET FOREIGN_KEY_CHECKS=0;

בנוסף, מוסיפים את השורה הבאה בסוף קובץ ה-dump:

SET FOREIGN_KEY_CHECKS=1;

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

אינטגרציה עם Vertex AI

שגיאה פתרון בעיות
הודעת שגיאה: Google ML Integration API is not supported on shared core instance. Please upsize your machine type. אם בחרתם ליבה משותפת לסוג המכונה של המופע, לא תוכלו להפעיל את השילוב של Vertex AI ב-Cloud SQL. שדרוג סוג המכונה לליבה ייעודית. מידע נוסף זמין במאמר בנושא סוגי מכונות.
הודעת שגיאה: Google ML Integration is unsupported for this maintenance version. Please follow https://cloud.google.com/sql/docs/mysql/self-service-maintenance to update the maintenance version of the instance. כדי להפעיל את השילוב של Vertex AI ב-Cloud SQL, גרסת התחזוקה של המכונה צריכה להיות R20240130 ומעלה. כדי לשדרג את המופע לגרסה הזו, אפשר לעיין במאמר בנושא תחזוקה בשירות עצמי.
הודעת שגיאה: Cannot invoke ml_predict_row if 'cloudsql.enable_google_ml_integration' is off. cloudsql.enable_google_ml_integration הסימון של מסד הנתונים מושבת. אי אפשר לשלב את Cloud SQL עם Vertex AI.

כדי להפעיל את הדגל הזה, משתמשים בפקודה gcloud sql instances patch:

gcloud sql instances patch INSTANCE_NAME --database-flags cloudsql.enable_google_ml_integration=on

מחליפים את INSTANCE_NAME בשם של מופע Cloud SQL הראשי.
הודעת שגיאה: Failed to connect to remote host: Connection refused. השילוב בין Cloud SQL לבין Vertex AI לא מופעל. כדי להפעיל את השילוב הזה, משתמשים בפקודה gcloud sql instances patch:

gcloud sql instances patch INSTANCE_NAME
--enable-google-ml-integration

מחליפים את INSTANCE_NAME בשם של מופע Cloud SQL הראשי.
הודעת שגיאה: Vertex AI API has not been used in project PROJECT_ID before or it is disabled. Enable it by visiting /apis/api/aiplatform.googleapis.com/overview?project=PROJECT_ID then retry. ‫Vertex AI API לא מופעל. מידע נוסף על הפעלת ה-API הזה זמין במאמר הפעלת שילוב של מסד נתונים עם Vertex AI.
הודעת שגיאה: Permission 'aiplatform.endpoints.predict' denied on resource. ההרשאות של Vertex AI לא מתווספות לחשבון השירות של Cloud SQL בפרויקט שבו נמצאת מכונת Cloud SQL. למידע נוסף על הוספת ההרשאות האלה לחשבון השירות, אפשר לעיין במאמר איך מעניקים לחשבון השירות של Cloud SQL הרשאות גישה ל-Vertex AI בניהול זהויות והרשאות גישה (IAM).
הודעת שגיאה: Publisher Model `projects/PROJECT_ID/locations/REGION_NAME/publishers/google/models/MODEL_NAME` not found. מודל למידת המכונה או מודל ה-LLM לא קיימים ב-Vertex AI.
הודעת שגיאה: Resource exhausted: grpc: received message larger than max. הגודל של הבקשה ש-Cloud SQL מעביר ל-Vertex AI חורג מהמגבלה של gRPC של 4MB לכל בקשה.
הודעת שגיאה: Cloud SQL attempts to send a request to Vertex AI. However, the instance is in the %s region, but the Vertex AI endpoint is in the %s region. Make sure the instance and endpoint are in the same region. מערכת Cloud SQL מנסה לשלוח בקשה אל Vertex AI. עם זאת, המכונה הווירטואלית נמצאת באזור אחד, אבל נקודת הקצה של Vertex AI נמצאת באזור אחר. כדי לפתור את הבעיה, גם המופע וגם נקודת הקצה צריכים להיות באותו אזור.
הודעת שגיאה: The Vertex AI endpoint isn't formatted properly. הפורמט של נקודת הקצה של Vertex AI לא תקין. מידע נוסף זמין במאמר שימוש בנקודות קצה פרטיות לחיזוי אונליין.
הודעת שגיאה: Quota exceeded for aiplatform.googleapis.com/online_prediction_requests_per_base_model with base model: textembedding-gecko. מספר הבקשות ש-Cloud SQL מעביר אל Vertex AI חורג מהמגבלה של 1,500 בקשות לדקה לכל אזור לכל מודל לכל פרויקט.

שרתים מקושרים

שגיאה פתרון בעיות
Msg 7411, Level 16, State 1, Line 25

Server 'LINKED_SERVER_NAME' is not configured for DATA ACCESS. 		האפשרות DataAccess מושבתת. מריצים את הפקודה הבאה כדי להפעיל את הגישה לנתונים: