פתרון בעיות

‫MySQL   |  PostgreSQL   |  SQL Server

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

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

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

• גיבוי ושחזור
• שיבוט
• קישוריות
• יצירת מופעים
• Flags
• זמינות גבוהה
• ייבוא וייצוא
• שרתים מקושרים
• Logging
• ניהול מופעים
• ‫Private Service Connect
• שכפול

גיבוי ושחזור

שגיאה	פתרון בעיות
אי אפשר לראות את הסטטוס של הפעולה הנוכחית.	במסוף Google Cloud מוצג רק אם הפעולה הצליחה או נכשלה. הוא לא מיועד להצגת אזהרות או עדכונים אחרים. מריצים את הפקודה gcloud sql operations list כדי להציג רשימה של כל הפעולות עבור המכונה הנתונה של Cloud SQL.
אתם רוצים לגלות מי ביצע פעולת גיבוי לפי דרישה.	בממשק המשתמש לא מוצג המשתמש שהתחיל פעולה. בודקים ביומנים ומסננים לפי טקסט כדי למצוא את המשתמש. יכול להיות שתצטרכו להשתמש ביומני ביקורת כדי לגשת למידע פרטי. קבצי יומן רלוונטיים כוללים: cloudsql.googleapis.com/sqlagent.out cloudsql.googleapis.com/sqlserver.err אם Cloud Audit Logs מופעלות ויש לכם את ההרשאות הנדרשות לצפייה בהן, יכול להיות שגם cloudaudit.googleapis.com/activity יהיה זמין.
אחרי שמוחקים מופע, אי אפשר לגבות אותו.	אם מוחקים מופע בלי ליצור גיבוי סופי של הנתונים, לא ניתן לשחזר את הנתונים. עם זאת, אם משחזרים את המכונה, Cloud SQL משחזר גם את הגיבויים. מידע נוסף על שחזור מופע שנמחק זמין במאמר שמירת גיבויים אחרי מחיקת מופע. אם ביצעתם פעולת ייצוא, צריך ליצור מופע חדש ואז לבצע פעולת ייבוא כדי ליצור מחדש את מסד הנתונים. קובצי הייצוא נכתבים ב-Cloud Storage וקובצי הייבוא נקראים משם. הערה: מומלץ ליצור גיבוי סופי של הנתונים לפני מחיקת המופע ב-Cloud SQL. כך תוכלו ליצור מחדש כל מכונה שמחקתם בטעות בלי לפנות ל-Cloud Customer Care.
גיבוי אוטומטי נתקע למשך שעות רבות ואי אפשר לבטל אותו.	גיבויים יכולים להימשך זמן רב, בהתאם לגודל מסד הנתונים. אם אתם ממש צריכים לבטל את הפעולה, אתם יכולים לבקש מ תמיכת הלקוחות force restart את המופע.
פעולת שחזור יכולה להיכשל אם משתמש אחד או יותר שמצוינים בקובץ ה-SQL dump לא קיימים.	לפני שמשחזרים SQL dump, כל המשתמשים במסד הנתונים שיש בבעלותם אובייקטים או שקיבלו הרשאות לאובייקטים במסד הנתונים שהושלך חייבים להיות קיימים במסד הנתונים של היעד. אם לא, פעולת השחזור תיכשל ולא תיצור מחדש את האובייקטים עם הבעלות או ההרשאות המקוריות. יוצרים את משתמשי מסד הנתונים לפני שמשחזרים את קובץ ה-SQL.
אתם רוצים להגדיל את מספר הימים שבהם אפשר לשמור גיבויים אוטומטיים מ-7 ל-30 ימים, או יותר.	אפשר להגדיר את מספר הגיבויים האוטומטיים שיישארו, אבל אי אפשר להגדיר מספר קטן יותר ממספר ברירת המחדל (שבעה). גיבויים אוטומטיים נמחקים באופן קבוע על סמך ערך השמירה שהוגדר. לצערנו, המשמעות היא שהגיבויים שמוצגים כרגע הם הגיבויים האוטומטיים היחידים שניתן לשחזר מהם. כדי לשמור גיבויים ללא הגבלת זמן, אפשר ליצור גיבוי לפי דרישה, כי הם לא נמחקים כמו גיבויים אוטומטיים. גיבויים על פי דרישה נשארים ללא הגבלת זמן. כלומר, הן נשארות עד שהן נמחקות או עד שהמופע שאליו הן שייכות נמחק. הגיבוי הזה לא נמחק אוטומטית, ולכן הוא יכול להשפיע על החיוב.
גיבוי אוטומטי נכשל ולא קיבלתם התראה באימייל.	כדי לקבל מ-Cloud SQL התראה על סטטוס הגיבוי, מגדירים התראה שמבוססת על יומן.
אין לך אפשרות לשחזר את המופע באמצעות הפקודה Transact-SQL RESTORE או באמצעות SQL Server Management Studio‏ (SSMS).	ב-Cloud SQL אין תמיכה בשחזור מופעים באמצעות SSMS. כדי לשחזר את המכונה, מריצים את הפקודה gcloud sql import.
אי אפשר לראות את היסטוריית הגיבוי של היומן.	היסטוריית הגיבוי של היומן נשמרת רק למשך 60 יום בטבלאות הגיבוי של מסד הנתונים msdb.
אי אפשר למחוק מופע כשבוחרים לבצע גיבוי סופי בזמן מחיקת המופע.	כשמוחקים מופע, צריך לאשר אם רוצים ליצור גיבוי סופי של המופע לפני המחיקה. אם הפעלתם גיבוי סופי באמצעות הגדרת המופע 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 (יכול להיות שהלקוח או השרת לא מגיבים, אולי בגלל עומס יתר) החיבור למנוע מסד הנתונים חרג ממגבלת הזמן שהוקצתה לו, והשרת מסיים את החיבור. האפליקציות צריכות להיות עמידות בפני כשלים ברשת ולפעול לפי שיטות מומלצות כמו איגום חיבורים וניסיון חוזר. רוב כלי הניהול של מאגרי החיבורים מזהים את השגיאות האלה, אם אפשר. אחרת, האפליקציה צריכה לנסות שוב או להיכשל בצורה מסודרת. כדי לנסות שוב להתחבר, מומלץ להשתמש בשיטות הבאות: השהיה מעריכית לפני ניסיון חוזר (exponential backoff). להגדיל את מרווח הזמן בין כל ניסיון חוזר, באופן מעריכי. כדאי גם להוסיף השהיה אקראית. שילוב של השיטות האלה עוזר לצמצם את ההגבלה.
הודעת שגיאה: 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.

