בדף הזה יש טיפים לפתרון בעיות ב-Cloud SQL עבור מנועי מסדי נתונים נתמכים. חלק מהטיפים האלה רלוונטיים רק למנועי מסדי נתונים ספציפיים, ואחרים רלוונטיים לכולם.
טיפים לפתרון בעיות במנועי מסדי נתונים ספציפיים מופיעים בדפים שלהם:
כדאי לבדוק אם השאלה או הבעיה שלך כבר קיבלו מענה באחד מהדפים הבאים:
הנושאים בדף הזה:
- גיבוי ושחזור
- שיבוט
- קישוריות
- יצירת מופעים
- חיצוני ראשי
- רפליקה חיצונית
- Flags
- זמינות גבוהה
- ייבוא וייצוא
- שילוב עם Vertex AI
- שרתים מקושרים
- Logging
- ניהול מופעים
- Private Service Connect
- שכפול
גיבוי ושחזור
| שגיאה | פתרון בעיות |
|---|---|
| אי אפשר לראות את הסטטוס של הפעולה הנוכחית. | במסוף Google Cloud מוצג רק אם הפעולה הצליחה או נכשלה. הוא לא מיועד להצגת אזהרות או עדכונים אחרים.
מריצים את
הפקודה |
| אתם רוצים לדעת מי ביצע פעולת גיבוי לפי דרישה. | בממשק המשתמש לא מוצג המשתמש שהתחיל את הפעולה.
בודקים ברישומים ומסננים לפי טקסט כדי למצוא את המשתמש. יכול להיות שתצטרכו להשתמש ביומני ביקורת כדי לגשת למידע פרטי. קובצי יומן רלוונטיים:
|
| אחרי שמוחקים מופע, אי אפשר לגבות אותו. | אם מוחקים מופע בלי ליצור גיבוי סופי של הנתונים, לא ניתן לשחזר את הנתונים. עם זאת, אם משחזרים את המכונה, Cloud SQL משחזר גם את הגיבויים. מידע נוסף על שחזור מופע שנמחק זמין במאמר שמירת גיבויים אחרי מחיקת מופע. אם ביצעתם פעולת ייצוא, צריך ליצור מופע חדש ואז לבצע פעולת ייבוא כדי ליצור מחדש את מסד הנתונים. הייצוא נכתב אל Cloud Storage והייבוא נקרא משם. |
| גיבוי אוטומטי נתקע למשך שעות רבות ואי אפשר לבטל אותו. | גיבויים יכולים להימשך זמן רב, בהתאם לגודל מסד הנתונים.
אם אתם ממש צריכים לבטל את הפעולה, אתם יכולים לבקש מ
תמיכת הלקוחות |
| פעולת שחזור יכולה להיכשל אם משתמש אחד או יותר שמצוינים בקובץ SQL מוכן לשימוש לא קיימים. | לפני שמשחזרים קובץ SQL dump, כל המשתמשים במסד הנתונים שיש בבעלותם אובייקטים או שקיבלו הרשאות לאובייקטים במסד הנתונים שהושלך חייבים להיות קיימים במסד הנתונים של היעד. אם לא, פעולת השחזור תיכשל ולא תיצור מחדש את האובייקטים עם הבעלות או ההרשאות המקוריות.
יוצרים את משתמשי מסד הנתונים לפני שמשחזרים את קובץ ה-SQL. |
| אתם רוצים להגדיל את מספר הימים שבהם אפשר לשמור גיבויים אוטומטיים מ-7 ל-30 ימים, או יותר. | אתם יכולים
להגדיר את מספר הגיבויים האוטומטיים שיישארו. גיבויים אוטומטיים נמחקים באופן קבוע על סמך ערך השמירה שהוגדר. לכן, הגיבויים שמוצגים כרגע הם הגיבויים האוטומטיים היחידים שאפשר לשחזר מהם.
כדי לשמור גיבויים ללא הגבלת זמן, אפשר ליצור גיבוי לפי דרישה, כי הם לא נמחקים כמו גיבויים אוטומטיים. גיבויים על פי דרישה נשמרים ללא הגבלת זמן. כלומר, הן נשארות עד שהן נמחקות או עד שהמופע שאליו הן שייכות נמחק. הגיבוי הזה לא נמחק אוטומטית, ולכן הוא יכול להשפיע על החיוב. |
| גיבוי אוטומטי נכשל ולא קיבלתם התראה באימייל. | כדי לקבל מ-Cloud SQL התראה על סטטוס הגיבוי, מגדירים התראה שמבוססת על יומן. |
| מופע נכשל שוב ושוב כי הוא עובר בין מצבי הכשל לבין מצבי שחזור הגיבוי. ניסיונות להתחבר למסד הנתונים ולהשתמש בו אחרי השחזור נכשלים. |
פעולות שכדאי לנסות:
|
| גיליתם שחסרים נתונים כשביצעתם פעולת גיבוי או שחזור. | הטבלאות נוצרו כטבלאות לא מתועדות. לדוגמה:
הטבלאות האלה לא נכללות בשחזור מגיבוי:
הפתרון הוא להימנע משימוש בטבלאות שלא נרשמו ביומן אם רוצים לשחזר את הטבלאות האלה באמצעות גיבוי. אם אתם משחזרים ממסד נתונים שכבר יש בו טבלאות לא מתועדות, אתם יכולים להעביר את מסד הנתונים לקובץ ולהטעין מחדש את הנתונים אחרי שתשנו את הקובץ שהועבר מ- |
| אי אפשר למחוק מופע כשבוחרים לבצע גיבוי סופי בזמן מחיקת המופע. |
כשמוחקים מופע, צריך לאשר אם רוצים ליצור גיבוי סופי של המופע לפני המחיקה. אם הפעלתם גיבוי סופי באמצעות הגדרת המופע final-backup, הבחירה שתבצעו כשאתם מוחקים את המופע חייבת להיות זהה להגדרת המופע של הגיבוי הסופי שהגדרתם כשהפעלתם גיבוי סופי למופע. כדי לפתור את הבעיה, נסו אחד מהפתרונות הבאים:
|
| לא ניתן ליצור מופע רפליקה אחרי יצירה מוצלחת של מופע ראשי עם הגדרת הגיבוי הסופית. |
אם יוצרים מופע חדש עם ההגדרה של מופע הגיבוי הסופי מופעלת, צריך לעדכן את מדיניות הארגון של הגיבוי הסופי כדי להחיל את הגדרות הגיבוי רק על המופע הראשי.
אין תמיכה בגיבויים סופיים של מופעי רפליקה. מידע נוסף זמין במאמר מדיניות הארגון של Cloud SQL. |
שכפל
| שגיאה | פתרון בעיות |
|---|---|
השיבוט נכשל עם השגיאה constraints/sql.restrictAuthorizedNetworks. |
הפעולה של שיבוט נחסמת על ידי ההגדרה Authorized Networks.
Authorized Networks מוגדרות לכתובות IP ציבוריות בקטע 'קישוריות' במסוף Google Cloud , ואין אפשרות לשכפול בגלל שיקולי אבטחה.
אם אפשר, מסירים את כל הערכים של |
הודעת שגיאה: Failed to create subnetwork. Couldn't find free
blocks in allocated IP ranges. Please allocate new ranges for this service
provider. Help Token: [help-token-id]. |
ניסיתם להשתמש במסוף כדי לשכפל מכונה עם כתובת IP פרטית, אבל לא ציינתם את טווח כתובות ה-IP שהוקצה שבו אתם רוצים להשתמש, והמכונה המקורית לא נוצרה עם הטווח שצוין. Google Cloud כתוצאה מכך, המכונה המשוכפלת נוצרת בטווח אקראי. משתמשים ב- |
חיבור
| שגיאה | פתרון בעיות |
|---|---|
Aborted connection. |
הבעיה יכולה להיות:
האפליקציות צריכות להיות עמידות בפני כשלים ברשת ולפעול לפי השיטות המומלצות, כמו איגום חיבורים וניסיון חוזר. רוב כלי הניהול של מאגרי החיבורים מזהים את השגיאות האלה, אם אפשר. אחרת, האפליקציה צריכה לנסות שוב או להיכשל בצורה מסודרת. כדי לנסות שוב להתחבר, מומלץ להשתמש באחת מהשיטות הבאות:
שילוב של השיטות האלה עוזר לצמצם את ההגבלה. |
הודעת שגיאה: Login failed for user "" |
יכול להיות שתיתקלו בשגיאת ההתחברות הזו במהלך אימות ב-Microsoft Entra ID. כדי לפתור את הבעיה, צריך לוודא שיש פרטי כניסה ל-SQL Server עבור המשתמש הזה ב-Microsoft Entra ID. |
| בעיות בקישוריות לרשת עם מופעים של כתובות IP פרטיות | יכול להיות שתיתקלו באחת מהבעיות הבאות במהלך ההגדרה של השילוב:
מידע נוסף על פתרון הבעיות האלה זמין במאמר בנושא פתרון בעיות בשילוב עם Microsoft Entra ID. |
FATAL: database 'user' does not exist. |
gcloud sql connect --user פועל רק עם משתמש ברירת המחדל postgres.
מתחברים למשתמש שמוגדר כברירת מחדל, ואז מחליפים משתמשים. |
| אתם רוצים לדעת מי מחובר. | מתחברים למסד הנתונים ומריצים את הפקודה הבאה:
SELECT datname, usename, application_name as appname, client_addr, state, now() - backend_start as conn_age, now() - state_change as last_activity_age FROM pg_stat_activity WHERE backend_type = 'client backend' ORDER BY 6 DESC LIMIT 20 |
יצירת מופעים
| שגיאה | פתרון בעיות |
|---|---|
הודעת שגיאה: The zone or region does not have sufficient
resources to handle the request at the moment. |
בזמן שליחת הבקשה ליצירת המופע, לא היה מספיק נפח באזור שנבחר למשאבים המבוקשים או לסוג המכונה הווירטואלית. יכול להיות שבזמן הבקשה יש ביקוש גבוה בו-זמנית לפעולות באותו מיקום אזורי ספציפי. כדי לפתור את הבעיה, נסו שוב ליצור את המכונה באזור אחר, או נסו שוב ליצור את המכונה באותו אזור שבו התקבלה השגיאה, בשעה אחרת ביום. |
הודעת שגיאה: Failed to create subnetwork. Couldn't
find free blocks in allocated IP ranges. Please allocate new ranges for
this service provider. |
אין יותר כתובות זמינות בטווח כתובות ה-IP שהוקצה. יכולים להיות כמה תרחישים אפשריים:
כדי לפתור את הבעיה, אפשר להרחיב את טווח כתובות ה-IP הקיים שהוקצה או להקצות טווח כתובות IP נוסף לחיבור הפרטי לשירות. מידע נוסף זמין במאמר בנושא הקצאת טווח כתובות IP. אם השתמשתם בדגל אם מקצים טווח חדש, חשוב לוודא שההקצאה לא חופפת להקצאות קיימות. אחרי שיוצרים טווח IP חדש, מעדכנים את הקישור בין רשתות ה-VPC באמצעות הפקודה הבאה: gcloud services vpc-peerings update \ --service=servicenetworking.googleapis.com \ --ranges=OLD_RESERVED_RANGE_NAME,NEW_RESERVED_RANGE_NAME \ --network=VPC_NETWORK \ --project=PROJECT_ID \ --force אם מרחיבים הקצאה קיימת, חשוב להגדיל רק את טווח ההקצאה ולא להקטין אותו. לדוגמה, אם ההקצאה המקורית הייתה 10.0.10.0/24, ההקצאה החדשה צריכה להיות לפחות 10.0.10.0/23. באופן כללי, אם מתחילים מהקצאה של /24, כלל אצבע טוב הוא להקטין את /mask ב-1 לכל תנאי (קבוצת סוגי מופעים נוספת, אזור נוסף). לדוגמה, אם מנסים ליצור שתי קבוצות של סוגי מכונות באותו הקצאה, מספיק לעבור מ- /24 ל- /23. אחרי הרחבת טווח כתובות IP קיים, מעדכנים את ה-VPC Peering באמצעות הפקודה הבאה: gcloud services vpc-peerings update \ --service=servicenetworking.googleapis.com \ --ranges=RESERVED_RANGE_NAME \ --network=VPC_NETWORK \ --project=PROJECT_ID |
הודעת שגיאה: Failed to create subnetwork. Router status is
temporarily unavailable. Please try again later. Help Token:
[token-ID]. |
נסו ליצור שוב את המכונה של Cloud SQL. |
הודעת שגיאה: HTTPError 400: Invalid request: Incorrect Service Networking config for instance: PROJECT_ID:INSTANCE_NAME:SERVICE_NETWORKING_NOT_ENABLED. |
מפעילים את Service Networking API באמצעות הפקודה הבאה ומנסים שוב ליצור את מכונת Cloud SQL. gcloud services enable servicenetworking.googleapis.com \ --project=PROJECT_ID |
הודעת שגיאה: Failed to create subnetwork. Required
'compute.projects.get' permission for PROJECT_ID. |
כשיוצרים מופע באמצעות כתובת IP פרטית, נוצר חשבון שירות בדיוק בזמן באמצעות Service Networking API. אם הפעלתם את Service Networking API רק לאחרונה, יכול להיות שחשבון השירות לא ייווצר והיצירה של המופע תיכשל. במקרה כזה, צריך לחכות שחשבון השירות יתעדכן בכל המערכת או להוסיף אותו ידנית עם ההרשאות הנדרשות. |
הודעת שגיאה: More than 3 subject alternative names are not
allowed. |
אתם מנסים להשתמש ב-SAN בהתאמה אישית כדי להוסיף יותר משלושה שמות DNS לאישור השרת של מופע Cloud SQL. אי אפשר להוסיף למופע יותר משלושה שמות DNS. |
הודעת שגיאה: Subject alternative names %s is too long. The
maximum length is 253 characters. |
מוודאים ששמות ה-DNS שרוצים להוסיף לאישור השרת של מופע Cloud SQL לא מכילים יותר מ-253 תווים. |
הודעת שגיאה: Subject alternative name %s is invalid. |
מוודאים ששמות ה-DNS שרוצים להוסיף לאישור השרת של מופע Cloud SQL עומדים בקריטריונים הבאים:
|
ייצוא
| שגיאה | פתרון בעיות |
|---|---|
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. כדי למנוע שגיאות במהלך פעולות ייצוא שכוללות שמות משתמשים, צריך להשתמש גם בדגל --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 |
חיצונית ראשית
| שגיאה | פתרון בעיות |
|---|---|
Lost connection to MySQL server during query when dumping table. |
יכול להיות שהמקור הפך ללא זמין, או שה-dump הכיל חבילות גדולות מדי.
מוודאים שהמקור הראשי החיצוני זמין לחיבור. אפשר גם לשנות את הערכים של הדגלים net_read_timeout ו-net_write_timeout במופע המקור כדי שהשגיאה לא תופיע יותר. מידע נוסף על הערכים המותרים של הדגלים האלה זמין במאמר בנושא הגדרת דגלים של מסד נתונים. מידע נוסף על שימוש בדגלים של |
| המיגרציה הראשונית של הנתונים הושלמה, אבל לא מתבצעת שכפול של הנתונים. | אחת הסיבות האפשריות לבעיה היא שבמסד הנתונים של המקור הוגדרו דגלי שכפול שגורמים לכך שחלק מהשינויים במסד הנתונים או כולם לא משוכפלים.
מוודאים שדגלי השכפול, כמו מריצים את הפקודה |
| המיגרציה הראשונית של הנתונים הושלמה בהצלחה, אבל שכפול הנתונים מפסיק לפעול אחרי זמן מה. | פעולות שכדאי לנסות:
|
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. למידע נוסף על הוספת ההרשאות האלה לחשבון השירות, אפשר לעיין במאמר איך מעניקים לחשבון השירות של Cloud SQL הרשאות גישה ל-Vertex AI בניהול זהויות והרשאות גישה (IAM). |
הודעת שגיאה: Publisher Model `projects/PROJECT_ID/locations/REGION_NAME/publishers/google/models/MODEL_NAME` not found. |
מודל למידת המכונה או ה-LLM לא קיימים ב-Vertex AI. |
הודעת שגיאה: Resource exhausted: grpc: received message larger than max. |
הגודל של הבקשה שמועברת מ-Cloud SQL אל Vertex AI חורג מהמגבלה של gRPC של 4MB לכל בקשה. |
הודעת שגיאה: Cloud SQL attempts to send a request to Vertex AI. However, the instance is in the %s region, but the Vertex AI endpoint is in the %s region. Make sure the instance and endpoint are in the same region. |
מערכת Cloud SQL מנסה לשלוח בקשה אל Vertex AI. עם זאת, המופע נמצא באזור אחד, אבל נקודת הקצה של Vertex AI נמצאת באזור אחר. כדי לפתור את הבעיה, גם המופע וגם נקודת הקצה צריכים להיות באותו אזור. |
הודעת שגיאה: The Vertex AI endpoint isn't formatted properly. |
הפורמט של נקודת הקצה של Vertex AI לא תקין. מידע נוסף זמין במאמר שימוש בנקודות קצה פרטיות לחיזוי אונליין. |
הודעת שגיאה: Quota exceeded for aiplatform.googleapis.com/online_prediction_requests_per_base_model with base model: textembedding-gecko. |
מספר הבקשות ש-Cloud SQL מעביר אל Vertex AI חורג מהמגבלה של 1,500 בקשות לדקה לכל אזור לכל מודל לכל פרויקט. |
שרתים מקושרים
| שגיאה | פתרון בעיות |
|---|---|
Msg 7411, Level 16, State 1, Line 25
|
האפשרות DataAccess מושבתת. מריצים את הפקודה הבאה כדי להפעיל את הגישה לנתונים:EXEC sp_serveroption @server='LINKED_SERVER_NAME', @optname='data access', @optvalue='TRUE' מחליפים את LINKED_SERVER_NAME בשם של השרת המקושר. |
Access to the remote server is denied because no
login-mapping exists. (Microsoft SQL Server, Error: 7416)
|
אם הבעיה הזו מתרחשת בזמן יצירת חיבור מוצפן, צריך לנסות דרך אחרת לספק את מזהה המשתמש כשניגשים לשרת המקושר. כדי לעשות זאת, מריצים את הפקודה הבאה:
EXEC master.dbo.sp_addlinkedserver @server = N'LINKED_SERVER_NAME', @srvproduct= N'', @provider= N'MSOLEDBSQL', @datasrc= N'TARGET_SERVER_ID', @provstr= N'Encrypt=yes;TrustServerCertificate=yes;User ID=USER_ID' מחליפים את מה שכתוב בשדות הבאים:
|
| התנהגות לא צפויה | אם אתם נתקלים בהתנהגות לא צפויה, ודאו שאתם משתמשים בספק נתמך. מידע נוסף זמין במסמכי העזרה של Microsoft. |
רישום ביומן
| שגיאה | פתרון בעיות |
|---|---|
| יומני הביקורת לא נמצאו. | יומני Data Access נכתבים רק אם הפעולה היא קריאה ל-API שמבוססת על משתמש מאומת ויוצרת, משנה או קוראת נתונים שנוצרו על ידי משתמש, או אם הפעולה ניגשת לקובצי הגדרות או למטא-נתונים של משאבים. |
| פרטי הפעולות לא מופיעים ביומנים. | רוצים לקבל מידע נוסף על פעולה מסוימת.
לדוגמה, משתמש נמחק אבל אתם לא יכולים לגלות מי עשה את זה. היומנים מראים שהפעולה התחילה, אבל לא מספקים מידע נוסף. כדי שפרטים מזהים אישיים (PII) כאלה יירשמו ביומן, אתם צריכים להפעיל את רישום הפעולות ביומן הביקורת. |
חלק מהיומנים מסוננים מיומן error.log של מופע Cloud SQL ל-SQL Server.
|
היומנים המסוננים כוללים
יומני AD בלי חותמות זמן, וכוללים:
Login failed for user 'x'. Reason: Token-based server access
validation failed with an infrastructure error. Login lacks connect endpoint
permission. [CLIENT: 127.0.0.1]. היומנים האלה מסוננים כי הם עלולים לגרום לבלבול.
|
| הרישום ביומן משתמש בהרבה נפח אחסון. | יש שלושה סוגים של קובצי יומן שצורכים נפח אחסון בדיסק: יומני פעולות חוזרות, יומנים כלליים ויומנים בינאריים.
מתחברים למסד הנתונים ומריצים את הפקודות הבאות כדי לקבל פרטים על כל סוג: SHOW VARIABLES LIKE 'innodb_log_file%'; SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2),2) AS GB from mysql.general_log; SHOW BINARY LOGS; |
| קשה לקרוא את קובצי היומן. | אתם מעדיפים לראות את היומנים בפורמט JSON או טקסט.אתם יכולים להשתמש בפקודה
gcloud logging read
יחד עם פקודות לעיבוד נתונים ב-Linux כדי להוריד את היומנים.
כדי להוריד את היומנים כקובץ JSON: gcloud logging read \ "resource.type=cloudsql_database \ AND logName=projects/PROJECT_ID \ /logs/cloudsql.googleapis.com%2FLOG_NAME" \ --format json \ --project=PROJECT_ID \ --freshness="1d" \ > downloaded-log.json כדי להוריד את היומנים כקובץ TEXT: gcloud logging read \ "resource.type=cloudsql_database \ AND logName=projects/PROJECT_ID \ /logs/cloudsql.googleapis.com%2FLOG_NAME" \ --format json \ --project=PROJECT_ID \ --freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \ | .textPayload' \ --order=asc > downloaded-log.txt |
| יומני השאילתות לא נמצאים ביומני PostgreSQL. | צריך להפעיל את הדגלים pgaudit.
|
ניהול מופעים
| שגיאה | פתרון בעיות |
|---|---|
| ביצועים איטיים אחרי הפעלה מחדש של MySQL. | ב-Cloud SQL אפשר לשמור נתונים במטמון במאגר הנתונים הזמני של InnoDB. עם זאת, אחרי הפעלה מחדש, המטמון הזה תמיד ריק, וכל פעולת קריאה דורשת תהליך הלוך ושוב לשרת העורפי כדי לקבל נתונים. כתוצאה מכך, עד שהמטמון יתמלא, יכול להיות שהשאילתות יהיו איטיות מהצפוי. |
| שחזור איטי אחרי קריסה. | יכול להיות שנצבר סכום גדול של general_log.
כדי לקצר את זמן השחזור אחרי קריסה, כדאי למנוע הצטברות של general_log גדול. אם האפשרות general_log מופעלת, כדאי לקצר את הטבלה ולהפעיל את general_log רק לפרקי זמן קצרים.
כדי לדעת מה הגודל של היומנים הכלליים, מתחברים למסד הנתונים ומריצים את השאילתה הבאה: SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;
|
| אתם רוצים לדעת מה תופס נפח אחסון. | לדוגמה, אם אתם רואים שהמסד נתונים שלכם משתמש רק ב-3GB, אבל בנתוני האחסון מצוין שנעשה שימוש ב-14GB. רוב הנפח שלא משמש את הטבלאות
משמש את יומני הנתונים הבינאריים או את הקבצים הזמניים.
פעולות שכדאי לנסות:
|
| השאילתות חסומות. | יכול להיות ששאילתות ינעלו את מסד הנתונים של MySQL, ויגרמו לכל השאילתות הבאות להיחסם או להגיע לפסק זמן.
מתחברים למסד הנתונים ומריצים את השאילתה הבאה:
יכול להיות שהפריט הראשון ברשימה הוא זה שמחזיק את הנעילה, והפריטים הבאים ממתינים לו.
|
| אי אפשר למחוק יומני בינאריים באופן ידני. | אי אפשר למחוק יומנים בינאריים באופן ידני. יומני בינאריים נמחקים אוטומטית עם הגיבוי האוטומטי המשויך אליהם, בדרך כלל אחרי שבעה ימים בערך. |
| אתם רוצים למצוא מידע על קבצים זמניים. | קובץ בשם ibtmp1 משמש לאחסון נתונים זמניים. הקובץ הזה מאופס כשמפעילים מחדש את מסד הנתונים. כדי למצוא מידע על השימוש בקובץ זמני, מתחברים למסד הנתונים ומריצים את השאילתה הבאה:
|
| אתם רוצים לדעת מה הגודל של הטבלה. | המידע הזה זמין במסד הנתונים.
מתחברים למסד הנתונים ומריצים את השאילתה הבאה:
|
| mysqld קיבל אות 11. | נסו לשנות את מבנה השאילתות כך שלא ייצרו יותר מדי חיבורים.
אם הבעיה לא נפתרת, אפשר לפנות לתמיכת הלקוחות.
אות 11 בדרך כלל מייצג בעיה בתוכנת MySQL.
|
InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The
settings might not be optimal. |
כלי ניקוי הדפים לא יכול לעמוד בקצב השינויים במופע.
פעם בשנייה, כלי הניקוי של הדף סורק את מאגר הנתונים הזמני כדי למצוא דפים עם נתונים מלוכלכים (dirty), כדי לנקות אותם ממאגר הנתונים הזמני לדיסק. האזהרה שמוצגת מציינת שיש הרבה דפים מלוכלכים שצריך לנקות, ושלוקח יותר משנייה לנקות קבוצה של דפים כאלה בדיסק.
מפצלים את המכונה אם אפשר. עדיף להשתמש בהרבה מכונות קטנות של Cloud SQL מאשר במכונה גדולה אחת. |
| אתם רוצים לדעת אילו שאילתות מופעלות עכשיו. | מתחברים למסד הנתונים ומריצים את השאילתה הבאה:
|
| אתם רוצים לדעת באילו יחידות נעשה שימוש בשדה מסוים. | מתחברים למסד הנתונים ומריצים את השאילתה הבאה
(באמצעות FIELD_NAME משלכם):
|
| רוצים למצוא את הערך הנוכחי של הגדרת מסד נתונים. | מתחברים למסד הנתונים ומריצים את השאילתה הבאה
(באמצעות SETTING_NAME משלכם):
מריצים את הפקודה |
| רוצים להפסיק תהליך רקע חסום. | למשתמש צריך להיות התפקיד pg_signal_backend.
מריצים את הפקודות הבאות:
|
| השימוש במזהי העסקאות במופע מתקרב ל-100%. | מערכת המעקב הפנימית שלך מתריעה שהמופע מתקרב ל-100%
בצריכת מזהי עסקאות. אתם רוצים להימנע ממעבר של עסקאות,
שיכול לחסום פעולות כתיבה.
יכול להיות שהעבודה של autovacuum חסומה, או שהיא לא משחררת את מזהי העסקאות מספיק מהר כדי לעמוד בקצב של עומס העבודה. כדי למנוע הפסקות שירות בגלל בעיה של חזרה למספרים קודמים של מזהי עסקאות, אפשר לעיין בטיפים לשירות עצמי לטיפול בבעיה של חזרה למספרים קודמים של מזהי עסקאות. עצות כלליות לשיפור הביצועים מופיעות במאמר Optimizing, monitoring, and troubleshooting vacuum operations in PostgreSQL. |
| הגדלנו את נפח האחסון הזמני. | האחסון האוטומטי מופעל.
הפעלה מחדש מוחקת את הקבצים הזמניים אבל לא מקטינה את נפח האחסון. רק תמיכת הלקוחות יכולה לאפס את גודל המופע. |
| הנתונים נמחקים באופן אוטומטי. | סביר להניח שסקריפט פועל איפשהו בסביבה שלכם.
בודקים ביומנים את השעה שבה נמחק הקובץ, ומחפשים סקריפט לא מורשה שפועל מלוח בקרה או מתהליך אוטומטי אחר. |
| אי אפשר למחוק את המופע. | יכול להיות שתופיע הודעת השגיאה ERROR: (gcloud.sql.instances.delete) HTTP Error
409: The instance or operation is not in an appropriate state to handle the
request, או שהמופע יסומן בסטטוס INSTANCE_RISKY_FLAG_CONFIG.
אלה כמה מהסיבות האפשריות לכך:
|
| המכונה תקועה בגלל גודל גדול של נתונים זמניים. | המערכת יכולה ליצור הרבה טבלאות זמניות בו-זמנית, בהתאם לשאילתות ולעומס.
לצערנו, אי אפשר להקטין את הקובץ אחת מהאפשרויות לצמצום הסיכון היא ליצור את הטבלה הזמנית באמצעות |
| שגיאה קריטית במהלך השדרוג. | יכול להיות שיומני הרישום יספקו מידע נוסף, אבל בכל מקרה, יכול להיות שתצטרכו תמיכת לקוחות כדי ליצור מחדש את המופע. |
| המופע נתקע בהפעלה מחדש אחרי שנגמר לו המקום בדיסק. | היכולת להגדיל את נפח האחסון באופן אוטומטי לא מופעלת.
אם נפח האחסון של המופע שלכם ייגמר, והיכולת להגדלה אוטומטית של נפח האחסון לא מופעלת, המופע יעבור למצב אופליין. כדי להימנע מהבעיה הזו, אפשר לערוך את המופע כדי להפעיל הגדלה אוטומטית של נפח האחסון. |
| המופע הראשי המקומי תקוע. | Google Cloud לא יכול לעזור עם מופעים שלא נמצאים ב-Cloud SQL. |
| כיבוי איטי בהפעלה מחדש. | כשמכונה מושבתת, כל החיבורים הפתוחים שלא מסתיימים תוך 60 שניות גורמים להשבתה לא תקינה.
אם משך החיבורים קצר מ-60 שניות, אפשר להימנע מרוב השבתות לא תקינות, כולל חיבורים משורת הפקודה של מסד הנתונים. אם משאירים את החיבורים האלה פתוחים במשך שעות או ימים, יכול להיות שהכיבוי לא יהיה תקין. |
| אי אפשר למחוק משתמש. | כנראה שיש למשתמש אובייקטים במסד הנתונים שתלויים בו. תצטרכו להסיר את האובייקטים האלה או להקצות אותם מחדש למשתמש אחר.
בודקים אילו אובייקטים תלויים במשתמש, ואז משחררים אותם או מקצים אותם מחדש למשתמש אחר. |
| שאילתות מסוימות פועלות לאט. | יש הרבה סיבות לכך ששאילתות פועלות לאט, בעיקר בגלל היבטים ספציפיים של מסד הנתונים. סיבה אחת שיכולה להיות קשורה ל-Cloud SQL היא חביון ברשת, כשהמשאב של המקור (הכתיבה או הקריאה) והמשאב של היעד (Cloud SQL) נמצאים באזורים שונים.
כדאי לעיין במיוחד ב טיפים כלליים לשיפור הביצועים. אם פעולות ההוספה, העדכון או המחיקה במסד הנתונים מתבצעות לאט, כדאי לבצע את הפעולות הבאות:
כדי להקטין את זמן האחזור, מומלץ למקם את משאבי המקור והיעד באותו אזור. |
| מוצגת הודעה על חוסר זיכרון, אבל בתרשימי המעקב לא רואים את זה. | יכול להיות שמופע ייכשל וידווח על Out of memory, אבל בטבלאות במסוף או ב-Cloud Monitoring ייראה כאילו עדיין יש זיכרון פנוי. Google Cloud
יש גורמים נוספים מלבד עומס העבודה שיכולים להשפיע על השימוש בזיכרון, כמו מספר החיבורים הפעילים ותהליכי התקורה הפנימיים. הם לא תמיד משתקפים בתרשימי המעקב. מוודאים שיש מספיק תקורה למופע כדי להתחשב בעומס העבודה, בתוספת תקורה נוספת. |
| שחזור של מופע שנמחק. | כל הנתונים במופע, כולל גיבויים, אובדים לתמיד כשמוחקים את המופע.
כדי לשמור את הנתונים, צריך לייצא אותם ל-Cloud Storage לפני שמוחקים את המופע. התפקיד Cloud SQL Admin כולל את ההרשאה למחיקת המכונה. כדי למנוע מחיקה בטעות, צריך להקצות את התפקיד הזה רק כשנדרש. |
| רוצים לשנות את השם של מופע קיים ב-Cloud SQL. | שינוי שם של מופע קיים אינו נתמך.
יש דרכים אחרות להשיג את המטרה על ידי יצירת מופע חדש.
בשני המקרים, אפשר למחוק את המופע הישן אחרי שהפעולה מסתיימת. מומלץ לבחור באפשרות של שיבוט, כי היא לא משפיעה על הביצועים ולא מחייבת אתכם לבצע מחדש הגדרות של מופעים, כמו סימון, סוג מכונה, גודל אחסון וזיכרון. |
| שגיאה במחיקת מופע. | אם ההגנה מפני מחיקה מופעלת עבור מופע, צריך לאשר את התוכניות למחיקת המופע. לאחר מכן, משביתים את ההגנה מפני מחיקה לפני שמוחקים את המופע. |
התחברות לשירות פרטי
| שגיאה | פתרון בעיות |
|---|---|
| הקובץ המצורף עם השירות של המופע לא מקבל את נקודת הקצה של Private Service Connect. |
|
ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource: The resource 'projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME' was not found |
הודעת השגיאה הזו יכולה להופיע כשמזמינים כתובת IP פנימית סטטית לנקודת הקצה של Private Service Connect. מוודאים שרשת המשנה שצוינה קיימת בפרויקט שצוין ב-URI. אם רוצים ליצור נקודת קצה בפרויקט שירות אבל להשתמש ברשת משנה מרשת VPC משותפת, צריך לציין את רשת המשנה באמצעות ה-URI שלה ולהשתמש במזהה הפרויקט של פרויקט המארח ב-URI. מידע נוסף זמין במאמר יצירת נקודת הקצה באופן ידני. |
ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource:
- The resource 'projects/PROJECT_ID/global/networks/NETWORK_NAME' was not found |
הודעת השגיאה הזו יכולה להופיע כשיוצרים נקודת קצה (endpoint) של Private Service Connect באופן ידני. מוודאים שהרשת שצוינה קיימת בפרויקט שצוין ב-URI. אם רוצים ליצור נקודת קצה בפרויקט שירות אבל להשתמש ברשת VPC משותפת, צריך לציין את הרשת באמצעות ה-URI שלה ולהשתמש במזהה הפרויקט של פרויקט המארח ב-URI. מידע נוסף זמין במאמר יצירת נקודת הקצה באופן ידני. |
Invalid consumer network status for PSC auto connection. |
הרשת הצרכנית לא מוגדרת בצורה נכונה, או שהיא לא מוגדרת בכלל, ולכן אין נקודת קצה שאפשר להתחבר אליה. כדי להתחבר לנקודת הקצה, צריך לבדוק את הסטטוס שלה ולתקן את השגיאה לפני שמנסים להתחבר שוב.
|
No permission to create a service connection policy. |
אין לכם את ההרשאות הדרושות כדי ליצור מדיניות לחיבור שירותים. כדי ליצור מדיניות של חיבור שירות, צריך את התפקיד |
| לא ניתן לקובץ המצורף עם הרשת לקבל חיבורים מהממשק של Private Service Connect כשמשתמשים בקישוריות יוצאת של Private Service Connect. | אם הרשת החיצונית לא יכולה לקבל חיבורים מממשק Private Service Connect, יכול להיות שמדיניות החיבורים בקובץ המצורף של הרשת לא מוגדרת בצורה נכונה. כדי לאמת את החיבורים שאושרו, מריצים את הפקודה הבאה בקובץ המצורף לרשת: gcloud compute network-attachments describe default --region=REGION_ID |
שכפול
| שגיאה | פתרון בעיות |
|---|---|
| השכפול של העותק לקריאה לא התחיל בזמן היצירה. | סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל. |
| אי אפשר ליצור העתק לקריאה – השגיאה invalidFlagValue. | אחד מהדגלים בבקשה לא תקין. יכול להיות שזה דגל שציינתם באופן מפורש או דגל שהוגדר לו ערך ברירת מחדל.
קודם כול, בודקים שהערך של הדגל אם הדגל |
| לא ניתן ליצור רפליקה לקריאה – שגיאה לא ידועה. | סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן.
בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
אם השגיאה היא: |
| הדיסק מלא. | יכול להיות שהגודל של הדיסק של המופע הראשי יתמלא במהלך יצירת רפליקה. עורכים את המופע הראשי כדי לשדרג אותו לגודל דיסק גדול יותר. |
| מופע הרפליקה משתמש ביותר מדי זיכרון. | הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמבוקשות לעיתים קרובות, מה שעלול לגרום לה להשתמש ביותר זיכרון מהמופע הראשי.
מפעילים מחדש את מופע הרפליקה כדי לפנות את המקום הזמני בזיכרון. |
| השכפול הופסק. | הגעתם למגבלת האחסון המקסימלית ולא הפעלתם את האפשרות להגדלת נפח האחסון באופן אוטומטי.
עורכים את המופע כדי להפעיל את |
| ההשהיה בשכפול גבוהה באופן עקבי. | עומס הכתיבה גבוה מדי בשביל הרפליקה. השהיית שכפול
מתרחשת כשהשרשור של SQL ברפליקה לא מצליח לעמוד בקצב של השרשור של IO. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום לעיכובים זמניים או קבועים בשכפול של סכימה נתונה. חלק מהסיבות הנפוצות להשהיה בשכפול:
הנה כמה פתרונות אפשריים:
|
| יצירת רפליקה נכשלה בגלל זמן קצוב לתפוגה. | עסקאות ארוכות טווח שלא בוצעו במופע הראשי עלולות לגרום לכך שיצירת רפליקת קריאה תיכשל.
אחרי שמפסיקים את כל השאילתות הפעילות, יוצרים מחדש את העותק. |