בדף הזה מפורטים טיפים לפתרון בעיות ב-Cloud SQL במנועים נתמכים של מסדי נתונים. חלק מהטיפים האלה רלוונטיים רק למנועים ספציפיים של מסדי נתונים, ואחרים משותפים לכולם.
לטיפים לפתרון בעיות במנועים ספציפיים של מסדי נתונים, אפשר לעיין בדפים שלהם:
בדקו אם השאלה או הבעיה שלכם כבר קיבלו מענה באחד מהדפים הבאים:
- שאלות נפוצות
- בעיות מוכרות
- הודעות שגיאה
- אבחון בעיות
- ניפוי באגים בבעיות בחיבור
- בעיות בעדכון נפח האחסון
הנושאים בדף הזה:
- גיבוי ושחזור
- שיבוט
- קישוריות
- יצירת מכונות
- הפעלת SQL באמצעות Data API
- ראשי חיצוני
- רפליקה חיצונית
- דגלים
- זמינות גבוהה
- ייבוא וייצוא
- שילוב עם Vertex AI
- שרתים מקושרים
- רישום ביומן
- ניהול מכונות
- Private Service Connect
- שכפול
גיבוי ושחזור
| שגיאה | פתרון בעיות |
|---|---|
| אי אפשר לראות את הסטטוס של הפעולה הנוכחית. | במסוף Google Cloud מדווח רק על הצלחה או כישלון בסיום הפעולה. הוא לא מיועד להצגת אזהרות או עדכונים אחרים.
מריצים את
הפקודה |
| אתם רוצים לגלות מי ביצע פעולת גיבוי על פי דרישה. | בממשק המשתמש לא מוצג המשתמש שהתחיל את הפעולה.
מחפשים ביומנים ומסננים לפי טקסט כדי למצוא את המשתמש. יכול להיות שתצטרכו להשתמש ביומני ביקורת כדי לראות מידע פרטי. קובצי היומן הרלוונטיים כוללים:
|
| אחרי שמוחקים מכונה, אי אפשר לגבות אותה. | אם מוחקים מכונה בלי לבצע גיבוי סופי של הנתונים, אי אפשר לבצע שחזור נתונים. עם זאת, אם משחזרים את המכונה, Cloud SQL משחזר גם את הגיבויים. מידע נוסף על שחזור מכונה שנמחקה זמין במאמר שמירת גיבויים אחרי מחיקת מכונה. אם ביצעתם פעולת ייצוא, צרו מכונה חדשה ואז בצעו פעולת ייבוא כדי ליצור מחדש את מסד הנתונים. הייצוא נכתב ב-Cloud Storage והייבוא נקרא משם. |
| גיבוי אוטומטי תקוע במשך שעות רבות ואי אפשר לבטל אותו. | הגיבויים יכולים להימשך זמן רב, בהתאם לגודל מסד הנתונים.
אם אתם ממש צריכים לבטל את הפעולה, אתם יכולים לבקש מ
תמיכת הלקוחות |
| פעולת שחזור יכולה להיכשל כשמשתמש אחד או יותר שמצוינים בקובץ ה-SQL המוכן לשימוש לא קיימים. | לפני שמשחזרים קובץ dump של SQL, כל המשתמשים במסד הנתונים שיש בבעלותם אובייקטים או שקיבלו הרשאות לאובייקטים במסד הנתונים שהושלך חייבים להיות קיימים במסד הנתונים של היעד. אם אין להם את ההרשאות האלה, פעולת השחזור לא תצליח ליצור מחדש את האובייקטים עם הבעלות או ההרשאות המקוריות.
יוצרים את המשתמשים במסד הנתונים לפני שמשחזרים את ה-SQL dump. |
| אתם רוצים להגדיל את מספר הימים שבהם אפשר לשמור גיבויים אוטומטיים מ-7 ל-30 ימים, או יותר. | אפשר
להגדיר את מספר הגיבויים האוטומטיים שרוצים לשמור. גיבויים אוטומטיים נמחקים באופן קבוע על סמך ערך השמירה שהוגדר. לצערנו, זה אומר שהגיבויים שמוצגים כרגע הם הגיבויים האוטומטיים היחידים שאפשר לשחזר מהם.
כדי לשמור גיבויים ללא הגבלת זמן, אתם יכולים ליצור גיבוי על פי דרישה, כי גיבויים כאלה לא נמחקים כמו גיבויים אוטומטיים. גיבויים לפי דרישה נשמרים ללא הגבלת זמן. כלומר, הם נשארים עד שמוחקים אותם או עד שמוחקים את המכונה שהם שייכים אליה. מכיוון שסוג הגיבוי הזה לא נמחק באופן אוטומטי, הוא יכול להשפיע על החיוב. |
| גיבוי אוטומטי נכשל ולא קיבלתם התראה באימייל. | כדי לקבל מ-Cloud SQL התראה על סטטוס הגיבוי, מגדירים התראה מבוססת-יומן. |
| גיבוי אוטומטי או גיבוי על פי דרישה נכשל במכונה עם יותר מ-50 תוויות שהוגדרו על ידי המשתמש. | כש-Cloud SQL מבצע גיבוי, הוא מעתיק את התוויות שהמשתמשים הגדירו למכונה לתמונת המצב של האחסון הבסיסי, ומוסיף תוויות מערכת פנימיות. אם המספר הכולל של התוויות חורג מהמגבלה של 64 תוויות לכל קובץ snapshot, הגיבוי נכשל.
כדי לפתור את הבעיה, צריך להסיר תוויות עודפות כך שיהיו במכונה עד 50 תוויות שהוגדרו על ידי המשתמש. מידע נוסף זמין במאמר הוספת תוויות למכונות. |
| מכונה נכשלת שוב ושוב כי היא עוברת בין מצבי הכישלון והשחזור מהגיבוי. ניסיונות להתחבר למסד הנתונים ולהשתמש בו אחרי השחזור נכשלים. |
דברים שכדאי לנסות:
|
| אתם מגלים שחסרים נתונים כשאתם מבצעים פעולת גיבוי או שחזור. | הטבלאות נוצרו כלא מתועדות. לדוגמה:
הטבלאות הבאות לא נכללות בשחזור מגיבוי:
כדי לשחזר טבלאות באמצעות גיבוי, צריך להימנע משימוש בטבלאות שלא נרשמו ביומן. אם אתם משחזרים ממסד נתונים שכבר יש בו טבלאות לא מתועדות, אז אתם יכולים להעביר את מסד הנתונים לקובץ dump, ולטעון מחדש את הנתונים אחרי ששיניתם את הקובץ שהועבר מ- |
| אי אפשר למחוק מכונה כשבוחרים ליצור גיבוי סופי בזמן מחיקת המכונה. |
כשמוחקים מכונה, צריך לאשר אם רוצים ליצור גיבוי סופי של המכונה לפני המחיקה. אם הפעלתם את הגיבוי הסופי באמצעות הגדרת המכונה 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]. |
אתם מנסים להשתמש במסוף כדי לשכפל מכונה עם כתובת IP פרטית, אבל לא ציינתם את טווח ה-IP שהוקצה שבו אתם רוצים להשתמש, ומכונת המקור לא נוצרה עם הטווח שצוין. Google Cloud כתוצאה מכך, המכונה המשוכפלת נוצרת בטווח אקראי. משתמשים ב- |
חיבור
| שגיאה | פתרון בעיות |
|---|---|
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 באמצעות הפקודה הבאה: 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" }}
|
Data 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 אין תמיכה בפעולות סינכרוניות בו-זמניות.
להעביר את הייצוא ל-offload. ברמה הכללית, במקום להפעיל ייצוא במכונה המקורית, Cloud SQL מפעיל מכונה ייעודית לביצוע הייצוא. להעברת הייצוא יש כמה יתרונות, כולל שיפור הביצועים במכונה המקורית וביטול החסימה של פעולות ניהוליות בזמן שהייצוא פועל. כשמשתמשים ב-export offloading, זמן האחזור הכולל יכול לגדול במשך הזמן שלוקח להעלות את המכונה של ה-offload. בדרך כלל, בייצוא של נתונים בנפח סביר, זמן האחזור לא משמעותי. עם זאת, אם הייצוא קטן מספיק, יכול להיות שתבחינו בעלייה בזמן האחזור. |
| שגיאה ביצירת התוסף. | קובץ ה-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 הראשוני נכשל בגלל שגיאות של זמן קצוב לתפוגה או של חיבור שאבד (לדוגמה, Dump timeout או Lost connection to MySQL server). |
השגיאה הזו יכולה להתרחש אם הצהרת DDL אחת או יותר יוצרת אינטראקציה עם תהליך ה-dump המקביל, וגורמת לתהליך להמתין ללא הגבלת זמן.
פתרון: אל תריצו הצהרות DDL במסד הנתונים של המקור במהלך שלב ה-dump הראשוני. לפני שמריצים הצהרות DDL, צריך להפעיל מחדש את ההעברה ולהמתין עד שהשלב הראשוני של ה-dump יסתיים. |
| העברת הנתונים הראשונית הצליחה, אבל לא מתבצע שכפול של נתונים. | אחת מהסיבות האפשריות לכך היא שבמסד הנתונים של המקור מוגדרים דגלי רפליקציה, שגורמים לכך שחלק מהשינויים במסד הנתונים או כולם לא משוכפלים. חשוב לוודא שדגלי הרפליקציה, כמו מריצים את הפקודה |
| העברת הנתונים הראשונית הצליחה, אבל שכפול הנתונים מפסיק לפעול אחרי זמן מה. | דברים שכדאי לנסות:
אם מופיעה השגיאה
|
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 חדש באמצעות הגדרות הדגל הנכונות, ומגדירים את הרפליקה החיצונית באמצעות הקובץ הזה.
|
דגלים
| שגיאה | פתרון בעיות |
|---|
זמינות גבוהה
| שגיאה | פתרון בעיות |
|---|---|
| אתם לא מוצאים את המדדים של מעבר ידני לגיבוי במקרה של כשל. | רק מעברים אוטומטיים לגיבוי נכללים במדדים. |
| המשאבים של מכונת Cloud SQL (מעבד ו-RAM) קרובים ל-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. מידע נוסף על הוספת ההרשאות האלה לחשבון השירות זמין במאמר מתן הרשאות של ניהול זהויות והרשאות גישה (IAM) לחשבון השירות של Cloud SQL כדי לגשת ל-Vertex AI. |
הודעת שגיאה: 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.
|
ניהול מופעים
| שגיאה | פתרון בעיות |
|---|---|
| אתם רוצים לדעת מה תופס מקום באחסון. | לדוגמה, נניח שאתם רואים שמסד הנתונים משתמש רק ב-3GB, אבל בנפח האחסון מוצג שימוש של 14GB. שטח שלא משמש את טבלאות מסד הנתונים משמש בדרך כלל ליומני עסקאות, לקבצים זמניים או ליומנים אחרים.
אפשר לראות פירוט של השימוש בדיסק של המכונה לפי סוג הנתונים באמצעות המדד דברים שכדאי לנסות:
|
| ביצועים איטיים אחרי הפעלה מחדש של MySQL. | ב-Cloud SQL אפשר לשמור נתונים במאגר ה-InnoDB buffer pool. עם זאת, אחרי הפעלה מחדש המטמון הזה תמיד ריק, וכל פעולות הקריאה דורשות תהליך הלוך ושוב לקצה העורפי כדי לקבל נתונים. כתוצאה מכך, יכול להיות שהשאילתות יהיו איטיות מהצפוי עד שהמטמון יתמלא. |
| התאוששות איטית מקריסה. | יכול להיות שהצטבר general_log גדול.
כדי לקצר את זמן ההתאוששות מקריסה, אפשר למנוע הצטברות של general_log גדול. אם general_log מופעל, צריך לחתוך את הטבלה ולהפעיל את general_log רק לפרקי זמן קצרים.
כדי לברר את הגודל של היומנים הכלליים, מתחברים למסד הנתונים ומריצים את השאילתה הבאה: SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;
|
| השאילתות חסומות. | שאילתות יכולות לנעול את מסד הנתונים של 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% צריכה של מזהי עסקאות. כדאי להימנע מ-transaction wraparound, שעלול לחסום כתיבות.
יכול להיות שמשימת ה-autovacuum חסומה, או שהיא לא מחזירה את מזהי העסקאות מספיק מהר כדי לעמוד בעומס העבודה. כדי למנוע הפסקות שירות בגלל בעיית wraparound של טרנזקציות, אתם יכולים לעיין בטיפים האלה לשירות עצמי בנושא טיפול ב-TXID wraparound. אם אתם רוצים עצות כלליות לכוונון, תוכלו להיעזר במאמר אופטימיזציה, מעקב ופתרון בעיות של פעולות vacuum ב-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" כולל את ההרשאה למחוק את המכונה. כדי למנוע מחיקה בטעות, כדאי להקצות את התפקיד הזה רק לפי הצורך. |
| אתם רוצים לשנות את השם של מכונה קיימת ב-Cloud SQL. | אי אפשר לשנות את השם של מכונה קיימת.
יש דרכים אחרות להשיג את המטרה על ידי יצירת מכונה חדשה.
בשני המקרים, אפשר למחוק את המכונה הישנה אחרי שהפעולה מסתיימת. אנחנו ממליצים לשכפל את המכונה כי זה לא משפיע על הביצועים, ולא צריך להגדיר מחדש את המכונה (למשל דגלים, סוג מכונה, נפח אחסון וזיכרון). |
| שגיאה במחיקת מופע. | אם ההגנה מפני מחיקה מופעלת במכונה, צריך לאשר את התוכניות למחיקת המכונה. ואז להשבית את ההגנה מפני מחיקה לפני שמוחקים את המכונה. |
הודעת שגיאה: 429 Too Many Requests (rateLimitExceeded). |
יכול להיות שתקבלו את השגיאה 429 Too Many Requests ב-HTTP עם הסיבה rateLimitExceeded כשאפליקציה או חשבון שירות חורגים מהמכסה לקצב הגשת הבקשות לכל משתמש ב-Cloud SQL Admin API. מכסות לקצב הגשת בקשות נאכפות לדקה, למשתמש ולאזור, ולכן יכול להיות שמדדי המכסות המצטברים ברמת הפרויקט בדף Cloud Quotas במסוף Google Cloud לא יראו ניצול מלא של המכסה.
כדי לאבחן איזה משתמש או חשבון שירות ממצה את הגבלת קצב של יצירת בקשות לכל משתמש:
כדי לפתור את השגיאה, מטמיעים באפליקציה שמירת נתונים במטמון בצד הלקוח או השהיה מעריכית לפני ניסיון חוזר (exponential backoff), מפזרים את עומסי העבודה בין חשבונות שירות שונים או מבקשים לשנות את המכסה. מידע נוסף זמין במאמר פתרון בעיות שקשורות לשגיאות במגבלת הקצב. |
התחברות לשירות פרטי
| שגיאה | פתרון בעיות |
|---|---|
| החיבור לשירות של המכונה לא מקבל את נקודת הקצה של 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 אם הממשק של Private Service Connect לא נמצא ברשימת הממשקים שאושרו, מעדכנים את מחבר הרשת. מידע נוסף זמין במאמר ניהול של חיבורי רשת. |
רפליקציה
| שגיאה | פתרון בעיות |
|---|---|
| הרפליקה לקריאה בלבד לא התחילה לשכפל בזמן היצירה. | סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל. |
| אי אפשר ליצור עותק לקריאה בלבד – שגיאת invalidFlagValue. | אחד מהדגלים בבקשה לא תקין. זה יכול להיות דגל שציינתם במפורש או דגל שהוגדר לערך ברירת מחדל.
קודם כל, בודקים שהערך של הדגל אם הדגל |
| לא ניתן ליצור עותק לקריאה בלבד – שגיאה לא ידועה. | סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן.
בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
אם השגיאה היא |
| הדיסק מלא. | גודל הדיסק של המכונה הראשית יכול להתמלא במהלך יצירת הרפליקה. עורכים את המכונה הראשית כדי לשדרג אותה לגודל דיסק גדול יותר. |
| מופע הרפליקה משתמש ביותר מדי זיכרון. | הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמתבצעות לעיתים קרובות, מה שעלול לגרום לה להשתמש ביותר זיכרון מאשר המכונה הראשית.
מפעילים מחדש את מכונת הרפליקה כדי לפנות את שטח הזיכרון הזמני. |
| השכפול הופסק. | הגעתם למגבלת האחסון המקסימלית וההגדלה האוטומטית של נפח האחסון לא מופעלת.
עורכים את המכונה כדי להפעיל את |
| השהיית השכפול גבוהה באופן עקבי. | עומס הכתיבה גבוה מדי והרפליקה לא יכולה לטפל בו. השהיית שכפול מתרחשת כשה-SQL thread ברפליקה לא מצליח לעמוד בקצב של ה-IO thread. סוגים מסוימים של שאילתות או עומסי עבודה יכולים לגרום לעיכוב זמני או קבוע בשכפול של סכימה מסוימת. חלק מהסיבות הנפוצות לעיכוב ברפליקציה:
פתרונות אפשריים:
|
| יצירת הרפליקה נכשלת בגלל זמן קצוב לתפוגה. | טרנזקציות ארוכות שלא אושרו במכונה הראשית יכולות לגרום לכך שהיצירה של רפליקה לקריאה בלבד תיכשל.
יוצרים מחדש את הרפליקה אחרי שעוצרים את כל השאילתות שפועלות. |