יצירת מופעים

שגיאה	פתרון בעיות
הודעת שגיאה: 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
אתם רוצים שהייצוא יהיה אוטומטי.	ב-Cloud SQL אין אפשרות לייצא באופן אוטומטי. אפשר ליצור מערכת ייצוא אוטומטית משלכם באמצעות מוצרים כמו Cloud Scheduler,‏ Pub/Sub ופונקציות Cloud Run, בדומה למאמר הזה בנושא גיבוי אוטומטי. Google Cloud

דגלים

שגיאה	פתרון בעיות
רוצים לשנות את אזור הזמן של מכונת Cloud SQL.	במאמר הגדרות של מכונות מוסבר איך לעדכן את אזור הזמן של מכונה. ב-Cloud SQL ל-SQL Server, אפשר להשתמש בפונקציה AT TIME ZONE כדי להמיר בין אזורי זמן ועוד. מידע נוסף על הפונקציה הזו זמין במאמר AT TIME ZONE (Transact-SQL).

זמינות גבוהה

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

ייבוא

שגיאה	פתרון בעיות
HTTP Error 409: Operation failed because another operation was already in progress.	כבר יש פעולה בהמתנה למכונה. מותר לבצע רק פעולה אחת בכל פעם. כדאי לנסות לשלוח את הבקשה אחרי שהפעולה הנוכחית תסתיים.
פעולת הייבוא נמשכת יותר מדי זמן.	יותר מדי חיבורים פעילים עלולים להפריע לפעולות ייבוא. סוגרים פעולות שלא בשימוש. כדאי לבדוק את המעבד (CPU) ואת השימוש בזיכרון במכונת Cloud SQL כדי לוודא שיש מספיק משאבים זמינים. הדרך הטובה ביותר לוודא שמשימת הייבוא מקבלת את מרב המשאבים היא להפעיל מחדש את המכונה לפני התחלת הפעולה. הפעלה מחדש: סגירת כל החיבורים. מסיים את כל המשימות שעשויות לצרוך משאבים.
פעולת ייבוא יכולה להיכשל אם משתמש אחד או יותר שמצוינים בקובץ ה-dump לא קיימים.	לפני שמייבאים קובץ dump, כל המשתמשים במסד הנתונים שיש בבעלותם אובייקטים או שקיבלו הרשאות לאובייקטים במסד הנתונים שהושלך חייבים להיות קיימים במסד הנתונים של היעד. אם לא, פעולת הייבוא תיכשל ולא תיצור מחדש את האובייקטים עם הבעלות או ההרשאות המקוריות. יוצרים את משתמשי מסד הנתונים לפני הייבוא.
חוסר התאמה ב-LSN	הסדר של ייבוא הגיבויים של יומן העסקאות שגוי או ששרשרת יומן העסקאות שבורה. מייבאים את הגיבויים של יומן העסקאות באותו סדר שבו הם מופיעים בטבלת קבוצת הגיבוי.
ההגדרה StopAt מוקדמת מדי	השגיאה הזו מציינת שהכניסה הראשונה בקובץ יומן העסקאות היא אחרי חותמת הזמן StopAt. לדוגמה, אם הכניסה הראשונה בקובץ יומן העסקאות היא ב-2023-09-01T12:00:00 והשדה StopAt מכיל את הערך 2023-09-01T11:00:00, ‏ Cloud SQL מחזיר את השגיאה הזו. חשוב לוודא שמשתמשים בחותמת הזמן הנכונה StopAt ובקובץ הנכון של יומן העסקאות.

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

