בדקו אם השאלה או הבעיה שלכם כבר קיבלו מענה באחד מהדפים הבאים:
- שאלות נפוצות
- בעיות מוכרות
- הודעות שגיאה
- אבחון בעיות
- ניפוי באגים בבעיות בחיבור
- בעיות בעדכון נפח האחסון
הנושאים בדף הזה:
- גיבוי ושחזור
- ביטול הייבוא והייצוא
- שיבוט
- קישוריות
- יצירת מכונות
- הפעלת SQL באמצעות Data API
- דגלים
- זמינות גבוהה
- ייבוא וייצוא
- שילוב עם Vertex AI
- רישום ביומן
- ניהול מכונות
- Private Service Connect
- שכפול
גיבוי ושחזור
| שגיאה | פתרון בעיות |
|---|---|
| אי אפשר לראות את הסטטוס של הפעולה הנוכחית. | במסוף Google Cloud מדווח רק על הצלחה או כישלון בסיום הפעולה. הוא לא מיועד להצגת אזהרות או עדכונים אחרים.
מריצים את
הפקודה |
| אתם רוצים לגלות מי ביצע פעולת גיבוי על פי דרישה. | בממשק המשתמש לא מוצג המשתמש שהתחיל את הפעולה.
מחפשים ביומנים ומסננים לפי טקסט כדי למצוא את המשתמש. יכול להיות שתצטרכו להשתמש ביומני ביקורת כדי לראות מידע פרטי. קובצי היומן הרלוונטיים כוללים:
|
| אחרי שמוחקים מכונה, אי אפשר לגבות אותה. | אם מוחקים מכונה בלי לבצע גיבוי סופי של הנתונים, אי אפשר לבצע שחזור נתונים. עם זאת, אם משחזרים את המכונה, Cloud SQL משחזר גם את הגיבויים. מידע נוסף על שחזור מכונה שנמחקה זמין במאמר שמירת גיבויים אחרי מחיקת מכונה. אם ביצעתם פעולת ייצוא, צרו מכונה חדשה ואז בצעו פעולת ייבוא כדי ליצור מחדש את מסד הנתונים. הייצוא נכתב ב-Cloud Storage והייבוא נקרא משם. |
| גיבוי אוטומטי תקוע במשך שעות רבות ואי אפשר לבטל אותו. | הגיבויים יכולים להימשך זמן רב, בהתאם לגודל מסד הנתונים.
אם אתם ממש צריכים לבטל את הפעולה, אתם יכולים לבקש מ
תמיכת הלקוחות |
| פעולת שחזור יכולה להיכשל כשמשתמש אחד או יותר שמצוינים בקובץ ה-SQL המוכן לשימוש לא קיימים. | לפני שמשחזרים קובץ dump של SQL, כל המשתמשים במסד הנתונים שיש בבעלותם אובייקטים או שקיבלו הרשאות לאובייקטים במסד הנתונים שהושלך חייבים להיות קיימים במסד הנתונים של היעד. אם אין להם את ההרשאות האלה, פעולת השחזור לא תצליח ליצור מחדש את האובייקטים עם הבעלות או ההרשאות המקוריות.
יוצרים את המשתמשים במסד הנתונים לפני שמשחזרים את ה-SQL dump. |
| אתם רוצים להגדיל את מספר הימים שבהם אפשר לשמור גיבויים אוטומטיים מ-7 ל-30 ימים, או יותר. | אפשר
להגדיר את מספר הגיבויים האוטומטיים שרוצים לשמור, מ-1 עד 365. גיבויים אוטומטיים נמחקים באופן קבוע על סמך ערך השמירה שהוגדר. לצערנו, זה אומר שהגיבויים שמוצגים כרגע הם הגיבויים האוטומטיים היחידים שאפשר לשחזר מהם.
כדי לשמור גיבויים ללא הגבלת זמן, אתם יכולים ליצור גיבוי על פי דרישה, כי גיבויים כאלה לא נמחקים כמו גיבויים אוטומטיים. גיבויים לפי דרישה נשמרים ללא הגבלת זמן. כלומר, הם נשארים עד שמוחקים אותם או עד שמוחקים את המכונה שהם שייכים אליה. מכיוון שסוג הגיבוי הזה לא נמחק באופן אוטומטי, הוא יכול להשפיע על החיוב. |
| גיבוי אוטומטי נכשל ולא קיבלתם התראה באימייל. | כדי לקבל מ-Cloud SQL התראה על סטטוס הגיבוי, מגדירים התראה מבוססת-יומן. |
| גיבוי אוטומטי או גיבוי על פי דרישה נכשל במכונה עם יותר מ-50 תוויות שהוגדרו על ידי המשתמש. | כש-Cloud SQL מבצע גיבוי, הוא מעתיק את התוויות שהמשתמשים הגדירו למכונה לתמונת המצב של האחסון הבסיסי, ומוסיף תוויות מערכת פנימיות. אם המספר הכולל של התוויות חורג מהמגבלה של 64 תוויות לכל קובץ snapshot, הגיבוי נכשל.
כדי לפתור את הבעיה, צריך להסיר תוויות עודפות כך שיהיו במכונה עד 50 תוויות שהוגדרו על ידי המשתמש. מידע נוסף זמין במאמר הוספת תוויות למכונות. |
| מכונה נכשלת שוב ושוב כי היא עוברת בין מצבי הכישלון והשחזור מהגיבוי. ניסיונות להתחבר למסד הנתונים ולהשתמש בו אחרי השחזור נכשלים. |
דברים שכדאי לנסות:
|
| אתם מגלים שחסרים נתונים כשאתם מבצעים פעולת גיבוי או שחזור. | הטבלאות נוצרו כלא מתועדות. לדוגמה:
הטבלאות הבאות לא נכללות בשחזור מגיבוי:
כדי לשחזר טבלאות באמצעות גיבוי, צריך להימנע משימוש בטבלאות שלא נרשמו ביומן. אם אתם משחזרים ממסד נתונים שכבר יש בו טבלאות לא מתועדות, אז אתם יכולים להעביר את מסד הנתונים לקובץ dump, ולטעון מחדש את הנתונים אחרי ששיניתם את הקובץ שהועבר מ- |
| אי אפשר למחוק מכונה כשבוחרים ליצור גיבוי סופי בזמן מחיקת המכונה. |
כשמוחקים מכונה, צריך לאשר אם רוצים ליצור גיבוי סופי של המכונה לפני המחיקה. אם הפעלתם את הגיבוי הסופי באמצעות הגדרת המכונה final-backup, הבחירה שתבצעו כשתמחקו את המכונה צריכה להתאים להגדרת המכונה של הגיבוי הסופי שקבעתם כשהפעלתם את הגיבוי הסופי למכונה. כדי לפתור את הבעיה, נסו אחד מהפתרונות הבאים:
|
| לא הצלחנו ליצור מכונה של רפליקה אחרי שיצרנו בהצלחה מכונה ראשית עם הגדרת הגיבוי הסופי. |
אם יוצרים מכונה חדשה כשההגדרה של מכונת הגיבוי הסופי מופעלת, צריך לעדכן את מדיניות הארגון של הגיבוי הסופי כדי להחיל את הגדרות הגיבוי על המכונה הראשית בלבד.
אין תמיכה בגיבויים סופיים במכונות של רפליקות. מידע נוסף זמין במאמר מדיניות הארגון ב-Cloud SQL. |
ביטול הייבוא והייצוא
| שגיאה | פתרון בעיות |
|---|---|
הודעת שגיאה: You can't cancel operation [operation-ID] because
this operation isn't in progress. |
אתם מנסים לבטל פעולת ייבוא או ייצוא שהושלמה, נכשלה או בוטלה. אם הפעולה פועלת, אפשר לבטל אותה. |
הודעת שגיאה: You can't cancel operation [operation-ID] because
Cloud SQL doesn't support the cancellation of an [operation-type]
operation. |
ב-Cloud SQL אי אפשר לבטל את הפעולה כי סוג הפעולה הוא לא |
הודעת שגיאה: The [operation-type] operation isn't cancelled. Wait
and retry in a few seconds. |
Cloud SQL לא יכול לבטל את פעולת הייבוא או הייצוא כרגע. כדאי לנסות שוב בעוד כמה שניות. אם הבעיה נמשכת, אפשר לפנות Google Cloud לתמיכה. |
שכפל
| שגיאה | פתרון בעיות |
|---|---|
השכפול נכשל ומוצגת השגיאה 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 מוסבר איך לפתור את הבעיות האלה. |
Certificate verify failed. |
התוקף של אישורי הלקוח פג או שהנתיב לאישורים שגוי. ליצור מחדש את האישורים. |
| יצירת חיבור איטי או זמן קצוב לתפוגה של חיבור כשמשתמשים באימות מסד נתונים של IAM. | החיבור למכונה של Cloud SQL באמצעות אימות של מסד נתונים ב-IAM נמשך כמה שניות או שנגמר הזמן הקצוב לתפוגה, בזמן שהחיבור באמצעות אימות מובנה של מסד נתונים מתבצע כרגיל. הסיבה: המכונה משתמשת בסוג מכונה עם ליבה משותפת ( פתרון:
מידע נוסף זמין במאמר ביצועים במכונות עם ליבת מעבד משותפת. |
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 |
Hostname/IP does not match certificate's altnames:
Host: localhost. is not in the cert's altnames. |
כתובת המארח לא תואמת לכתובת בשמות החלופיים של אישור השרת. אם אתם משתמשים ב-Node.js עם verify-full או המקבילה שלו, השתמשו בשם ה-DNS לפרמטר servername.
אפשר למצוא את שם ה-DNS באישור השרת באמצעות openssl. לדוגמה,
|
יצירת מכונות
| שגיאה | פתרון בעיות |
|---|---|
הודעת שגיאה: 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 נאכף באופן ידני, צריך לבקש מהאדמין של הארגון להסיר את האילוץ, והבעיה תיפתר במכונות החדשות שייווצרו.
|
IAM authentication is not enabled for the instance
|
כדי לפתור את הבעיה, מגדירים את המכונה לאימות IAM. |
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 ל-PostgreSQL. כדי למנוע שגיאות במהלך פעולות ייצוא שכוללות שמות משתמשים, צריך להשתמש גם בדגל --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, בדומה למאמר הזה בנושא אוטומציה של גיבויים. |
דגלים
| שגיאה | פתרון בעיות |
|---|---|
| אתם מגדירים את אזור הזמן לסשן, אבל הוא פג כשאתם מתנתקים. |
מתחברים למסד הנתונים ומגדירים את אזור הזמן של מסד הנתונים לאזור הזמן הרצוי, לכל משתמש או לכל מסד נתונים. ב-Cloud SQL ל-PostgreSQL, אפשר לציין את הפרטים הבאים.
ההגדרות האלה נשמרות אחרי שסוגרים את הסשן, בדומה להגדרה של ALTER DATABASE dbname SET TIMEZONE TO 'timezone'; ALTER USER username SET TIMEZONE TO 'timezone'; ההגדרות האלה חלות רק על חיבורים חדשים למסד הנתונים. כדי לראות את השינוי באזור הזמן, מתנתקים מהמכונה ומתחברים אליה מחדש. |
זמינות גבוהה
| שגיאה | פתרון בעיות |
|---|---|
| אתם לא מוצאים את המדדים של מעבר ידני לגיבוי במקרה של כשל. | רק מעברים אוטומטיים לגיבוי נכללים במדדים. |
| המשאבים של מכונת Cloud SQL (מעבד ו-RAM) קרובים ל-100% שימוש, ולכן המכונה עם הזמינות הגבוהה מושבתת. | גודל המכונה של המכונה קטן מדי לעומס.
עורכים את המכונה כדי לשדרג למכונה גדולה יותר עם יותר מעבדי CPU וזיכרון. |
ייבוא
| שגיאה | פתרון בעיות |
|---|---|
הודעת שגיאה: permission denied for schema public |
בגרסאות 15 ואילך של PostgreSQL, אם מסד הנתונים של היעד נוצר מ-template0, יכול להיות שייבוא הנתונים ייכשל. כדי לפתור את הבעיה, צריך להריץ את פקודת ה-SQL GRANT ALL ON SCHEMA public TO cloudsqlsuperuser כדי לתת למשתמש cloudsqlsuperuser הרשאות לסכימה ציבורית. |
HTTP Error 409: Operation failed because another operation was already in progress. |
כבר יש פעולה בהמתנה למכונה. מותר לבצע פעולה אחת בלבד בכל פעם. כדאי לנסות לשלוח את הבקשה אחרי שהפעולה הנוכחית תסתיים. |
| פעולת הייבוא נמשכת יותר מדי זמן. | יותר מדי חיבורים פעילים יכולים להפריע לפעולות הייבוא.
סוגרים פעולות שלא בשימוש. בודקים את המעבד (CPU) ואת השימוש בזיכרון במכונת Cloud SQL, כדי לוודא שיש מספיק משאבים זמינים. הדרך הטובה ביותר לוודא שמשימת הייבוא מקבלת את מרב המשאבים היא להפעיל מחדש את המכונה לפני התחלת הפעולה. הפעלה מחדש:
|
| פעולת ייבוא יכולה להיכשל כשמשתמש אחד או יותר שמצוינים בקובץ ה-dump לא קיימים. | לפני שמייבאים קובץ dump, כל המשתמשים במסד הנתונים שיש בבעלותם אובייקטים או שקיבלו הרשאות לאובייקטים במסד הנתונים שהושלך חייבים להיות קיימים במסד הנתונים של היעד. אם אין להם את ההרשאות האלה, פעולת הייבוא לא תצליח ליצור מחדש את האובייקטים עם הבעלות או ההרשאות המקוריות.
יוצרים את משתמשי מסד הנתונים לפני הייבוא. |
| אחרי שמייבאים נתונים, השימוש בדיסק הנתונים גדל באופן משמעותי. | יכול להיות שיהיה שימוש לא צפוי בדיסק אחרי ייבוא הנתונים. יכול להיות שהשימוש הזה נובע משימוש בשחזור מערכת מנקודה מסוימת בזמן (PITR). כדי לפתור את הבעיה, אחרי שמייבאים נתונים, משביתים את האפשרות "שחזור מערכת מנקודה מסוימת בזמן (PITR)" אם רוצים למחוק יומנים ולפנות נפח אחסון. חשוב לזכור שהקטנת נפח האחסון שבשימוש לא מקטינה את נפח האחסון שהוקצה למכונה. |
הודעת שגיאה: GRANT stderr: ERROR: must be member of role ROLE_NAME |
הודעת השגיאה הזו מופיעה אם מנסים לייבא קובץ SQL מוכן לשימוש שהועלה ב-Cloud Storage למסד נתונים של Cloud SQL, ומשימת הייבוא פועלת במשך כארבעה ימים. ROLE_NAME הוא תפקיד מותאם אישית במסד הנתונים, שמוגדר במסד הנתונים של PostgreSQL במקור. משתמש ברירת המחדל כדי לפתור את הבעיה, מבצעים את השלבים הבאים:
|
שילוב עם Vertex AI
| שגיאה | פתרון בעיות |
|---|---|
הודעת שגיאה: Google ML integration API is supported only on Postgres version 12 or above. |
כדי להפעיל את השילוב של Vertex AI ב-Cloud SQL, צריך מסד נתונים של Cloud SQL ל-PostgreSQL בגרסה 12 ואילך. כדי לשדרג את מסד הנתונים לגרסה הזו, קראו את המאמר שדרוג הגרסה הראשית של מסד הנתונים במקום. |
הודעת שגיאה: 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/postgres/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 בקשות לדקה לכל אזור, לכל מודל ולכל פרויקט. |
רישום ביומן
| שגיאה | פתרון בעיות |
|---|---|
| רישום ביומן צורך הרבה מעבד (CPU) וזיכרון במכונת Cloud SQL. | צריך לכוונן את הרישום ביומן.
אפשר להגדיר את הדגל |
| לא נמצאו יומני ביקורת. | יומני Data Access נכתבים רק אם הפעולה היא קריאה מאומתת ל-API שמונעת על ידי משתמש, שיוצרת, משנה או קוראת נתונים שנוצרו על ידי משתמשים, או אם הפעולה ניגשת לקובצי תצורה או למטא-נתונים של משאבים. |
| מידע על הפעולות לא נמצא ביומנים. | אתם רוצים לקבל מידע נוסף על פעולה מסוימת.
לדוגמה, משתמש נמחק אבל אתם לא מצליחים לגלות מי מחק אותו. ביומנים מוצג שהפעולה התחילה, אבל אין מידע נוסף. כדי שפרטים מזהים אישיים (PII) ופרטים נוספים יתועדו, צריך להפעיל את יומני הביקורת. |
| קשה לקרוא קובצי יומן. | אתם מעדיפים להציג את היומנים כקובץ 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. שטח שלא משמש את טבלאות מסד הנתונים משמש בדרך כלל ליומני עסקאות, לקבצים זמניים או ליומנים אחרים.
אפשר לראות פירוט של השימוש בדיסק של המכונה לפי סוג הנתונים באמצעות המדד דברים שכדאי לנסות:
|
| אתם רוצים לברר אילו שאילתות פועלות עכשיו. | מתחברים למסד הנתונים ומריצים את השאילתה הבאה:
|
| אתם רוצים לברר באילו יחידות משתמשים בשדה ספציפי. | מתחברים למסד הנתונים ומריצים את השאילתה הבאה (עם 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 שניות, אפשר להימנע מרוב הכיבויים הלא תקינים, כולל חיבורים משורת הפקודה של מסד הנתונים. אם משאירים את החיבורים האלה פתוחים במשך שעות או ימים, יכול להיות שהכיבוי לא יהיה תקין. |
| אי אפשר למחוק משתמש. | כנראה שיש למשתמש אובייקטים במסד הנתונים שתלויים בו. צריך להסיר את האובייקטים האלה או להקצות אותם מחדש למשתמש אחר.
צריך לבדוק אילו אובייקטים תלויים במשתמש, ואז להסיר את האובייקטים האלה או להקצות אותם מחדש למשתמש אחר. בשרשור הזה ב-Stack Exchange מוסבר איך למצוא את האובייקטים שבבעלות המשתמש. |
| שאילתות מסוימות פועלות לאט. | יש הרבה סיבות לכך ששאילתות יכולות להיות איטיות, בעיקר בגלל היבטים ספציפיים של מסד הנתונים. אחת מהסיבות שקשורות ל-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 כדי למצוא את השגיאה בפועל.
אם השגיאה היא |
| הדיסק מלא. | גודל הדיסק של המכונה הראשית יכול להתמלא במהלך יצירת הרפליקה. עורכים את המכונה הראשית כדי לשדרג אותה לגודל דיסק גדול יותר. |
| המקום בכונן גדל באופן משמעותי. | אם יש משבצת שלא משמשת באופן פעיל למעקב אחרי נתונים, PostgreSQL שומר את מקטעי ה-WAL ללא הגבלת זמן, וכך המקום בכונן גדל ללא הגבלת זמן. אם אתם משתמשים בתכונות שכפול לוגי ופענוח ב-Cloud SQL, משבצות השכפול נוצרות ומוסרות באופן אוטומטי. כדי לזהות משבצות רפליקציה שלא בשימוש, אפשר לשלוח שאילתה לתצוגת המערכת pg_replication_slots ולסנן לפי העמודה active. אפשר להסיר משבצות שלא בשימוש כדי להסיר מקטעי WAL באמצעות הפקודה pg_drop_replication_slot.
|
| מופע הרפליקה משתמש ביותר מדי זיכרון. | הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמתבצעות לעיתים קרובות, מה שעלול לגרום לה להשתמש ביותר זיכרון מאשר המכונה הראשית.
מפעילים מחדש את מכונת הרפליקה כדי לפנות את שטח הזיכרון הזמני. |
| השכפול הופסק. | הגעתם למגבלת האחסון המקסימלית וההגדלה האוטומטית של נפח האחסון לא מופעלת.
עורכים את המכונה כדי להפעיל את |
| השהיית השכפול גבוהה באופן עקבי. | עומס הכתיבה גבוה מדי והרפליקה לא יכולה לטפל בו. השהיית שכפול מתרחשת כשה-SQL thread ברפליקה לא מצליח לעמוד בקצב של ה-IO thread. סוגים מסוימים של שאילתות או עומסי עבודה יכולים לגרום לעיכוב זמני או קבוע בשכפול של סכימה מסוימת. חלק מהסיבות הנפוצות לעיכוב ברפליקציה:
פתרונות אפשריים:
|
| שגיאות במהלך בנייה מחדש של אינדקסים ב-PostgreSQL 9.6. | קיבלתם הודעת שגיאה מ-PostgreSQL שבה כתוב שצריך לבנות מחדש אינדקס מסוים. אפשר לעשות את זה רק במכונה הראשית. אם תיצרו מכונת רפליקה חדשה, תקבלו שוב את אותה הודעת שגיאה.
בגרסאות PostgreSQL שמתחת ל-10, אינדקסים של גיבוב (hash) לא מופצים לרפליקות.
אם אתם חייבים להשתמש באינדקסי גיבוב, שדרגו ל-PostgreSQL 10 ואילך. אחרת, אם אתם רוצים להשתמש גם ברפליקות, אל תשתמשו באינדקסי גיבוב ב-PostgreSQL 9.6. |
| השאילתה במכונה הראשית תמיד פועלת. | אחרי שיוצרים רפליקה, השאילתה SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' אמורה לפעול באופן רציף במכונה הראשית.
|
| יצירת הרפליקה נכשלת בגלל זמן קצוב לתפוגה. | טרנזקציות ארוכות שלא אושרו במכונה הראשית יכולות לגרום לכך שהיצירה של רפליקה לקריאה בלבד תיכשל.
יוצרים מחדש את הרפליקה אחרי שעוצרים את כל השאילתות שפועלות. |
| אם למכונה הראשית ולרפליקה יש גדלים שונים של vCPU, יכולות להיות בעיות בביצועי השאילתות כי הכלי לאופטימיזציה של שאילתות מביא בחשבון את הגדלים של ה-vCPU. |
כדי לפתור את הבעיה, מבצעים את השלבים הבאים:
אם מדובר בשאילתה ספציפית, צריך לשנות אותה. לדוגמה, אתם יכולים לשנות את סדר הצירופים כדי לבדוק אם הביצועים משתפרים. |