כדאי לבדוק אם השאלה או הבעיה שלך כבר קיבלו מענה באחד מהדפים הבאים:
הנושאים בדף הזה:
- גיבוי ושחזור
- ביטול ייבוא וייצוא
- שיבוט
- קישוריות
- יצירת מופעים
- Flags
- זמינות גבוהה
- ייבוא וייצוא
- שילוב עם Vertex AI
- Logging
- ניהול מופעים
- Private Service Connect
- שכפול
גיבוי ושחזור
| שגיאה | פתרון בעיות |
|---|---|
| אי אפשר לראות את הסטטוס של הפעולה הנוכחית. | במסוף Google Cloud מוצג רק אם הפעולה הצליחה או נכשלה. הוא לא מיועד להצגת אזהרות או עדכונים אחרים.
מריצים את
הפקודה |
| אתם רוצים לדעת מי ביצע פעולת גיבוי לפי דרישה. | בממשק המשתמש לא מוצג המשתמש שהתחיל את הפעולה.
בודקים ברישומים ומסננים לפי טקסט כדי למצוא את המשתמש. יכול להיות שתצטרכו להשתמש ביומני ביקורת כדי לגשת למידע פרטי. קובצי יומן רלוונטיים:
|
| אחרי שמוחקים מופע, אי אפשר לגבות אותו. | אם מוחקים מופע בלי ליצור גיבוי סופי של הנתונים, לא ניתן לשחזר את הנתונים. עם זאת, אם משחזרים את המכונה, Cloud SQL משחזר גם את הגיבויים. מידע נוסף על שחזור מופע שנמחק זמין במאמר שמירת גיבויים אחרי מחיקת מופע. אם ביצעתם פעולת ייצוא, צריך ליצור מופע חדש ואז לבצע פעולת ייבוא כדי ליצור מחדש את מסד הנתונים. הייצוא נכתב אל Cloud Storage והייבוא נקרא משם. |
| גיבוי אוטומטי נתקע למשך שעות רבות ואי אפשר לבטל אותו. | גיבויים יכולים להימשך זמן רב, בהתאם לגודל מסד הנתונים.
אם אתם ממש צריכים לבטל את הפעולה, אתם יכולים לבקש מ
תמיכת הלקוחות |
| פעולת שחזור יכולה להיכשל אם משתמש אחד או יותר שמצוינים בקובץ SQL מוכן לשימוש לא קיימים. | לפני שמשחזרים קובץ SQL dump, כל המשתמשים במסד הנתונים שיש בבעלותם אובייקטים או שקיבלו הרשאות לאובייקטים במסד הנתונים שהושלך חייבים להיות קיימים במסד הנתונים של היעד. אם לא, פעולת השחזור תיכשל ולא תיצור מחדש את האובייקטים עם הבעלות או ההרשאות המקוריות.
יוצרים את משתמשי מסד הנתונים לפני שמשחזרים את קובץ ה-SQL. |
| אתם רוצים להגדיל את מספר הימים שבהם אפשר לשמור גיבויים אוטומטיים מ-7 ל-30 ימים, או יותר. | אפשר
להגדיר את מספר הגיבויים האוטומטיים שיישארו, בין 1 ל-365. גיבויים אוטומטיים נמחקים באופן קבוע על סמך ערך השמירה שהוגדר. לכן, הגיבויים שמוצגים כרגע הם הגיבויים האוטומטיים היחידים שאפשר לשחזר מהם.
כדי לשמור גיבויים ללא הגבלת זמן, אפשר ליצור גיבוי לפי דרישה, כי הם לא נמחקים כמו גיבויים אוטומטיים. גיבויים על פי דרישה נשמרים ללא הגבלת זמן. כלומר, הן נשארות עד שהן נמחקות או עד שהמופע שאליו הן שייכות נמחק. הגיבוי הזה לא נמחק אוטומטית, ולכן הוא יכול להשפיע על החיוב. |
| גיבוי אוטומטי נכשל ולא קיבלתם התראה באימייל. | כדי לקבל מ-Cloud SQL התראה על סטטוס הגיבוי, מגדירים התראה שמבוססת על יומן. |
| מופע נכשל שוב ושוב כי הוא עובר בין מצבי הכשל לבין מצבי שחזור הגיבוי. ניסיונות להתחבר למסד הנתונים ולהשתמש בו אחרי השחזור נכשלים. |
פעולות שכדאי לנסות:
|
| גיליתם שחסרים נתונים כשביצעתם פעולת גיבוי או שחזור. | הטבלאות נוצרו כטבלאות לא מתועדות. לדוגמה:
הטבלאות האלה לא נכללות בשחזור מגיבוי:
הפתרון הוא להימנע משימוש בטבלאות שלא נרשמו ביומן אם רוצים לשחזר את הטבלאות האלה באמצעות גיבוי. אם אתם משחזרים ממסד נתונים שכבר יש בו טבלאות לא מתועדות, אתם יכולים להעביר את מסד הנתונים לקובץ ולהטעין מחדש את הנתונים אחרי שתשנו את הקובץ שהועבר מ- |
| אי אפשר למחוק מופע כשבוחרים לבצע גיבוי סופי בזמן מחיקת המופע. |
כשמוחקים מופע, צריך לאשר אם רוצים ליצור גיבוי סופי של המופע לפני המחיקה. אם הפעלתם גיבוי סופי באמצעות הגדרת המופע 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 ציבוריות בקטע 'קישוריות' במסוף Google Cloud , ואין אפשרות לשכפול בגלל שיקולי אבטחה.
אם אפשר, מסירים את כל הערכים של |
הודעת שגיאה: Failed to create subnetwork. Couldn't find free
blocks in allocated IP ranges. Please allocate new ranges for this service
provider. Help Token: [help-token-id]. |
ניסיתם להשתמש במסוף כדי לשכפל מכונה עם כתובת IP פרטית, אבל לא ציינתם את טווח כתובות ה-IP שהוקצה שבו אתם רוצים להשתמש, והמכונה המקורית לא נוצרה עם הטווח שצוין. Google Cloud כתוצאה מכך, המכונה המשוכפלת נוצרת בטווח אקראי. משתמשים ב- |
חיבור
| שגיאה | פתרון בעיות |
|---|---|
Aborted connection. |
הבעיה יכולה להיות:
האפליקציות צריכות להיות עמידות בפני כשלים ברשת ולפעול לפי השיטות המומלצות, כמו איגום חיבורים וניסיון חוזר. רוב כלי הניהול של מאגרי החיבורים מזהים את השגיאות האלה, אם אפשר. אחרת, האפליקציה צריכה לנסות שוב או להיכשל בצורה מסודרת. כדי לנסות שוב להתחבר, מומלץ להשתמש באחת מהשיטות הבאות:
שילוב של השיטות האלה עוזר לצמצם את ההגבלה. |
הודעת שגיאה: Login failed for user "" |
יכול להיות שתיתקלו בשגיאת ההתחברות הזו במהלך אימות ב-Microsoft Entra ID. כדי לפתור את הבעיה, צריך לוודא שיש פרטי כניסה ל-SQL Server עבור המשתמש הזה ב-Microsoft Entra ID. |
| בעיות בקישוריות לרשת עם מופעים של כתובות IP פרטיות | יכול להיות שתיתקלו באחת מהבעיות הבאות במהלך ההגדרה של השילוב:
מידע נוסף על פתרון הבעיות האלה זמין במאמר בנושא פתרון בעיות בשילוב עם Microsoft Entra ID. |
Certificate verify failed. |
תוקף האישורים של הלקוח פג או שהנתיב לאישור לא נכון. יוצרים מחדש את האישורים כדי ליצור אותם מחדש. |
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 Peering באמצעות הפקודה הבאה: gcloud services vpc-peerings update \ --service=servicenetworking.googleapis.com \ --ranges=RESERVED_RANGE_NAME \ --network=VPC_NETWORK \ --project=PROJECT_ID |
הודעת שגיאה: Failed to create subnetwork. Router status is
temporarily unavailable. Please try again later. Help Token:
[token-ID]. |
נסו ליצור שוב את המכונה של Cloud SQL. |
הודעת שגיאה: HTTPError 400: Invalid request: Incorrect Service Networking config for instance: PROJECT_ID:INSTANCE_NAME:SERVICE_NETWORKING_NOT_ENABLED. |
מפעילים את Service Networking API באמצעות הפקודה הבאה ומנסים שוב ליצור את מכונת Cloud SQL. gcloud services enable servicenetworking.googleapis.com \ --project=PROJECT_ID |
הודעת שגיאה: Failed to create subnetwork. Required
'compute.projects.get' permission for PROJECT_ID. |
כשיוצרים מופע באמצעות כתובת IP פרטית, נוצר חשבון שירות בדיוק בזמן באמצעות Service Networking API. אם הפעלתם את Service Networking API רק לאחרונה, יכול להיות שחשבון השירות לא ייווצר והיצירה של המופע תיכשל. במקרה כזה, צריך לחכות שחשבון השירות יתעדכן בכל המערכת או להוסיף אותו ידנית עם ההרשאות הנדרשות. |
הודעת שגיאה: More than 3 subject alternative names are not
allowed. |
אתם מנסים להשתמש ב-SAN בהתאמה אישית כדי להוסיף יותר משלושה שמות DNS לאישור השרת של מופע Cloud SQL. אי אפשר להוסיף למופע יותר משלושה שמות DNS. |
הודעת שגיאה: Subject alternative names %s is too long. The
maximum length is 253 characters. |
מוודאים ששמות ה-DNS שרוצים להוסיף לאישור השרת של מופע Cloud SQL לא מכילים יותר מ-253 תווים. |
הודעת שגיאה: Subject alternative name %s is invalid. |
מוודאים ששמות ה-DNS שרוצים להוסיף לאישור השרת של מופע Cloud SQL עומדים בקריטריונים הבאים:
|
ייצוא
| שגיאה | פתרון בעיות |
|---|---|
HTTP Error 409: Operation failed because another operation was
already in progress. |
כבר קיימת פעולה שממתינה לאישור לגבי המכונה. אפשר לבצע רק פעולה אחת בכל פעם. כדאי לנסות לשלוח את הבקשה אחרי שהפעולה הנוכחית תסתיים. |
HTTP Error 403: The service account does not have the required
permissions for the bucket. |
מוודאים שהקטגוריה קיימת ושלחשבון השירות של מכונת Cloud SQL (שמבצעת את הייצוא) הוקצה התפקיד Storage Object Creator (roles/storage.objectCreator) כדי לאפשר ייצוא לקטגוריה. מידע נוסף זמין במאמר תפקידי IAM ל-Cloud Storage. |
| ייצוא ה-CSV פעל אבל ייצוא ה-SQL נכשל. | הייצוא בפורמטים CSV ו-SQL מתבצע באופן שונה. בפורמט SQL מיוצא כל מסד הנתונים, והייצוא כנראה יימשך יותר זמן. בפורמט CSV אפשר להגדיר אילו רכיבים במסד הנתונים ייכללו בייצוא.
שימוש בייצוא של קובצי CSV כדי לייצא רק את מה שצריך. |
| הייצוא נמשך יותר מדי זמן. | Cloud SQL לא תומך בפעולות סינכרוניות בו-זמניות.
שימוש ב העברת עומס של ייצוא. באופן כללי, בייצוא להפחתת עומס, במקום להפעיל ייצוא במכונת המקור, Cloud SQL מפעיל מכונה להפחתת עומס כדי לבצע את הייצוא. לייצוא offloading יש כמה יתרונות, כולל שיפור הביצועים במופע המקור וביטול החסימה של פעולות אדמיניסטרטיביות בזמן שהייצוא פועל. אם משתמשים בהעברת עומס לייצוא, זמן האחזור הכולל עשוי להתארך בפרק הזמן שנדרש להפעלת מופע העברת העומס. בדרך כלל, בייצוא בגודל סביר, זמן האחזור לא משמעותי. עם זאת, אם הייצוא קטן מספיק, יכול להיות שתבחינו בעלייה בחביון. |
| שגיאה ביצירת התוסף. | קובץ ה-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 אין אפשרות לייצא באופן אוטומטי.
אפשר לבנות מערכת ייצוא אוטומטית משלכם באמצעות מוצרים כמו Cloud Scheduler, Pub/Sub ופונקציות Cloud Run, בדומה למאמר הזה בנושא גיבויים אוטומטיים. Google Cloud |
דגלים
| שגיאה | פתרון בעיות |
|---|---|
| אתם מגדירים את אזור הזמן לסשן, אבל הוא יפוג כשתתנתקו מהחשבון. |
מתחברים למסד הנתונים ומגדירים את אזור הזמן של מסד הנתונים לאזור הזמן הרצוי, לפי משתמש או לפי מסד נתונים. ב-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 |
ב-PostgreSQL בגרסה 15 ואילך, אם מסד הנתונים של היעד נוצר מ-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. למידע נוסף על הוספת ההרשאות האלה לחשבון השירות, אפשר לעיין במאמר איך מעניקים לחשבון השירות של 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 בקשות לדקה לכל אזור לכל מודל לכל פרויקט. |
רישום ביומן
| שגיאה | פתרון בעיות |
|---|---|
| הרישום ביומן צורך הרבה מעבד (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.
|
ניהול מופעים
| שגיאה | פתרון בעיות |
|---|---|
| אתם רוצים לדעת אילו שאילתות מופעלות עכשיו. | מתחברים למסד הנתונים ומריצים את השאילתה הבאה:
|
| אתם רוצים לדעת באילו יחידות נעשה שימוש בשדה מסוים. | מתחברים למסד הנתונים ומריצים את השאילתה הבאה
(באמצעות 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 שניות, אפשר להימנע מרוב השבתות לא נקיות, כולל חיבורים משורת הפקודה של מסד הנתונים. אם משאירים את החיבורים האלה פתוחים במשך שעות או ימים, יכול להיות שהכיבוי לא יהיה תקין. |
| אי אפשר למחוק משתמש. | כנראה שיש למשתמש אובייקטים במסד הנתונים שתלויים בו. תצטרכו להסיר את האובייקטים האלה או להקצות אותם מחדש למשתמש אחר.
בודקים אילו אובייקטים תלויים במשתמש, ואז משחררים אותם או מקצים אותם מחדש למשתמש אחר. בשרשור הזה ב-Stack Exchange מוסבר איך למצוא את האובייקטים שבבעלות המשתמש. |
| שאילתות מסוימות פועלות לאט. | יש הרבה סיבות לכך ששאילתות פועלות לאט, בעיקר בגלל היבטים ספציפיים של מסד הנתונים. סיבה אחת שיכולה להיות קשורה ל-Cloud SQL היא חביון ברשת, כשהמשאב של המקור (הכתיבה או הקריאה) והמשאב של היעד (Cloud SQL) נמצאים באזורים שונים.
כדאי לעיין במיוחד ב טיפים כלליים לשיפור הביצועים. אם פעולות ההוספה, העדכון או המחיקה במסד הנתונים מתבצעות לאט, כדאי לבצע את הפעולות הבאות:
כדי להקטין את זמן האחזור, מומלץ למקם את משאבי המקור והיעד באותו אזור. |
| מוצגת הודעה על חוסר זיכרון, אבל בתרשימי המעקב לא רואים את זה. | יכול להיות שמופע ייכשל וידווח על Out of memory, אבל בטבלאות במסוף או ב-Cloud Monitoring ייראה כאילו עדיין יש זיכרון פנוי. Google Cloud
יש גורמים נוספים מלבד עומס העבודה שיכולים להשפיע על השימוש בזיכרון, כמו מספר החיבורים הפעילים ותהליכי התקורה הפנימיים. הם לא תמיד משתקפים בתרשימי המעקב. מוודאים שיש מספיק תקורה למופע כדי להתחשב בעומס העבודה, בתוספת תקורה נוספת. |
| שחזור של מופע שנמחק. | כל הנתונים במופע, כולל גיבויים, אובדים לתמיד כשמוחקים את המופע.
כדי לשמור את הנתונים, צריך לייצא אותם ל-Cloud Storage לפני שמוחקים את המופע. התפקיד Cloud SQL Admin כולל את ההרשאה למחיקת המכונה. כדי למנוע מחיקה בטעות, צריך להקצות את התפקיד הזה רק כשנדרש. |
| רוצים לשנות את השם של מופע קיים ב-Cloud SQL. | שינוי שם של מופע קיים אינו נתמך.
יש דרכים אחרות להשיג את המטרה על ידי יצירת מופע חדש.
בשני המקרים, אפשר למחוק את המופע הישן אחרי שהפעולה מסתיימת. מומלץ לבחור באפשרות של שיבוט, כי היא לא משפיעה על הביצועים ולא מחייבת אתכם לבצע מחדש הגדרות של מופעים, כמו סימון, סוג מכונה, גודל אחסון וזיכרון. |
| שגיאה במחיקת מופע. | אם ההגנה מפני מחיקה מופעלת עבור מופע, צריך לאשר את התוכניות למחיקת המופע. לאחר מכן, משביתים את ההגנה מפני מחיקה לפני שמוחקים את המופע. |
התחברות לשירות פרטי
| שגיאה | פתרון בעיות |
|---|---|
| הקובץ המצורף עם השירות של המופע לא מקבל את נקודת הקצה של Private Service Connect. |
|
ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource: The resource 'projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME' was not found |
הודעת השגיאה הזו יכולה להופיע כשמזמינים כתובת IP פנימית סטטית לנקודת הקצה של Private Service Connect. מוודאים שרשת המשנה שצוינה קיימת בפרויקט שצוין ב-URI. אם רוצים ליצור נקודת קצה בפרויקט שירות אבל להשתמש ברשת משנה מרשת VPC משותפת, צריך לציין את רשת המשנה באמצעות ה-URI שלה ולהשתמש במזהה הפרויקט של פרויקט המארח ב-URI. מידע נוסף זמין במאמר יצירת נקודת הקצה באופן ידני. |
ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource:
- The resource 'projects/PROJECT_ID/global/networks/NETWORK_NAME' was not found |
הודעת השגיאה הזו יכולה להופיע כשיוצרים נקודת קצה (endpoint) של Private Service Connect באופן ידני. מוודאים שהרשת שצוינה קיימת בפרויקט שצוין ב-URI. אם רוצים ליצור נקודת קצה בפרויקט שירות אבל להשתמש ברשת VPC משותפת, צריך לציין את הרשת באמצעות ה-URI שלה ולהשתמש במזהה הפרויקט של פרויקט המארח ב-URI. מידע נוסף זמין במאמר יצירת נקודת הקצה באופן ידני. |
Invalid consumer network status for PSC auto connection. |
הרשת הצרכנית לא מוגדרת בצורה נכונה, או שהיא לא מוגדרת בכלל, ולכן אין נקודת קצה שאפשר להתחבר אליה. כדי להתחבר לנקודת הקצה, צריך לבדוק את הסטטוס שלה ולתקן את השגיאה לפני שמנסים להתחבר שוב.
|
No permission to create a service connection policy. |
אין לכם את ההרשאות הדרושות כדי ליצור מדיניות לחיבור שירותים. כדי ליצור מדיניות של חיבור שירות, צריך את התפקיד |
| לא ניתן לקובץ המצורף עם הרשת לקבל חיבורים מהממשק של Private Service Connect כשמשתמשים בקישוריות יוצאת של Private Service Connect. | אם הרשת החיצונית לא יכולה לקבל חיבורים מממשק Private Service Connect, יכול להיות שמדיניות החיבורים בקובץ המצורף של הרשת לא מוגדרת בצורה נכונה. כדי לאמת את החיבורים שאושרו, מריצים את הפקודה הבאה בקובץ המצורף לרשת: gcloud compute network-attachments describe default --region=REGION_ID |
שכפול
| שגיאה | פתרון בעיות |
|---|---|
| השכפול של העותק לקריאה לא התחיל בזמן היצירה. | סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל. |
| אי אפשר ליצור העתק לקריאה – השגיאה invalidFlagValue. | אחד מהדגלים בבקשה לא תקין. יכול להיות שזה דגל שציינתם באופן מפורש או דגל שהוגדר לו ערך ברירת מחדל.
קודם כול, בודקים שהערך של הדגל אם הדגל |
| לא ניתן ליצור רפליקה לקריאה – שגיאה לא ידועה. | סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן.
בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
אם השגיאה היא: |
| הדיסק מלא. | יכול להיות שהגודל של הדיסק של המופע הראשי יתמלא במהלך יצירת רפליקה. עורכים את המופע הראשי כדי לשדרג אותו לגודל דיסק גדול יותר. |
| נפח האחסון בדיסק גדל באופן משמעותי. | משבצת שלא נמצאת בשימוש פעיל למעקב אחרי נתונים גורמת ל-PostgreSQL לשמור על קטעי WAL ללא הגבלת זמן, וכך נפח הדיסק גדל ללא הגבלה. אם משתמשים בתכונות logical replication and decoding ב-Cloud SQL, משבצות השכפול נוצרות ומוסרות באופן אוטומטי. אפשר לזהות משבצות שכפול שלא נעשה בהן שימוש על ידי שליחת שאילתה לתצוגת המערכת pg_replication_slots וסינון לפי העמודה active. אפשר להשתמש בפקודה pg_drop_replication_slot כדי להסיר פלחים של WAL על ידי השמטה של משבצות לא בשימוש.
|
| מופע הרפליקה משתמש ביותר מדי זיכרון. | הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמבוקשות לעיתים קרובות, מה שעלול לגרום לה להשתמש ביותר זיכרון מהמופע הראשי.
מפעילים מחדש את מופע הרפליקה כדי לפנות את המקום הזמני בזיכרון. |
| השכפול הופסק. | הגעתם למגבלת האחסון המקסימלית ולא הפעלתם את האפשרות להגדלת נפח האחסון באופן אוטומטי.
עורכים את המופע כדי להפעיל את |
| ההשהיה בשכפול גבוהה באופן עקבי. | עומס הכתיבה גבוה מדי בשביל הרפליקה. השהיית שכפול
מתרחשת כשהשרשור של SQL ברפליקה לא מצליח לעמוד בקצב של השרשור של IO. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום לעיכובים זמניים או קבועים בשכפול של סכימה נתונה. חלק מהסיבות הנפוצות להשהיה בשכפול:
הנה כמה פתרונות אפשריים:
|
| שגיאות במהלך בנייה מחדש של אינדקסים ב-PostgreSQL 9.6. | קיבלתם שגיאה מ-PostgreSQL שמציינת שצריך לבנות מחדש אינדקס מסוים. אפשר לעשות את זה רק במופע הראשי. אם תיצרו מכונת רפליקה חדשה, תקבלו שוב את אותה שגיאה תוך זמן קצר.
אינדקסים של Hash
לא מועברים לרפליקות בגרסאות PostgreSQL מתחת ל-10.
אם אתם חייבים להשתמש באינדקסים של hash, אתם צריכים לשדרג ל-PostgreSQL 10 ומעלה. אחרת, אם אתם רוצים להשתמש גם בעותקים משוכפלים, אל תשתמשו באינדקסים של hash ב-PostgreSQL 9.6. |
| השאילתה במופע הראשי תמיד פועלת. | אחרי שיוצרים רפליקה, השאילתה SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' אמורה לפעול באופן רציף במופע הראשי.
|
| יצירת רפליקה נכשלה בגלל זמן קצוב לתפוגה. | עסקאות ארוכות טווח שלא בוצעו במופע הראשי עלולות לגרום לכך שיצירת רפליקת קריאה תיכשל.
אחרי שמפסיקים את כל השאילתות הפעילות, יוצרים מחדש את העותק. |
| אם למופע הראשי ולרפליקה יש גדלים שונים של vCPU, יכול להיות שיהיו בעיות בביצועי השאילתות, כי האופטימיזציה של השאילתות מתבצעת בהתאם לגדלים של vCPU. |
כדי לפתור את הבעיה, מבצעים את השלבים הבאים:
אם מדובר בשאילתה ספציפית, צריך לשנות את השאילתה. לדוגמה, אפשר לשנות את הסדר של הפעולות לצירוף כדי לראות אם הביצועים משתפרים. |