שגיאה	פתרון בעיות
Msg 7411, Level 16, State 1, Line 25 Server 'LINKED_SERVER_NAME' is not configured for DATA ACCESS.	האפשרות DataAccess מושבתת. מריצים את הפקודה הבאה כדי להפעיל את הגישה לנתונים: EXEC sp_serveroption @server='LINKED_SERVER_NAME', @optname='data access', @optvalue='TRUE' מחליפים את LINKED_SERVER_NAME בשם של השרת המקושר.
Access to the remote server is denied because no login-mapping exists. (Microsoft SQL Server, Error: 7416)	אם הבעיה הזו מתרחשת בזמן יצירת חיבור מוצפן, צריך לנסות דרך אחרת לספק את מזהה המשתמש כשניגשים לשרת המקושר. כדי לעשות זאת, מריצים את הפקודה הבאה: EXEC master.dbo.sp_addlinkedserver @server = N'LINKED_SERVER_NAME', @srvproduct= N'', @provider= N'MSOLEDBSQL', @datasrc= N'TARGET_SERVER_ID', @provstr= N'Encrypt=yes;TrustServerCertificate=yes;User ID=USER_ID' מחליפים את מה שכתוב בשדות הבאים: LINKED_SERVER_NAME בשם של השרת המקושר. TARGET_SERVER_ID עם השם של שרת היעד, או עם כתובת ה-IP ומספר היציאה של שרת היעד. ‫USER_ID מחליפים במשתמש שמתחבר.
התנהגות לא צפויה	אם אתם נתקלים בהתנהגות לא צפויה, ודאו שאתם משתמשים בספק נתמך. מידע נוסף זמין במסמכי העזרה של Microsoft.

רישום ביומן

