כדאי לבדוק אם השאלה או הבעיה שלך כבר קיבלו מענה באחד מהדפים הבאים:
הנושאים בדף הזה:
- גיבוי ושחזור
- שיבוט
- קישוריות
- יצירת מופעים
- Flags
- זמינות גבוהה
- ייבוא וייצוא
- שרתים מקושרים
- Logging
- ניהול מופעים
- Private Service Connect
- שכפול
גיבוי ושחזור
| שגיאה | פתרון בעיות |
|---|---|
| אי אפשר לראות את הסטטוס של הפעולה הנוכחית. | במסוף Google Cloud מוצג רק אם הפעולה הצליחה או נכשלה. הוא לא מיועד להצגת אזהרות או עדכונים אחרים.
מריצים את
הפקודה |
| אתם רוצים לדעת מי ביצע פעולת גיבוי לפי דרישה. | בממשק המשתמש לא מוצג המשתמש שהתחיל את הפעולה.
בודקים ברישומים ומסננים לפי טקסט כדי למצוא את המשתמש. יכול להיות שתצטרכו להשתמש ביומני ביקורת כדי לגשת למידע פרטי. קובצי יומן רלוונטיים:
|
| אחרי שמוחקים מופע, אי אפשר לגבות אותו. | אם מוחקים מופע בלי ליצור גיבוי סופי של הנתונים, לא ניתן לשחזר את הנתונים. עם זאת, אם משחזרים את המכונה, Cloud SQL משחזר גם את הגיבויים. מידע נוסף על שחזור מופע שנמחק זמין במאמר שמירת גיבויים אחרי מחיקת מופע. אם ביצעתם פעולת ייצוא, צריך ליצור מופע חדש ואז לבצע פעולת ייבוא כדי ליצור מחדש את מסד הנתונים. הייצוא נכתב אל Cloud Storage והייבוא נקרא משם. |
| גיבוי אוטומטי נתקע למשך שעות רבות ואי אפשר לבטל אותו. | גיבויים יכולים להימשך זמן רב, בהתאם לגודל מסד הנתונים.
אם אתם ממש צריכים לבטל את הפעולה, אתם יכולים לבקש מ
תמיכת הלקוחות |
| פעולת שחזור יכולה להיכשל אם משתמש אחד או יותר שמצוינים בקובץ SQL מוכן לשימוש לא קיימים. | לפני שמשחזרים קובץ 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. |
שכפל
| שגיאה | פתרון בעיות |
|---|---|
השיבוט נכשל עם השגיאה constraints/sql.restrictAuthorizedNetworks. |
הפעולה של שיבוט נחסמת על ידי ההגדרה Authorized Networks.
Authorized Networks מוגדרות לכתובות IP ציבוריות בקטע 'קישוריות' במסוף Google Cloud , ואין אפשרות לשכפול בגלל שיקולי אבטחה.
אם אפשר, מסירים את כל הערכים של |
הודעת שגיאה: 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 כתוצאה מכך, המכונה המשוכפלת נוצרת בטווח אקראי. משתמשים ב- |
חיבור
| שגיאה | פתרון בעיות |
|---|---|
Aborted connection. |
הבעיה יכולה להיות:
האפליקציות צריכות להיות עמידות בפני כשלים ברשת ולפעול לפי השיטות המומלצות, כמו איגום חיבורים וניסיון חוזר. רוב כלי הניהול של מאגרי החיבורים מזהים את השגיאות האלה, אם אפשר. אחרת, האפליקציה צריכה לנסות שוב או להיכשל בצורה מסודרת. כדי לנסות שוב להתחבר, מומלץ להשתמש באחת מהשיטות הבאות:
שילוב של השיטות האלה עוזר לצמצם את ההגבלה. |
הודעת שגיאה: Login failed for user "" |
יכול להיות שתיתקלו בשגיאת ההתחברות הזו במהלך אימות ב-Microsoft Entra ID. כדי לפתור את הבעיה, צריך לוודא שיש פרטי כניסה ל-SQL Server עבור המשתמש הזה ב-Microsoft Entra ID. |
| בעיות בקישוריות לרשת עם מופעים של כתובות IP פרטיות | יכול להיות שתיתקלו באחת מהבעיות הבאות במהלך ההגדרה של השילוב:
מידע נוסף על פתרון הבעיות האלה זמין במאמר בנושא פתרון בעיות בשילוב עם 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 הקיים שהוקצה או להקצות טווח כתובות IP נוסף לחיבור הפרטי לשירות. מידע נוסף זמין במאמר בנושא הקצאת טווח כתובות 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 עומדים בקריטריונים הבאים:
|
ייצוא
| שגיאה | פתרון בעיות |
|---|---|
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, אפשר להשתמש בפונקציה |
זמינות גבוהה
| שגיאה | פתרון בעיות |
|---|---|
| אי אפשר למצוא את המדדים של מעבר ידני לגיבוי. | רק מעברים אוטומטיים לגיבוי נכללים במדדים. |
| השימוש במשאבים של מכונת Cloud SQL (מעבד ו-RAM) מתקרב ל-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
|
האפשרות 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' מחליפים את מה שכתוב בשדות הבאים:
|
| התנהגות לא צפויה | אם אתם נתקלים בהתנהגות לא צפויה, ודאו שאתם משתמשים בספק נתמך. מידע נוסף זמין במסמכי העזרה של 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.
אלה כמה מהסיבות האפשריות לכך:
|
| המכונה תקועה בגלל גודל גדול של נתונים זמניים. | המערכת יכולה ליצור הרבה טבלאות זמניות בו-זמנית, בהתאם לשאילתות ולעומס.
לצערנו, אי אפשר להקטין את הקובץ אחת מהאפשרויות לצמצום הסיכון היא ליצור את הטבלה הזמנית באמצעות |
| שגיאה קריטית במהלך השדרוג. | יכול להיות שיומני הרישום יספקו מידע נוסף, אבל בכל מקרה, יכול להיות שתצטרכו תמיכת לקוחות כדי ליצור מחדש את המופע. |
| המופע נתקע בהפעלה מחדש אחרי שנגמר לו המקום בדיסק. | היכולת להגדיל את נפח האחסון באופן אוטומטי לא מופעלת.
אם נפח האחסון של המופע שלכם ייגמר, והיכולת להגדלה אוטומטית של נפח האחסון לא מופעלת, המופע יעבור למצב אופליין. כדי להימנע מהבעיה הזו, אפשר לערוך את המופע כדי להפעיל הגדלה אוטומטית של נפח האחסון. |
| המופע הראשי המקומי תקוע. | Google Cloud לא יכול לעזור עם מופעים שלא נמצאים ב-Cloud SQL. |
| כיבוי איטי בהפעלה מחדש. | כשמכונה מושבתת, כל החיבורים הפתוחים שלא מסתיימים תוך 60 שניות גורמים להשבתה לא תקינה.
אם משך החיבורים קצר מ-60 שניות, אפשר להימנע מרוב השבתות לא נקיות, כולל חיבורים משורת הפקודה של מסד הנתונים. אם משאירים את החיבורים האלה פתוחים במשך שעות או ימים, יכול להיות שהכיבוי לא יהיה תקין. |
| אי אפשר למחוק משתמש. | כנראה שיש למשתמש אובייקטים במסד הנתונים שתלויים בו. תצטרכו להסיר את האובייקטים האלה או להקצות אותם מחדש למשתמש אחר.
בודקים אילו אובייקטים תלויים במשתמש, ואז משחררים אותם או מקצים אותם מחדש למשתמש אחר. בשרשור הזה ב-Stack Exchange מוסבר איך למצוא את האובייקטים שבבעלות המשתמש. |
| שאילתות מסוימות פועלות לאט. | יש הרבה סיבות לכך ששאילתות פועלות לאט, בעיקר בגלל היבטים ספציפיים של מסד הנתונים. סיבה אחת שיכולה להיות קשורה ל-Cloud SQL היא חביון ברשת, כשהמשאב של המקור (הכתיבה או הקריאה) והמשאב של היעד (Cloud SQL) נמצאים באזורים שונים.
כדאי לעיין במיוחד ב טיפים כלליים לשיפור הביצועים. אם פעולות ההוספה, העדכון או המחיקה במסד הנתונים מתבצעות לאט, כדאי לבצע את הפעולות הבאות:
כדי להקטין את זמן האחזור, מומלץ למקם את משאבי המקור והיעד באותו אזור. |
| מוצגת הודעה על חוסר זיכרון, אבל בתרשימי המעקב לא רואים את זה. | יכול להיות שמופע ייכשל וידווח על Out of memory, אבל בטבלאות במסוף או ב-Cloud Monitoring ייראה כאילו עדיין יש זיכרון פנוי. Google Cloud
יש גורמים נוספים מלבד עומס העבודה שיכולים להשפיע על השימוש בזיכרון, כמו מספר החיבורים הפעילים ותהליכי התקורה הפנימיים. הם לא תמיד משתקפים בתרשימי המעקב. מוודאים שיש מספיק תקורה למופע כדי להתחשב בעומס העבודה, בתוספת תקורה נוספת. |
| שחזור של מופע שנמחק. | כל הנתונים במופע, כולל גיבויים, אובדים לתמיד כשמוחקים את המופע.
כדי לשמור את הנתונים, צריך לייצא אותם ל-Cloud Storage לפני שמוחקים את המופע. התפקיד Cloud SQL Admin כולל את ההרשאה למחיקת המכונה. כדי למנוע מחיקה בטעות, צריך להקצות את התפקיד הזה רק כשנדרש. |
| רוצים לשנות את השם של מופע קיים ב-Cloud SQL. | שינוי שם של מופע קיים אינו נתמך.
יש דרכים אחרות להשיג את המטרה על ידי יצירת מופע חדש.
בשני המקרים, אפשר למחוק את המופע הישן אחרי שהפעולה מסתיימת. מומלץ לבחור באפשרות של שיבוט, כי היא לא משפיעה על הביצועים ולא מחייבת אתכם לבצע מחדש הגדרות של מופעים, כמו סימון, סוג מכונה, גודל אחסון וזיכרון. |
| שגיאה במחיקת מופע. | אם ההגנה מפני מחיקה מופעלת עבור מופע, צריך לאשר את התוכניות למחיקת המופע. לאחר מכן, משביתים את ההגנה מפני מחיקה לפני שמוחקים את המופע. |
התחברות לשירות פרטי
| שגיאה | פתרון בעיות |
|---|---|
| הקובץ המצורף עם השירות של המופע לא מקבל את נקודת הקצה של 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 פנימית סטטית לנקודת הקצה של 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. |
הרשת הצרכנית לא מוגדרת בצורה נכונה, או שהיא לא מוגדרת בכלל, ולכן אין נקודת קצה שאפשר להתחבר אליה. כדי להתחבר לנקודת הקצה, צריך לבדוק את הסטטוס שלה ולתקן את השגיאה לפני שמנסים להתחבר שוב.
|
No permission to create a service connection policy. |
אין לכם את ההרשאות הדרושות כדי ליצור מדיניות לחיבור שירותים. כדי ליצור מדיניות של חיבור שירות, צריך את התפקיד |
| לא ניתן לקובץ המצורף עם הרשת לקבל חיבורים מהממשק של Private Service Connect כשמשתמשים בקישוריות יוצאת של Private Service Connect. | אם הרשת החיצונית לא יכולה לקבל חיבורים מממשק Private Service Connect, יכול להיות שמדיניות החיבורים בקובץ המצורף של הרשת לא מוגדרת בצורה נכונה. כדי לאמת את החיבורים שאושרו, מריצים את הפקודה הבאה בקובץ המצורף לרשת: gcloud compute network-attachments describe default --region=REGION_ID |
שכפול
| שגיאה | פתרון בעיות |
|---|---|
| השכפול של העותק לקריאה לא התחיל בזמן היצירה. | סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל. |
| אי אפשר ליצור העתק לקריאה – השגיאה invalidFlagValue. | אחד מהדגלים בבקשה לא תקין. יכול להיות שזה דגל שציינתם באופן מפורש או דגל שהוגדר לו ערך ברירת מחדל.
קודם כול, בודקים שהערך של הדגל אם הדגל |
| לא ניתן ליצור רפליקה לקריאה – שגיאה לא ידועה. | סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן.
בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
אם השגיאה היא: |
| הדיסק מלא. | יכול להיות שהגודל של הדיסק של המופע הראשי יתמלא במהלך יצירת רפליקה. עורכים את המופע הראשי כדי לשדרג אותו לגודל דיסק גדול יותר. |
| מופע הרפליקה משתמש ביותר מדי זיכרון. | הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמבוקשות לעיתים קרובות, מה שעלול לגרום לה להשתמש ביותר זיכרון מהמופע הראשי.
מפעילים מחדש את מופע הרפליקה כדי לפנות את המקום הזמני בזיכרון. |
| השכפול הופסק. | הגעתם למגבלת האחסון המקסימלית ולא הפעלתם את האפשרות להגדלת נפח האחסון באופן אוטומטי.
עורכים את המופע כדי להפעיל את |
| ההשהיה בשכפול גבוהה באופן עקבי. | עומס הכתיבה גבוה מדי בשביל הרפליקה. השהיית שכפול
מתרחשת כשהשרשור של SQL ברפליקה לא מצליח לעמוד בקצב של השרשור של IO. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום לעיכובים זמניים או קבועים בשכפול של סכימה נתונה. חלק מהסיבות הנפוצות להשהיה בשכפול:
הנה כמה פתרונות אפשריים:
|
| יצירת רפליקה נכשלה בגלל זמן קצוב לתפוגה. | עסקאות ארוכות טווח שלא בוצעו במופע הראשי עלולות לגרום לכך שיצירת רפליקת קריאה תיכשל.
אחרי שמפסיקים את כל השאילתות הפעילות, יוצרים מחדש את העותק. |