בדף הזה יש טיפים לפתרון בעיות ב-Cloud SQL עבור מנועי מסדי נתונים נתמכים. חלק מהטיפים האלה רלוונטיים רק למנועי מסד נתונים ספציפיים, ואחרים רלוונטיים לכולם.
טיפים לפתרון בעיות במנועי מסדי נתונים ספציפיים מופיעים בדפים שלהם:
כדאי לבדוק אם השאלה או הבעיה שלך כבר קיבלו מענה באחד מהדפים הבאים:
- שאלות נפוצות
- בעיות מוכרות
- הודעות שגיאה
- אבחון בעיות
- ניפוי באגים בבעיות בחיבור
- בעיות בעדכון נפח האחסון
הנושאים בדף הזה:
- גיבוי ושחזור
- שיבוט
- קישוריות
- יצירת מופעים
- הרצת SQL באמצעות Data API
- חיצוני ראשי
- External replica
- Flags
- זמינות גבוהה
- ייבוא וייצוא
- שילוב עם Vertex AI
- שרתים מקושרים
- Logging
- ניהול מופעים
- Private Service Connect
- שכפול
גיבוי ושחזור
| שגיאה | פתרון בעיות |
|---|---|
| אי אפשר לראות את הסטטוס של הפעולה הנוכחית. | הדוח במסוף Google Cloud מציג רק אם הפעולה הושלמה בהצלחה או נכשלה. הוא לא מיועד להצגת אזהרות או עדכונים אחרים.
מריצים את הפקודה
|
| אתם רוצים לדעת מי ביצע פעולת גיבוי לפי דרישה. | בממשק המשתמש לא מוצג המשתמש שהתחיל פעולה.
בודקים ביומנים ומסננים לפי טקסט כדי למצוא את המשתמש. יכול להיות שתצטרכו להשתמש ביומני ביקורת כדי לגשת למידע פרטי. קובצי יומן רלוונטיים כוללים:
|
| אחרי שמחקתם מופע, אי אפשר לגבות אותו. | אם מוחקים מופע בלי ליצור גיבוי סופי של הנתונים, לא ניתן לשחזר את הנתונים. עם זאת, אם משחזרים את המכונה, Cloud SQL משחזר גם את הגיבויים. מידע נוסף על שחזור מופע שנמחק זמין במאמר שמירת גיבויים אחרי מחיקת מופע. אם ביצעתם פעולת ייצוא, צריך ליצור מופע חדש ואז לבצע פעולת ייבוא כדי ליצור מחדש את מסד הנתונים. קובצי הייצוא נכתבים ב-Cloud Storage וקובצי הייבוא נקראים משם. |
| גיבוי אוטומטי נתקע למשך שעות רבות ואי אפשר לבטל אותו. | הגיבויים יכולים להימשך זמן רב, בהתאם לגודל מסד הנתונים.
אם אתם ממש צריכים לבטל את הפעולה, אתם יכולים לבקש מ
תמיכת הלקוחות לבטל |
| פעולת שחזור יכולה להיכשל אם משתמש אחד או יותר שמצוינים בקובץ ה-SQL dump לא קיימים. | לפני שמשחזרים SQL dump, כל המשתמשים במסד הנתונים שיש בבעלותם אובייקטים או שקיבלו הרשאות לאובייקטים במסד הנתונים שהושלך חייבים להיות קיימים במסד הנתונים של היעד. אם לא, פעולת השחזור תיכשל ולא תיצור מחדש את האובייקטים עם הבעלות או ההרשאות המקוריות.
יוצרים את משתמשי מסד הנתונים לפני שמשחזרים את קובץ ה-SQL. |
| אתם רוצים להגדיל את מספר הימים שבהם אפשר לשמור גיבויים אוטומטיים מ-7 ל-30 ימים, או יותר. | אפשר
להגדיר את מספר הגיבויים האוטומטיים שיישארו. גיבויים אוטומטיים נמחקים באופן קבוע על סמך ערך השמירה שהוגדר. לכן, הגיבויים שמוצגים כרגע הם הגיבויים האוטומטיים היחידים שאפשר לשחזר מהם.
כדי לשמור גיבויים ללא הגבלת זמן, אתם יכולים ליצור גיבוי לפי דרישה, כי הם לא נמחקים כמו גיבויים אוטומטיים. גיבויים לפי דרישה נשארים ללא הגבלת זמן. כלומר, הן נשארות עד שהן נמחקות או עד שהמופע שאליו הן שייכות נמחק. הגיבוי הזה לא נמחק אוטומטית, ולכן הוא יכול להשפיע על החיוב. |
| גיבוי אוטומטי נכשל ולא קיבלתם התראה באימייל. | כדי לקבל מ-Cloud SQL התראה על סטטוס הגיבוי, צריך להגדיר התראה מבוססת-יומן. |
| גיבוי אוטומטי או גיבוי לפי דרישה נכשל במופע עם יותר מ-50 תוויות שהוגדרו על ידי המשתמש. | כשמערכת Cloud SQL יוצרת גיבוי, היא מעתיקה את התוויות שהוגדרו על ידי המשתמשים של המכונה לתמונת המצב של האחסון הבסיסי, ומוסיפה תוויות פנימיות של המערכת. אם המספר הכולל של התוויות חורג מהמגבלה של 64 תוויות בצילום המצב, הגיבוי נכשל.
כדי לפתור את הבעיה, צריך להסיר תוויות מיותרות כך שיהיו למופע 50 תוויות או פחות שהוגדרו על ידי המשתמש. מידע נוסף מופיע במאמר בנושא הוספת תוויות למופעים. |
| מופע נכשל שוב ושוב כי הוא עובר בין מצבי הכשל לבין מצבי שחזור הגיבוי. ניסיונות להתחבר למסד הנתונים ולהשתמש בו אחרי השחזור נכשלים. |
פעולות שכדאי לנסות:
|
| גיליתם שחסרים נתונים כשביצעתם פעולת גיבוי או שחזור. | הטבלאות נוצרו כטבלאות לא מתועדות. לדוגמה:
הטבלאות האלה לא נכללות בשחזור מגיבוי:
הפתרון הוא להימנע משימוש בטבלאות שלא נרשמו ביומן אם רוצים לשחזר את הטבלאות האלה באמצעות גיבוי. אם אתם משחזרים ממסד נתונים שכבר מכיל טבלאות לא מתועדות, אתם יכולים להעביר את מסד הנתונים לקובץ ואז לטעון מחדש את הנתונים אחרי שתשנו את הקובץ שהועבר מ- |
| אי אפשר למחוק מופע כשבוחרים ליצור גיבוי סופי בזמן מחיקת המופע. |
כשמוחקים מופע, צריך לאשר אם רוצים ליצור גיבוי סופי של המופע לפני המחיקה. אם הפעלתם גיבוי סופי באמצעות הגדרת המופע final-backup, הבחירה שתבצעו כשאתם מוחקים את המופע חייבת להיות זהה להגדרת המופע של הגיבוי הסופי שהגדרתם כשהפעלתם גיבוי סופי למופע. כדי לפתור את הבעיה, אפשר לנסות את הפתרונות הבאים:
|
| לא ניתן ליצור מופע משוכפל אחרי יצירה מוצלחת של מופע ראשי עם הגדרת הגיבוי הסופית. |
אם יוצרים מופע חדש עם ההגדרה של מופע הגיבוי הסופי מופעלת, צריך לעדכן את מדיניות הארגון של הגיבוי הסופי כדי להחיל את הגדרות הגיבוי רק על המופע הראשי.
אין תמיכה בגיבויים סופיים של מופעי העתקה. מידע נוסף זמין במאמר מדיניות הארגון של Cloud SQL. |
שכפל
| שגיאה | פתרון בעיות |
|---|---|
השיבוט נכשל עם השגיאה constraints/sql.restrictAuthorizedNetworks. |
הפעולה של שיבוט נחסמת על ידי ההגדרה של Authorized Networks.
Authorized Networks מוגדרות לכתובות IP ציבוריות בקטע Connectivity (קישוריות) במסוף 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]. |
ניסיתם להשתמש במסוף Google Cloud כדי לשכפל מכונה עם כתובת IP פרטית, אבל לא ציינתם את טווח כתובות ה-IP שהוקצה שבו אתם רוצים להשתמש, והמכונה המקורית לא נוצרה עם הטווח שצוין. כתוצאה מכך, המכונה המשובטת נוצרת בטווח אקראי. משתמשים ב- |
חיבור
| שגיאה | פתרון בעיות |
|---|---|
Aborted connection. |
הבעיה יכולה להיות:
האפליקציות צריכות להיות עמידות בפני כשלים ברשת ולפעול לפי השיטות המומלצות, כמו איגום חיבורים וניסיון חוזר. רוב כלי הניהול של מאגרי החיבורים מזהים את השגיאות האלה כשהדבר אפשרי. אחרת, האפליקציה צריכה לנסות שוב או להיכשל בצורה מסודרת. כדי לנסות שוב להתחבר, מומלץ להשתמש בשיטות הבאות:
שילוב של השיטות האלה עוזר לצמצם את ההגבלה. |
| זמן קצוב לתפוגה של חיבור או שגיאה כללית בחיבור כשמשתמשים בכתובת IP פרטית או בקישור בין רשתות VPC שכנות (peering). | ניסיונות החיבור נכשלים עם שגיאות כלליות של זמן קצוב לתפוגה או שגיאות חיבור ללא פרטי אבחון. שלבים לפתרון בעיות:
פרטים נוספים ופקודות אבחון של gcloud זמינים במאמר אבחון כשלים בחיבור לרשת VPC ולכתובות IP פרטיות. |
הודעת שגיאה: Login failed for user "" |
יכול להיות שתיתקלו בשגיאת ההתחברות הזו במהלך אימות של Microsoft Entra ID. כדי לפתור את הבעיה, ודא שקיימת התחברות ל-SQL Server עבור משתמש Microsoft Entra ID זה. |
| בעיות בקישוריות לרשת עם מופעים של כתובות IP פרטיות | יכול להיות שתיתקלו באחת מהבעיות הבאות במהלך ההגדרה של השילוב:
מידע נוסף על פתרון הבעיות האלה זמין במאמר בנושא פתרון בעיות בשילוב עם 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 הקיים שהוקצה או להקצות טווח כתובות 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 עומדים בקריטריונים הבאים:
|
הרצת SQL באמצעות Data API
| שגיאה | פתרון בעיות |
|---|---|
The instance doesn't allow using ExecuteSql to access this instance.
You can allow it by patching the instance with {settings: { dataApiAccess:
"ALLOW_DATA_API" }}
|
ממשק ה-API לנתונים מושבת כברירת מחדל. כדי לפתור את הבעיה, צריך להפעיל את Data API במופע. |
Secret cannot be provided when auto_iam_authn is true.
|
כשמגדירים את auto_iam_authn ל-true, מתבצע אימות למסד הנתונים באמצעות IAM.
שיטת האימות הזו לא דורשת סיסמה או סוד.
אימות באמצעות IAM
|
ExecuteSql API is not supported for instances in certain
Assured Workloads control packages folders yet.
|
יכול להיות שתסריט ה-SQL והתגובה להרצה שלו יעברו דרך מיקומים ביניים בין הלקוח לבין המיקום של מופע היעד. לכן, בקשות ייכשלו עבור מקרים בפרויקטים מסוימים של Assured Workloads. אם הפרויקט שלכם לא רשום ב-Assured Workloads אבל constraints/sql.restrictNoncompliantResourceCreation נאכף באופן ידני, צריך לבקש מהאדמין בארגון להסיר את האילוץ. הבעיה תיפתר במופעים שייווצרו.
|
The database is currently unavailable.
|
יכול להיות שהמופע מופעל מחדש, עובר תחזוקה או שהוא במצב לא תקין. צריך לבדוק את הסטטוס של המופע ולנסות שוב מאוחר יותר. |
ייצוא
| שגיאה | פתרון בעיות |
|---|---|
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 מכיל הפניות לתוסף שלא נתמך. |
שגיאה בשימוש ב-pg_dumpall. |
כדי להשתמש בכלי pg_dumpall עם הדגל --global, צריך להיות לכם תפקיד של משתמש על, אבל התפקיד הזה לא נתמך ב-Cloud SQL. כדי למנוע שגיאות במהלך פעולות ייצוא שכוללות שמות משתמשים, צריך להשתמש גם בדגל --no-role-passwords.
|
הפעולה של הייצוא נכשלת בגלל חריגה מזמן קצוב לתפוגה לפני שמתבצע ייצוא של משהו, ומופיעה הודעת השגיאה Could not receive data from client: Connection reset
by peer. |
אם Cloud Storage לא מקבל נתונים בפרק זמן מסוים, בדרך כלל כ-7 דקות, החיבור מתאפס. יכול להיות ששאילתת הייצוא הראשונית נמשכת יותר מדי זמן.
מבצעים ייצוא ידני באמצעות
הכלי |
| אתם רוצים שהייצוא יהיה אוטומטי. | ב-Cloud SQL אין אפשרות לייצא באופן אוטומטי.
אפשר ליצור מערכת ייצוא אוטומטית משלכם באמצעות Google Cloudמוצרים כמו Cloud Scheduler, Pub/Sub ופונקציות Cloud Run, בדומה למאמר הזה בנושא גיבוי אוטומטי. |
חיצוני ראשי
| שגיאה | פתרון בעיות |
|---|---|
Lost connection to MySQL server during query when dumping table. |
יכול להיות שהמקור הפך ללא זמין, או שה-dump הכיל חבילות גדולות מדי.
מוודאים שהמקור הראשי החיצוני זמין לחיבור. אפשר גם לשנות את הערכים של הדגלים net_read_timeout ו-net_write_timeout במופע המקור כדי שהשגיאה לא תופיע. מידע נוסף על הערכים המותרים של הדגלים האלה זמין במאמר בנושא הגדרת דגלים של מסד נתונים. מידע נוסף על שימוש בדגלים של |
הגיבוי הראשוני נכשל בגלל שגיאות שקשורות לזמן קצוב לתפוגה או לניתוק מהחיבור (לדוגמה,
Dump timeout או Lost connection to MySQL server). |
השגיאה הזו יכולה להתרחש אם הצהרת DDL אחת או יותר יוצרת אינטראקציה עם תהליך ה-dump המקביל, וגורמת לתהליך להמתין ללא הגבלת זמן.
פתרון: אל תריצו הצהרות DDL במסד הנתונים של המקור במהלך שלב ההעברה הראשוני. לפני שמריצים הצהרות DDL, מפעילים מחדש את ההעברה וממתינים לסיום שלב הגיבוי הראשוני. |
| המיגרציה הראשונית של הנתונים הושלמה, אבל לא מתבצעת שכפול של הנתונים. | אחת הסיבות האפשריות לכך היא שבמסד הנתונים של המקור הוגדרו דגלי שכפול שגורמים לכך שחלק מהשינויים במסד הנתונים או כולם לא משוכפלים. מוודאים שדגלי השכפול, כמו מריצים את הפקודה |
| המיגרציה הראשונית של הנתונים הושלמה בהצלחה, אבל שכפול הנתונים מפסיק לפעול אחרי זמן מה. | פעולות שכדאי לנסות:
אם מופיעה השגיאה
|
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 חדש באמצעות הגדרות הדגל הנכונות, ומגדירים את העותק החיצוני באמצעות הקובץ הזה.
|
דגלים
| שגיאה | פתרון בעיות |
|---|
זמינות גבוהה
| שגיאה | פתרון בעיות |
|---|---|
| אי אפשר למצוא את המדדים של מעבר ידני לגיבוי. | רק מעברים אוטומטיים לגיבוי נכללים במדדים. |
| השימוש במשאבים (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 מחליפים את 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
|
האפשרות 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]. היומנים האלה מסוננים כי הם עלולים לגרום לבלבול.
|
| הרישום ביומן משתמש בהרבה מקום בדיסק. | יש שלושה סוגים של קובצי יומן שצורכים נפח אחסון בדיסק: יומני פעולות חוזרות (redo),
יומנים כלליים ויומנים בינאריים.
מתחברים למסד הנתונים ומריצים את הפקודות האלה כדי לקבל פרטים על כל סוג: SHOW VARIABLES LIKE 'innodb_log_file%'; SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2),2) AS GB from mysql.general_log; SHOW BINARY LOGS; |
| קשה לקרוא את קובצי היומן. | אתם מעדיפים לראות את היומנים כ-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 |
| יומני השאילתות לא נמצאים ביומני PostgreSQL. | צריך להפעיל את הדגלים pgaudit.
|
ניהול מופעים
| שגיאה | פתרון בעיות |
|---|---|
| ביצועים איטיים אחרי הפעלה מחדש של MySQL. | ב-Cloud SQL אפשר לשמור נתונים במטמון במאגר הנתונים הזמני של InnoDB. עם זאת, אחרי הפעלה מחדש, המטמון הזה תמיד ריק, וכל פעולת קריאה דורשת תהליך הלוך ושוב לשרת העורפי כדי לקבל נתונים. כתוצאה מכך, יכול להיות שהשאילתות יהיו איטיות מהצפוי עד שהמטמון יתמלא. |
| התאוששות איטית מקריסה. | יכול להיות שנצבר סכום גדול של general_log.
כדי לקצר את זמן השחזור אחרי קריסה, מומלץ למנוע הצטברות של general_log גדול. אם האפשרות general_log מופעלת, כדאי לקצר את הטבלה ולהפעיל את general_log רק לפרקי זמן קצרים.
כדי לדעת מה הגודל של היומנים הכלליים, מתחברים למסד הנתונים ומריצים את השאילתה הבאה: SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;
|
| אתם רוצים לדעת מה תופס נפח אחסון. | לדוגמה, אם אתם רואים שהמסד נתונים שלכם משתמש רק ב-3GB, אבל בנתוני האחסון מצוין שנעשה שימוש ב-14GB. רוב הנפח שלא משמש את הטבלאות משמש ליומנים בינאריים או לקבצים זמניים.
פעולות שכדאי לנסות:
|
| השאילתות חסומות. | יכול להיות ששאילתות ינעלו את מסד הנתונים של MySQL, ויגרמו לכל השאילתות הבאות להיחסם או להגיע לזמן קצוב לתפוגה.
מתחברים למסד הנתונים ומריצים את השאילתה הבאה:
יכול להיות שהפריט הראשון ברשימה הוא זה שמחזיק את הנעילה, והפריטים הבאים ממתינים לו.
|
| אי אפשר למחוק יומני בינאריים באופן ידני. | אי אפשר למחוק יומנים בינאריים באופן ידני. יומני בינאריים נמחקים אוטומטית עם הגיבוי האוטומטי המשויך, בדרך כלל אחרי שבעה ימים. |
| אתם רוצים למצוא מידע על קבצים זמניים. | קובץ בשם ibtmp1 משמש לאחסון נתונים זמניים. הקובץ הזה מאופס כשמפעילים מחדש את מסד הנתונים. כדי למצוא מידע על השימוש בקובץ זמני, מתחברים למסד הנתונים ומריצים את השאילתה הבאה:
|
| רוצים לדעת מה גודל הטבלה. | המידע הזה זמין במסד הנתונים.
מתחברים למסד הנתונים ומריצים את השאילתה הבאה:
|
| mysqld קיבל אות 11. | נסו לבצע רפקטורינג של שאילתות כדי שלא ייצרו יותר מדי חיבורים.
אם הבעיה לא נפתרת, אפשר לפנות לתמיכת לקוחות.
אות 11 בדרך כלל מייצג בעיה בתוכנת MySQL.
|
InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The
settings might not be optimal. |
כלי ניקוי הדפים לא יכול לעמוד בקצב השינויים במופע.
פעם בשנייה, כלי הניקוי של הדף סורק את מאגר הנתונים הזמני כדי למצוא דפים לא נקיים, ומרוקן אותם ממאגר הנתונים הזמני לדיסק. האזהרה שמוצגת לכם מציינת שיש הרבה דפים לא נקיים שצריך לנקות, ושלוקח יותר משנייה לנקות קבוצה של דפים כאלה בדיסק.
מפצלים את המכונה אם אפשר. עדיף להשתמש בהרבה מכונות קטנות של Cloud SQL מאשר במכונה גדולה אחת. |
| אתם רוצים לדעת אילו שאילתות מופעלות עכשיו. | מתחברים למסד הנתונים ומריצים את השאילתה הבאה:
|
| אתם רוצים לדעת באילו יחידות נעשה שימוש בשדה מסוים. | מתחברים למסד הנתונים ומריצים את השאילתה הבאה
(באמצעות FIELD_NAME משלכם):
|
| רוצים למצוא את הערך הנוכחי של הגדרת מסד נתונים. | מתחברים למסד הנתונים ומריצים את השאילתה הבאה
(באמצעות SETTING_NAME משלכם):
מריצים את הפקודה |
| רוצים להפסיק תהליך ברקע שנחסם. | למשתמש צריך להיות התפקיד pg_signal_backend.
מריצים את הפקודות הבאות:
|
| השימוש במזהי העסקאות במופע מתקרב ל-100%. | מערכת המעקב הפנימית שלך מתריעה שהמופע מתקרב ל-100%
בצריכת מזהי עסקאות. אתם רוצים להימנע ממעבר של עסקאות,
שיכול לחסום פעולות כתיבה.
יכול להיות שהעבודה של autovacuum חסומה, או שהיא לא משחררת את מזהי העסקאות מספיק מהר כדי לעמוד בקצב של עומס העבודה. כדי למנוע הפסקות שירות בגלל בעיה של חזרה למספרים קודמים של מזהי עסקאות, אפשר לעיין בטיפים האלה לשירות עצמי לטיפול בחזרה למספרים קודמים של מזהי עסקאות. לקבלת עצות כלליות לגבי כוונון, אפשר לעיין במאמר Optimizing, monitoring, and troubleshooting vacuum operations in PostgreSQL. |
| הגדלנו את נפח האחסון הזמני באופן אוטומטי. | האחסון האוטומטי מופעל.
הפעלה מחדש מוחקת את הקבצים הזמניים אבל לא מפחיתה את נפח האחסון. רק תמיכת לקוחות יכולה לאפס את גודל המופע. |
| הנתונים נמחקים באופן אוטומטי. | סביר להניח שסקריפט פועל איפשהו בסביבה שלכם.
בודקים ביומנים את השעה שבה בוצעה המחיקה, ומחפשים אם יש סקריפט לא מורשה שפועל מלוח בקרה או מתהליך אוטומטי אחר. |
| אי אפשר למחוק את המופע. | יכול להיות שתופיע הודעת השגיאה 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 שניות, אפשר להימנע מרוב הכיבויים הלא תקינים, כולל חיבורים משורת הפקודה של מסד הנתונים. אם החיבורים האלה נשארים פתוחים במשך שעות או ימים, יכול להיות שהכיבוי לא יהיה תקין. |
| אי אפשר למחוק משתמש. | כנראה שיש למשתמש אובייקטים במסד הנתונים שתלויים בו. תצטרכו להסיר את האובייקטים האלה או להקצות אותם מחדש למשתמש אחר.
בודקים אילו אובייקטים תלויים במשתמש, ואז משמיטים או מקצים מחדש את האובייקטים האלה למשתמש אחר. |
| שאילתות מסוימות פועלות לאט. | הטיפול בשאילתות יכול להיות איטי מסיבות רבות, בעיקר בגלל היבטים ספציפיים של מסד הנתונים. סיבה אחת שיכולה להיות קשורה ל-Cloud SQL היא חביון ברשת, כשהמשאב של המקור (הכתיבה או הקריאה) והמשאב של היעד (Cloud SQL) נמצאים באזורים שונים.
כדאי לעיין במיוחד ב טיפים כלליים לשיפור הביצועים. אם פעולות ההוספה, העדכון או המחיקה במסד הנתונים מתבצעות לאט, כדאי לבצע את הפעולות הבאות:
כדי להקטין את זמן האחזור, מומלץ למקם את משאבי המקור והיעד באותו אזור. |
| מוצגת הודעה על אין זיכרון פנוי (OOM), אבל בתרשימי המעקב לא רואים את זה. | יכול להיות שמופע ייכשל וידווח על Out of memory, אבל בטבלאות במסוף Google Cloud או בתרשימים ב-Cloud Monitoring ייראה כאילו עדיין יש זיכרון פנוי.
יש עוד גורמים חוץ מעומס העבודה שיכולים להשפיע על השימוש בזיכרון, כמו מספר החיבורים הפעילים ותהליכי התקורה הפנימיים. השינויים האלה לא תמיד משתקפים בתרשימי המעקב. מוודאים שיש מספיק תקורה למופע כדי להתחשב בעומס העבודה, בתוספת תקורה נוספת. |
| שחזור של מופע שנמחק. | כל הנתונים במופע, כולל הגיבויים, אובדים לתמיד כשמוחקים את המופע.
כדי לשמור את הנתונים, צריך לייצא אותם ל-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 פנימית סטטית לנקודת הקצה (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. |
הרשת הצרכנית לא מוגדרת בצורה נכונה, או שהיא לא מוגדרת בכלל, ולכן אין נקודת קצה שאפשר להתחבר אליה. כדי להתחבר לנקודת הקצה, צריך לבדוק את הסטטוס שלה ולתקן את השגיאה לפני שמנסים להתחבר שוב.
|
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 בעותק לא מצליח לעמוד בקצב של
שרשור הקלט/פלט. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום להשהיה גבוהה זמנית או קבועה בשכפול של סכימה נתונה. חלק מהסיבות האופייניות לעיכוב בשכפול:
הנה כמה פתרונות אפשריים:
|
| יצירת העותק נכשלה בגלל פסק זמן. | עסקאות ארוכות טווח שלא בוצעו במופע הראשי עלולות לגרום לכשל ביצירת רפליקה לקריאה.
אחרי שמפסיקים את כל השאילתות הפעילות, יוצרים מחדש את העותק. |