שגיאה	פתרון בעיות
יומני הביקורת לא נמצאו.	יומני Data-Access נכתבים רק אם הפעולה היא קריאה ל-API שמבוססת על משתמש מאומת ויוצרת, משנה או קוראת נתונים שנוצרו על ידי משתמש, או אם הפעולה ניגשת לקובצי הגדרות או למטא-נתונים של משאבים.
לא נמצא מידע על פעולות ביומנים.	רוצים לקבל מידע נוסף על פעולה מסוימת. לדוגמה, משתמש נמחק אבל אתם לא יכולים לגלות מי עשה את זה. היומנים מראים שהפעולה התחילה, אבל לא מספקים מידע נוסף. כדי שפרטים מזהים אישיים (PII) כמו אלה יירשמו ביומן, אתם צריכים להפעיל את רישום הפעולות ביומן הביקורת.
חלק מהיומנים מסוננים מיומן error.log של מכונת Cloud SQL ל-SQL Server.	היומנים המסוננים כוללים יומני AD בלי חותמות זמן, וכוללים: Login failed for user 'x'. Reason: Token-based server access validation failed with an infrastructure error. Login lacks connect endpoint permission. [CLIENT: 127.0.0.1]. היומנים האלה מסוננים כי הם עלולים לגרום לבלבול.
קשה לקרוא את קובצי היומן.	אתם מעדיפים לראות את היומנים בפורמט JSON או טקסט.אתם יכולים להשתמש בפקודה gcloud logging read יחד עם פקודות לעיבוד נתונים ב-Linux כדי להוריד את היומנים. כדי להוריד את היומנים כקובץ JSON: gcloud logging read \ "resource.type=cloudsql_database \ AND logName=projects/PROJECT_ID \ /logs/cloudsql.googleapis.com%2FLOG_NAME" \ --format json \ --project=PROJECT_ID \ --freshness="1d" \ > downloaded-log.json כדי להוריד את היומנים כקובץ TEXT: gcloud logging read \ "resource.type=cloudsql_database \ AND logName=projects/PROJECT_ID \ /logs/cloudsql.googleapis.com%2FLOG_NAME" \ --format json \ --project=PROJECT_ID \ --freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \ | .textPayload' \ --order=asc > downloaded-log.txt

ניהול מופעים

שגיאה	פתרון בעיות
הגדלנו את נפח האחסון הזמני באופן אוטומטי.	האחסון האוטומטי מופעל. הפעלה מחדש מוחקת את הקבצים הזמניים אבל לא מקטינה את נפח האחסון. רק תמיכת לקוחות יכולה לאפס את גודל המופע.
הנתונים נמחקים באופן אוטומטי.	סביר להניח שסקריפט פועל איפשהו בסביבה שלכם. בודקים ביומנים את השעה שבה בוצעה המחיקה, ומחפשים סקריפט לא מורשה שפועל מלוח בקרה או מתהליך אוטומטי אחר.
אי אפשר למחוק את המופע.	יכול להיות שתופיע הודעת השגיאה ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request, או שהמופע יסומן בסטטוס INSTANCE_RISKY_FLAG_CONFIG. אלה כמה מהסיבות האפשריות לכך: מתבצעת כרגע פעולה אחרת. פעולות Cloud SQL לא מופעלות בו-זמנית. ממתינים לסיום הפעולה השנייה. האזהרה INSTANCE_RISKY_FLAG_CONFIG מופעלת בכל פעם שמשתמשים בדגל beta אחד לפחות. מסירים את הגדרות הדגל של הסיכון ומפעילים מחדש את המופע
המכונה תקועה בגלל גודל גדול של נתונים זמניים.	המערכת יכולה ליצור הרבה טבלאות זמניות בבת אחת, בהתאם לשאילתות ולעומס. לצערנו, אי אפשר להקטין את הקובץ ibtmp1 בשום שיטה, מלבד הפעלה מחדש של השירות. אחת מהאפשרויות לצמצום הסיכון היא ליצור את הטבלה הזמנית באמצעות ROW_FORMAT=COMPRESSED, כדי שהיא תאוחסן במרחבי טבלאות של קובץ לכל טבלה בספריית הקבצים הזמניים. עם זאת, החיסרון הוא עלויות הביצועים שקשורות ליצירה ולהסרה של מרחב טבלאות של קובץ לכל טבלה עבור כל טבלה זמנית.
שגיאה קריטית במהלך השדרוג.	יכול להיות שיומני הרישום יספקו מידע נוסף, אבל בכל מקרה, יכול להיות שתצטרכו תמיכת לקוחות כדי לכפות יצירה מחדש של המופע.
מופע נתקע בהפעלה מחדש אחרי שנגמר לו המקום בדיסק.	היכולת להגדיל את נפח האחסון באופן אוטומטי לא מופעלת. אם נפח האחסון של המופע שלכם יתמלא, והיכולת להגדלה אוטומטית של נפח האחסון לא מופעלת, המופע יעבור למצב אופליין. כדי למנוע את הבעיה הזו, אפשר לערוך את המופע כדי להפעיל הגדלה אוטומטית של נפח האחסון.
המופע הראשי המקומי תקוע.	Google Cloud לא יכול לעזור עם מופעים שלא נמצאים ב-Cloud SQL.
כיבוי איטי בהפעלה מחדש.	כשמופעלת השבתה של מופע, כל החיבורים הפתוחים שלא מסתיימים תוך 60 שניות גורמים להשבתה לא נקייה. אם החיבורים נמשכים פחות מ-60 שניות, אפשר להימנע מרוב הכיבויים הלא תקינים, כולל חיבורים משורת הפקודה של מסד הנתונים. אם החיבורים האלה נשארים פתוחים במשך שעות או ימים, יכול להיות שהכיבוי לא יהיה תקין.
אי אפשר למחוק משתמש.	כנראה שיש למשתמש אובייקטים במסד הנתונים שתלויים בו. תצטרכו להסיר את האובייקטים האלה או להקצות אותם מחדש למשתמש אחר. בודקים אילו אובייקטים תלויים במשתמש, ואז משמיטים או מקצים מחדש את האובייקטים האלה למשתמש אחר. בשרשור הזה ב-Stack Exchange מוסבר איך למצוא את האובייקטים שבבעלות המשתמש.
שאילתות מסוימות פועלות לאט.	יש הרבה סיבות לכך ששאילתות פועלות לאט, בעיקר בגלל היבטים ספציפיים של מסד הנתונים. סיבה אחת שיכולה להיות קשורה ל-Cloud SQL היא חביון ברשת, כשהמשאב של המקור (כותב או קורא) והמשאב של היעד (Cloud SQL) נמצאים באזורים שונים. כדאי לעיין במיוחד ב טיפים כלליים לשיפור הביצועים. אם פעולות ההוספה, העדכון או המחיקה במסד הנתונים מתבצעות לאט, כדאי לבצע את הפעולות הבאות: בודקים את המיקומים של הכותב ומסד הנתונים. שליחת נתונים למרחק רב גורמת לזמן אחזור. בודקים את המיקום של הקורא ומסד הנתונים. זמן האחזור משפיע על ביצועי הקריאה אפילו יותר מאשר על ביצועי הכתיבה כדי להקטין את זמן האחזור, מומלץ למקם את משאבי המקור והיעד באותו אזור.
מוצגת הודעה על חוסר בזיכרון, אבל בתרשימי המעקב לא רואים את זה.	יכול להיות שמופע ייכשל וידווח על Out of memory, אבל נראה בתרשימים של מסוף Google Cloud או Cloud Monitoring שעדיין יש זיכרון פנוי. יש גורמים נוספים מלבד עומס העבודה שיכולים להשפיע על השימוש בזיכרון, כמו מספר החיבורים הפעילים ותהליכי התקורה הפנימיים. השינויים האלה לא תמיד משתקפים בתרשימי המעקב. מוודאים שיש מספיק תקורה למופע כדי להתחשב בעומס העבודה, בתוספת תקורה נוספת.
שחזור מופע שנמחק.	כל הנתונים במופע, כולל הגיבויים, אובדים לתמיד כשמוחקים את המופע. כדי לשמור את הנתונים, צריך לייצא אותם ל-Cloud Storage לפני ש מוחקים את המופע. התפקיד Cloud SQL Admin כולל את ההרשאה למחוק את המופע. כדי למנוע מחיקה בטעות, כדאי להקצות את התפקיד הזה רק כשצריך.
רוצים לשנות את השם של מופע קיים ב-Cloud SQL.	אי אפשר לשנות את השם של מופע קיים. יש דרכים אחרות להשיג את המטרה על ידי יצירת מופע חדש. אפשר לשכפל את המכונה שרוצים לשנות את השם שלה ולהגדיר שם חדש למכונה המשוכפלת. כך תוכלו ליצור את המופע החדש בלי לייבא נתונים באופן ידני. בדיוק כמו כשיוצרים מכונה חדשה, למכונה המשוכפלת יש כתובת IP חדשה. אפשר לייצא נתונים מהמכונה לקטגוריה של Cloud Storage, ליצור מכונה חדשה עם השם החדש שרוצים, ואז לייבא את הנתונים למכונה החדשה. בשני המקרים, אפשר למחוק את המופע הישן אחרי שהפעולה מסתיימת. מומלץ לבחור באפשרות של שיבוט, כי היא לא משפיעה על הביצועים ולא מחייבת אתכם להגדיר מחדש את ההגדרות של המופע, כמו דגלים, סוג המכונה, גודל האחסון והזיכרון.
שגיאה במחיקת מופע.	אם ההגנה מפני מחיקה מופעלת עבור מופע, צריך לאשר את התוכניות למחיקת המופע. לאחר מכן משביתים את ההגנה מפני מחיקה לפני שמוחקים את המופע.

התחברות לשירות פרטי

שגיאה	פתרון בעיות
הקובץ המצורף של השירות של המופע לא מקבל את נקודת הקצה של Private Service Connect.	בודקים את הסטטוס של נקודת הקצה. gcloud כדי לבדוק את הסטטוס, משתמשים בפקודה gcloud compute forwarding-rules describe. gcloud compute forwarding-rules describe ENDPOINT_NAME \ --project=PROJECT_ID \ --region=REGION_NAME \ | grep pscConnectionStatus מחליפים את הפרטים הבאים: ‫ENDPOINT_NAME: השם של נקודת הקצה ‫PROJECT_ID: המזהה או מספר הפרויקט של Google Cloud הפרויקט שמכיל את נקודת הקצה ‫REGION_NAME: שם האזור של נקודת הקצה REST לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים: ‫PROJECT_ID: המזהה או מספר הפרויקט של Google Cloud הפרויקט שמכיל את נקודת הקצה של Private Service Connect ‫REGION_NAME: שם האזור ‫ENDPOINT_NAME: השם של נקודת הקצה ה-method של ה-HTTP וכתובת ה-URL: GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות: ‫Curl (Linux,‏ macOS או Cloud Shell) הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list. מריצים את הפקודה הבאה: curl -X GET \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME" ‎PowerShell (Windows) הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list. מריצים את הפקודה הבאה: $cred = gcloud auth print-access-token $headers = @{ "Authorization" = "Bearer $cred" } Invoke-WebRequest ` -Method GET ` -Headers $headers ` -Uri "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME" | Select-Object -Expand Content אתם אמורים לקבל תגובת JSON שדומה לזו: { "kind": "compute#forwardingRule", "id": "ENDPOINT_ID", "creationTimestamp": "2024-05-09T12:03:21.383-07:00", "name": "ENDPOINT_NAME", "region": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME", "IPAddress": "IP_ADDRESS", "target": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/serviceAttachments/SERVICE_ATTACHMENT_NAME", "selfLink": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME", "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default", "serviceDirectoryRegistrations": [ { "namespace": "goog-psc-default" } ], "networkTier": "PREMIUM", "labelFingerprint": "LABEL_FINGERPRINT_ID", "fingerprint": "FINGERPRINT_ID", "pscConnectionId": "CONNECTION_ID", "pscConnectionStatus": "ACCEPTED", "allowPscGlobalAccess": true } מוודאים שהסטטוס של נקודת הקצה הוא ACCEPTED. אם הסטטוס הוא PENDING, המשמעות היא שהמופע לא מאפשר את הפרויקט שמכיל את נקודת הקצה. Google Cloud מוודאים שהפרויקט ברשת שבו נוצרה נקודת הקצה מותר. מידע נוסף זמין במאמר עריכת מופע עם Private Service Connect מופעל.
ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource: The resource 'projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME' was not found	הודעת השגיאה הזו יכולה להופיע כשמזמינים כתובת IP פנימית סטטית לנקודת הקצה (endpoint) של Private Service Connect. מוודאים שרשת המשנה שצוינה קיימת בפרויקט שצוין ב-URI. אם רוצים ליצור נקודת קצה בפרויקט שירות אבל להשתמש בתת-רשת מרשת VPC משותפת, צריך לציין את תת-הרשת באמצעות ה-URI שלה ולהשתמש במזהה הפרויקט של פרויקט המארח ב-URI. מידע נוסף זמין במאמר יצירת נקודת הקצה באופן ידני.
ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource: - The resource 'projects/PROJECT_ID/global/networks/NETWORK_NAME' was not found	הודעת השגיאה הזו יכולה להופיע כשיוצרים נקודת קצה (endpoint) של Private Service Connect באופן ידני. מוודאים שהרשת שצוינה קיימת בפרויקט שצוין ב-URI. אם רוצים ליצור נקודת קצה בפרויקט שירות אבל להשתמש ברשת VPC משותפת, צריך לציין את הרשת באמצעות ה-URI שלה ולהשתמש במזהה הפרויקט של פרויקט המארח ב-URI. מידע נוסף זמין במאמר יצירת נקודת הקצה באופן ידני.
Invalid consumer network status for PSC auto connection.	הרשת של הצרכן לא מוגדרת נכון או לא מוגדרת בכלל, ולכן אין נקודת קצה שאפשר להתחבר אליה. כדי להתחבר לנקודת הקצה, צריך לבדוק את הסטטוס שלה ולתקן את השגיאה לפני שמנסים להתחבר שוב. כדי לבדוק את הסטטוס של נקודת קצה, אפשר לעיין במאמר אחזור נקודת הקצה. הסטטוס של נקודת הקצה יכול להיות אחד מהבאים: ‫CONNECTION_POLICY_MISSING: אין מדיניות תואמת של חיבור שירות ברשת הצרכן. מדיניות חיבור לשירותים מוגדרת לפי רשת, לפי אזור. כדי להגדיר מחדש את הרשת, אפשר לעיין במאמר בנושא עדכון מדיניות חיבור לשירות. ‫CONSUMER_INSTANCE_PROJECT_NOT_ALLOWLISTED: יש מדיניות תואמת של חיבור שירות, אבל השדה היקף מופע השירות במדיניות לא מוגדר כך שיאפשר חיבור למופע הזה של Cloud SQL. מעדכנים את המדיניות כדי להגדיר את הערך של השדה היקף מופע השירות (--producer-instance-location) עם הפרויקט, התיקייה או הארגון שבהם נמצא מופע Cloud SQL. כדי להגדיר מחדש את המדיניות של חיבור השירות, אפשר לעיין במאמר עדכון מדיניות של חיבור שירות. ‫POLICY_LIMIT_REACHED: מדיניות החיבור לשירות הגיעה למגבלת נקודות הקצה. כדי לפתור את הבעיה, צריך להגדיל את מגבלת נקודות הקצה על ידי עדכון המדיניות של חיבור השירות.
No permission to create a service connection policy.	אין לכם את ההרשאות הנדרשות כדי ליצור מדיניות של חיבור שירות. כדי ליצור מדיניות לחיבור שירות, צריך את התפקיד Compute Network Admin IAM. מידע נוסף זמין במאמר בנושא תפקידים והרשאות.
לא ניתן לקבל חיבורים מהממשק של Private Service Connect לקובץ המצורף עם הרשת כשמשתמשים בקישוריות יוצאת של Private Service Connect.	אם הרשת החיצונית לא יכולה לקבל חיבורים מממשק Private Service Connect, יכול להיות שמדיניות החיבורים בקובץ המצורף של הרשת לא מוגדרת בצורה נכונה. צריך להגדיר את הקבצים המצורפים לרשת כך שיקבלו את כל החיבורים באופן אוטומטי, או להגדיר אותם באופן ידני עם רשימה של חיבורים מאושרים. מידע נוסף זמין במאמר בנושא מדיניות חיבור. כדי לאמת את החיבורים שאושרו, מריצים את הפקודה הבאה בקובץ המצורף לרשת: gcloud compute network-attachments describe default --region=REGION_ID אם הממשק של Private Service Connect לא מופיע ברשימה המקובלת, צריך לעדכן את הקובץ המצורף עם הרשת. מידע נוסף מופיע במאמר בנושא ניהול קבצים מצורפים ברשת.

שכפול

שגיאה	פתרון בעיות
השכפול של העותק לקריאה לא התחיל בזמן היצירה.	כנראה שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
אי אפשר ליצור עותק לקריאה – השגיאה invalidFlagValue.	אחד מהדגלים בבקשה לא תקין. יכול להיות שזה דגל שציינתם באופן מפורש או דגל שהוגדר לו ערך ברירת מחדל. קודם כול, בודקים שהערך של הדגל max_connections גדול מהערך בשרת הראשי או שווה לו. אם הדגל max_connections מוגדר בצורה מתאימה, בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
לא ניתן ליצור עותק לקריאה – שגיאה לא ידועה.	כנראה שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל. אם השגיאה היא: set Service Networking service account as servicenetworking.serviceAgent role on consumer project, צריך להשבית ואז להפעיל מחדש את Service Networking API. הפעולה הזו יוצרת את חשבון השירות שנדרש כדי להמשיך בתהליך.
הדיסק מלא.	יכול להיות שהנפח של הדיסק של המופע הראשי יתמלא במהלך יצירת העותק. עורכים את המופע הראשי כדי לשדרג אותו לגודל דיסק גדול יותר.
מופע הרפליקה משתמש ביותר מדי זיכרון.	העותק משתמש בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמבוקשות לעיתים קרובות, מה שעלול לגרום לו להשתמש ביותר זיכרון מהמופע הראשי. מפעילים מחדש את מופע הרפליקה כדי לפנות את המקום הזמני בזיכרון.
השכפול הופסק.	הגעתם למגבלת האחסון המקסימלית ולא הפעלתם את האפשרות להגדלת נפח האחסון באופן אוטומטי. עורכים את המופע כדי להפעיל את automatic storage increase.
ההשהיה בשכפול גבוהה באופן עקבי.	עומס הכתיבה גבוה מדי בשביל העותק. השהיית שכפול מתרחשת כשה-SQL thread בעותק לא מצליח לעמוד בקצב של ה-IO thread. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום לעיכובים זמניים או קבועים בשכפול של סכימה נתונה. חלק מהסיבות האופייניות לעיכוב בשכפול: שאילתות איטיות בעותק המשוכפל. צריך לאתר את הבעיות ולתקן אותן. שאילתות כמו DELETE ... WHERE field < 50000000 גורמות לפיגור בשכפול בשכפול מבוסס-שורות, כי מספר עצום של עדכונים מצטבר בעותק המשוכפל. הנה כמה פתרונות אפשריים: עורכים את המופע כדי להגדיל את הגודל של העותק המשוכפל. הפחתת העומס על מסד הנתונים. הפניית תנועת קריאה אל העותק לקריאה בלבד. יוצרים אינדקס לטבלאות. זיהוי ותיקון של שאילתות כתיבה איטיות. יוצרים את העותק המשוכפל מחדש.
יצירת העותק נכשלה בגלל פסק זמן.	עסקאות ארוכות טווח שלא בוצעו במופע הראשי עלולות לגרום לכך שיצירת העתק לקריאה תיכשל. יוצרים מחדש את העותק אחרי שמפסיקים את כל השאילתות הפעילות.