בדקו אם השאלה או הבעיה שלכם כבר קיבלו מענה באחד מהדפים הבאים:
- שאלות נפוצות
- בעיות מוכרות
- הודעות שגיאה
- אבחון בעיות
- ניפוי באגים בבעיות בחיבור
- בעיות בעדכון נפח האחסון
הנושאים בדף הזה:
- גיבוי ושחזור
- שיבוט
- קישוריות
- יצירת מכונות
- הפעלת SQL באמצעות Data API
- דגלים
- זמינות גבוהה
- ייבוא וייצוא
- שרתים מקושרים
- רישום ביומן
- ניהול מכונות
- Private Service Connect
- שכפול
גיבוי ושחזור
| שגיאה | פתרון בעיות |
|---|---|
| אי אפשר לראות את הסטטוס של הפעולה הנוכחית. | במסוף Google Cloud מדווח רק על הצלחה או כישלון בסיום הפעולה. הוא לא מיועד להצגת אזהרות או עדכונים אחרים.
מריצים את
הפקודה |
| אתם רוצים לגלות מי ביצע פעולת גיבוי על פי דרישה. | בממשק המשתמש לא מוצג המשתמש שהתחיל את הפעולה.
מחפשים ביומנים ומסננים לפי טקסט כדי למצוא את המשתמש. יכול להיות שתצטרכו להשתמש ביומני ביקורת כדי לראות מידע פרטי. קובצי היומן הרלוונטיים כוללים:
|
| אחרי שמוחקים מכונה, אי אפשר לגבות אותה. | אם מוחקים מכונה בלי לבצע גיבוי סופי של הנתונים, אי אפשר לבצע שחזור נתונים. עם זאת, אם משחזרים את המכונה, Cloud SQL משחזר גם את הגיבויים. מידע נוסף על שחזור מכונה שנמחקה זמין במאמר שמירת גיבויים אחרי מחיקת מכונה. אם ביצעתם פעולת ייצוא, צרו מכונה חדשה ואז בצעו פעולת ייבוא כדי ליצור מחדש את מסד הנתונים. הייצוא נכתב ב-Cloud Storage והייבוא נקרא משם. |
| גיבוי אוטומטי תקוע במשך שעות רבות ואי אפשר לבטל אותו. | הגיבויים יכולים להימשך זמן רב, בהתאם לגודל מסד הנתונים.
אם אתם ממש צריכים לבטל את הפעולה, אתם יכולים לבקש מ
תמיכת הלקוחות |
| פעולת שחזור יכולה להיכשל כשמשתמש אחד או יותר שמצוינים בקובץ ה-SQL המוכן לשימוש לא קיימים. | לפני שמשחזרים קובץ dump של SQL, כל המשתמשים במסד הנתונים שיש בבעלותם אובייקטים או שקיבלו הרשאות לאובייקטים במסד הנתונים שהושלך חייבים להיות קיימים במסד הנתונים של היעד. אם אין להם את ההרשאות האלה, פעולת השחזור לא תצליח ליצור מחדש את האובייקטים עם הבעלות או ההרשאות המקוריות.
יוצרים את המשתמשים במסד הנתונים לפני שמשחזרים את ה-SQL dump. |
| אתם רוצים להגדיל את מספר הימים שבהם אפשר לשמור גיבויים אוטומטיים מ-7 ל-30 ימים, או יותר. | אפשר
להגדיר את מספר הגיבויים האוטומטיים שרוצים לשמור, אבל אי אפשר לשמור פחות ממספר ברירת המחדל (שבעה). גיבויים אוטומטיים נמחקים באופן קבוע על סמך ערך השמירה שהוגדר. לצערנו, זה אומר שהגיבויים שמוצגים כרגע הם הגיבויים האוטומטיים היחידים שאפשר לשחזר מהם.
כדי לשמור גיבויים ללא הגבלת זמן, אתם יכולים ליצור גיבוי על פי דרישה, כי גיבויים כאלה לא נמחקים כמו גיבויים אוטומטיים. גיבויים לפי דרישה נשמרים ללא הגבלת זמן. כלומר, הם נשארים עד שמוחקים אותם או עד שמוחקים את המכונה שהם שייכים אליה. מכיוון שסוג הגיבוי הזה לא נמחק באופן אוטומטי, הוא יכול להשפיע על החיוב. |
| גיבוי אוטומטי נכשל ולא קיבלתם התראה באימייל. | כדי לקבל מ-Cloud SQL התראה על סטטוס הגיבוי, מגדירים התראה מבוססת-יומן. |
| גיבוי אוטומטי או גיבוי על פי דרישה נכשל במכונה עם יותר מ-50 תוויות שהוגדרו על ידי המשתמש. | כש-Cloud SQL מבצע גיבוי, הוא מעתיק את התוויות שהמשתמשים הגדירו למכונה לתמונת המצב של האחסון הבסיסי, ומוסיף תוויות מערכת פנימיות. אם המספר הכולל של התוויות חורג מהמגבלה של 64 תוויות לכל קובץ snapshot, הגיבוי נכשל.
כדי לפתור את הבעיה, צריך להסיר תוויות עודפות כך שיהיו במכונה עד 50 תוויות שהוגדרו על ידי המשתמש. מידע נוסף זמין במאמר הוספת תוויות למכונות. |
| אי אפשר לשחזר את המכונה באמצעות הפקודה Transact-SQL RESTORE או SQL Server Management Studio (SSMS). |
ב-Cloud SQL אי אפשר לשחזר מכונות באמצעות SSMS.
כדי לשחזר את המכונה, מריצים את הפקודה
gcloud sql import.
|
| אתם לא יכולים לראות את היסטוריית הגיבוי של היומן. | היסטוריית הגיבוי של היומן נשמרת רק למשך 60 יום בטבלאות של היסטוריית הגיבוי ב-מסד הנתונים msdb. |
| אי אפשר למחוק מכונה כשבוחרים ליצור גיבוי סופי בזמן מחיקת המכונה. |
כשמוחקים מכונה, צריך לאשר אם רוצים ליצור גיבוי סופי של המכונה לפני המחיקה. אם הפעלתם את הגיבוי הסופי באמצעות הגדרת המכונה final-backup, הבחירה שתבצעו כשתמחקו את המכונה צריכה להתאים להגדרת מכונת הגיבוי הסופי שקבעתם כשהפעלתם את הגיבוי הסופי למכונה. כדי לפתור את הבעיה, נסו אחד מהפתרונות הבאים:
|
| לא הצלחנו ליצור מכונה של רפליקה אחרי שיצרנו בהצלחה מכונה ראשית עם הגדרת הגיבוי הסופי. |
אם יוצרים מכונה חדשה כשההגדרה של מכונת הגיבוי הסופי מופעלת, צריך לעדכן את מדיניות הארגון של הגיבוי הסופי כדי להחיל את הגדרות הגיבוי על המכונה הראשית בלבד.
אין תמיכה בגיבויים סופיים במכונות של רפליקות. מידע נוסף זמין במאמר מדיניות הארגון ב-Cloud SQL. |
שכפל
| שגיאה | פתרון בעיות |
|---|---|
השכפול נכשל ומוצגת השגיאה constraints/sql.restrictAuthorizedNetworks. |
פעולת השכפול נחסמת על ידי ההגדרה Authorized Networks.
Authorized Networks מוגדרים לכתובות IP ציבוריות בקטע Connectivity במסוף Google Cloud , ואי אפשר לשכפל בגלל שיקולי אבטחה.
אם אפשר, מסירים את כל הרשומות של |
הודעת שגיאה: Failed to create subnetwork. Couldn't find free
blocks in allocated IP ranges. Please allocate new ranges for this service
provider. Help Token: [help-token-id]. |
אתם מנסים להשתמש במסוף כדי לשכפל מכונה עם כתובת IP פרטית, אבל לא ציינתם את טווח ה-IP שהוקצה שבו אתם רוצים להשתמש, ומכונת המקור לא נוצרה עם הטווח שצוין. Google Cloud כתוצאה מכך, המכונה המשוכפלת נוצרת בטווח אקראי. משתמשים ב- |
חיבור
| שגיאה | פתרון בעיות |
|---|---|
Aborted connection. |
הבעיה יכולה להיות:
האפליקציות צריכות להיות עמידות בפני כשלים ברשת ולפעול לפי השיטות המומלצות, כמו מאגר חיבורים וניסיונות חוזרים. רוב מאגרי החיבורים מזהים את השגיאות האלה כשאפשר. אחרת, האפליקציה צריכה לנסות שוב או להיכשל בצורה חלקה. כדי לנסות להתחבר מחדש, מומלץ להשתמש בשיטות הבאות:
שילוב של השיטות האלה עוזר לצמצם את ההאטה. |
| הזמן הקצוב לתפוגה של החיבור או שגיאת חיבור כללית כשמשתמשים בכתובת IP פרטית או בקישור בין רשתות VPC שכנות (peering). | ניסיונות החיבור נכשלים עם שגיאות כלליות של זמן קצוב לתפוגה או שגיאות חיבור ללא פרטי אבחון. שלבים לפתרון בעיות:
לפרטים נוספים ולפקודות אבחון של gcloud, קראו את המאמר אבחון כשלים ברשת VPC ובקישור דרך IP פרטי. |
הודעת שגיאה: Login failed for user "" |
יכול להיות שתיתקלו בשגיאת ההתחברות הזו במהלך אימות Microsoft Entra ID. כדי לפתור את הבעיה, ודאו שקיים פרטי התחברות ל-SQL Server למשתמש הזה ב-Microsoft Entra ID. |
| בעיות בקישוריות לרשת במכונות עם כתובת IP פרטית | יכול להיות שתיתקלו בבעיות הבאות במהלך הגדרת השילוב:
במאמר פתרון בעיות בשילוב עם Microsoft Entra ID מוסבר איך לפתור את הבעיות האלה. |
יצירת מכונות
| שגיאה | פתרון בעיות |
|---|---|
הודעת שגיאה: The zone or region does not have sufficient
resources to handle the request at the moment. |
באזור שנבחר אין מספיק קיבולת למשאבים המבוקשים או לסוג המכונה הווירטואלית בזמן הבקשה ליצירת המכונה. יכול להיות שבזמן הבקשה יש ביקוש תפעולי גבוה בו-זמנית במיקום האזורי הספציפי הזה. כדי לפתור את הבעיה, נסו ליצור את המכונה באזור אחר או באותו אזור שבו התקבלה השגיאה, אבל בשעה אחרת ביום. |
הודעת שגיאה: Failed to create subnetwork. Couldn't
find free blocks in allocated IP ranges. Please allocate new ranges for
this service provider. |
אין יותר כתובות זמינות בטווח ה-IP שהוקצה. יכולים להיות כמה תרחישים אפשריים:
כדי לפתור את הבעיה, אתם יכולים להרחיב את טווח כתובות ה-IP שהוקצה או להקצות טווח כתובות IP נוסף לחיבור לשירות הפרטי. מידע נוסף זמין במאמר הקצאת טווח של כתובות IP. אם השתמשתם בדגל אם אתם מקצים טווח חדש, חשוב לוודא שההקצאה לא חופפת להקצאות קיימות. אחרי שיוצרים טווח כתובות IP חדש, מעדכנים את קישור ה-VPC השכנות באמצעות הפקודה הבאה: gcloud services vpc-peerings update \ --service=servicenetworking.googleapis.com \ --ranges=OLD_RESERVED_RANGE_NAME,NEW_RESERVED_RANGE_NAME \ --network=VPC_NETWORK \ --project=PROJECT_ID \ --force אם אתם מרחיבים הקצאה קיימת, הקפידו להגדיל רק את טווח ההקצאה ולא להקטין אותו. לדוגמה, אם ההקצאה המקורית הייתה 10.0.10.0/24, ההקצאה החדשה צריכה להיות לפחות 10.0.10.0/23. באופן כללי, אם מתחילים מהקצאה של /24, כלל אצבע טוב הוא להפחית את ה- /mask ב-1 לכל תנאי (קבוצה נוספת של סוגי מכונות, אזור נוסף). לדוגמה, אם מנסים ליצור את שתי קבוצות סוגי המכונות באותה הקצאה, מספיק לעבור מ- /24 ל- /23. אחרי שמרחיבים טווח כתובות IP קיים, מעדכנים את הקישור בין רשתות ה-VPC באמצעות הפקודה הבאה: gcloud services vpc-peerings update \ --service=servicenetworking.googleapis.com \ --ranges=RESERVED_RANGE_NAME \ --network=VPC_NETWORK \ --project=PROJECT_ID |
הודעת שגיאה: Failed to create subnetwork. Router status is
temporarily unavailable. Please try again later. Help Token:
[token-ID]. |
מנסים ליצור שוב את המכונה של Cloud SQL. |
הודעת שגיאה: HTTPError 400: Invalid request: Incorrect Service Networking config for instance: PROJECT_ID:INSTANCE_NAME:SERVICE_NETWORKING_NOT_ENABLED. |
מפעילים את Service Networking API באמצעות הפקודה הבאה ומנסים ליצור שוב את המכונה של Cloud SQL. gcloud services enable servicenetworking.googleapis.com \ --project=PROJECT_ID |
הודעת שגיאה: Failed to create subnetwork. Required
'compute.projects.get' permission for PROJECT_ID. |
כשיוצרים מכונה באמצעות כתובת IP פרטית, נוצר חשבון שירות בזמן אמת באמצעות Service Networking API. אם הפעלתם את Service Networking API רק לאחרונה, יכול להיות שחשבון השירות לא ייווצר ויצירת המכונה תיכשל. במקרה כזה, צריך להמתין עד שחשבון השירות יופץ במערכת, או להוסיף אותו ידנית עם ההרשאות הנדרשות. |
הודעת שגיאה: More than 3 subject alternative names are not
allowed. |
אתם מנסים להשתמש ב-SAN בהתאמה אישית כדי להוסיף יותר משלושה שמות DNS לאישור השרת של מכונה ב-Cloud SQL. אי אפשר להוסיף למכונה יותר משלושה שמות DNS. |
הודעת שגיאה: Subject alternative names %s is too long. The
maximum length is 253 characters. |
חשוב לוודא ששמות ה-DNS שרוצים להוסיף לאישור השרת של מכונה ב-Cloud SQL לא מכילים יותר מ-253 תווים. |
הודעת שגיאה: Subject alternative name %s is invalid. |
מוודאים ששמות ה-DNS שרוצים להוסיף לאישור השרת של מכונה ב-Cloud SQL עומדים בקריטריונים הבאים:
|
הפעלת SQL באמצעות Data API
| שגיאה | פתרון בעיות |
|---|---|
The instance doesn't allow using ExecuteSql to access this instance.
You can allow it by patching the instance with {settings: { dataApiAccess:
"ALLOW_DATA_API" }}
|
Data API מושבת כברירת מחדל. כדי לפתור את הבעיה, מפעילים את Data API במכונה. |
Secret cannot be provided when auto_iam_authn is true.
|
כשמגדירים את auto_iam_authn ל-true, מבצעים אימות למסד הנתונים באמצעות IAM.
בשיטת האימות הזו לא נדרשת סיסמה או סוד.
אימות באמצעות IAM
|
ExecuteSql API is not supported for instances in certain
Assured Workloads control packages folders yet.
|
יכול להיות שסקריפט ה-SQL והתגובה להפעלה שלו יעברו דרך מיקומי ביניים בין הלקוח לבין המיקום של מכונת היעד. לכן, בקשות ייכשלו במכונות בפרויקטים מסוימים של Assured Workloads. אם הפרויקט לא רשום ל-Assured Workloads אבל constraints/sql.restrictNoncompliantResourceCreation נאכף באופן ידני, צריך לבקש מהאדמין של הארגון להסיר את האילוץ, והבעיה תיפתר במכונות החדשות שייווצרו.
|
The server principal USERNAME is not able to access the
database DATABASE_NAME under the current security context.
|
המשתמש לא חבר במסד הנתונים. מתחברים למסד הנתונים כמשתמש sqlserver ומוסיפים את המשתמש החדש, ואז נותנים למשתמש החדש את התפקיד db_owner במסד הנתונים. לדוגמה:
EXEC sp_adduser 'user'; EXEC sp_addrolemember 'db_owner', 'user' |
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 |
| אתם רוצים שהייצוא יתבצע באופן אוטומטי. | ב-Cloud SQL אין דרך להפוך את הייצוא לאוטומטי.
אתם יכולים ליצור מערכת ייצוא אוטומטית משלכם באמצעות מוצרי Google Cloudכמו Cloud Scheduler, Pub/Sub ופונקציות Cloud Run, בדומה למאמר הזה בנושא אוטומציה של גיבויים. |
דגלים
| שגיאה | פתרון בעיות |
|---|---|
| אתם רוצים לשנות את אזור הזמן של מכונה ב-Cloud SQL. |
במאמר הגדרות של מכונה מוסבר איך לעדכן את אזור הזמן של המכונה. ב-Cloud SQL ל-SQL Server, אפשר להשתמש בפונקציה |
זמינות גבוהה
| שגיאה | פתרון בעיות |
|---|---|
| אתם לא מוצאים את המדדים של מעבר ידני לגיבוי במקרה של כשל. | רק מעברים אוטומטיים לגיבוי נכללים במדדים. |
| המשאבים של מכונת Cloud SQL (מעבד ו-RAM) קרובים ל-100% שימוש, ולכן המכונה עם הזמינות הגבוהה מושבתת. | גודל המכונה של המכונה קטן מדי לעומס.
עורכים את המכונה כדי לשדרג למכונה גדולה יותר עם יותר מעבדי CPU וזיכרון. |
ייבוא
| שגיאה | פתרון בעיות |
|---|---|
HTTP Error 409: Operation failed because another operation was already in progress. |
כבר יש פעולה בהמתנה למכונה. מותר לבצע פעולה אחת בלבד בכל פעם. כדאי לנסות לשלוח את הבקשה אחרי שהפעולה הנוכחית תסתיים. |
| פעולת הייבוא נמשכת יותר מדי זמן. | יותר מדי חיבורים פעילים יכולים להפריע לפעולות הייבוא.
סוגרים פעולות שלא בשימוש. בודקים את המעבד (CPU) ואת השימוש בזיכרון במכונת Cloud SQL, כדי לוודא שיש מספיק משאבים זמינים. הדרך הטובה ביותר לוודא שמשימת הייבוא מקבלת את מרב המשאבים היא להפעיל מחדש את המכונה לפני התחלת הפעולה. הפעלה מחדש:
|
| פעולת ייבוא יכולה להיכשל כשמשתמש אחד או יותר שמצוינים בקובץ ה-dump לא קיימים. | לפני שמייבאים קובץ dump, כל המשתמשים במסד הנתונים שיש בבעלותם אובייקטים או שקיבלו הרשאות לאובייקטים במסד הנתונים שהושלך חייבים להיות קיימים במסד הנתונים של היעד. אם אין להם את ההרשאות האלה, פעולת הייבוא לא תצליח ליצור מחדש את האובייקטים עם הבעלות או ההרשאות המקוריות.
יוצרים את משתמשי מסד הנתונים לפני הייבוא. |
| אי-התאמה ב-LSN | סדר הייבוא של הגיבויים של יומן העסקאות שגוי או ששרשרת יומן העסקאות שבורה. מייבאים את הגיבויים של יומן העסקאות באותו סדר שבו הם מופיעים בטבלה של קבוצת הגיבויים. |
| StopAt מוקדם מדי | השגיאה הזו מציינת שהיומן הראשון בקובץ יומן העסקאות הוא אחרי חותמת הזמן StopAt. לדוגמה, אם היומן הראשון בקובץ יומן העסקאות הוא ב-2023-09-01T12:00:00 ובשדה StopAt יש את הערך 2023-09-01T11:00:00, אז Cloud SQL מחזיר את השגיאה הזו.חשוב לוודא שאתם משתמשים בחותמת הזמן הנכונה של StopAt ובקובץ יומן העסקאות הנכון. |
שרתים מקושרים
| שגיאה | פתרון בעיות |
|---|---|
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]. היומנים האלה מסוננים כי הם עלולים לגרום לבלבול.
|
| קשה לקרוא קובצי יומן. | אתם מעדיפים להציג את היומנים כקובץ 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 |
ניהול מופעים
| שגיאה | פתרון בעיות |
|---|---|
| אתם רוצים לדעת מה תופס מקום באחסון. | לדוגמה, נניח שאתם רואים שמסד הנתונים משתמש רק ב-3GB, אבל בנפח האחסון מוצג שימוש של 14GB. שטח שלא משמש את טבלאות מסד הנתונים משמש בדרך כלל ליומני עסקאות, לקבצים זמניים או ליומנים אחרים.
אפשר לראות פירוט של השימוש בדיסק של המכונה לפי סוג הנתונים באמצעות המדד דברים שכדאי לנסות:
|
| נפח האחסון הזמני הגדיל את נפח האחסון האוטומטי. | האחסון האוטומטי מופעל.
הפעלה מחדש מוחקת את הקבצים הזמניים אבל לא מפחיתה את נפח האחסון. רק תמיכת הלקוחות יכולה לאפס את גודל המכונה. |
| הנתונים נמחקים באופן אוטומטי. | סביר להניח שסקריפט פועל במקום כלשהו בסביבה שלכם.
חפשו ביומנים בסביבות זמן המחיקה ובדקו אם יש סקריפט זדוני שפועל ממרכז בקרה או מתהליך אוטומטי אחר. |
| אי אפשר למחוק את המכונה. | יכול להיות שתופיע הודעת השגיאה 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 כדי למצוא את השגיאה בפועל.
אם השגיאה היא |
| הדיסק מלא. | גודל הדיסק של המכונה הראשית יכול להתמלא במהלך יצירת הרפליקה. עורכים את המכונה הראשית כדי לשדרג אותה לגודל דיסק גדול יותר. |
| מופע הרפליקה משתמש ביותר מדי זיכרון. | הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמתבצעות לעיתים קרובות, מה שעלול לגרום לה להשתמש ביותר זיכרון מאשר המכונה הראשית.
מפעילים מחדש את מכונת הרפליקה כדי לפנות את שטח הזיכרון הזמני. |
| השכפול הופסק. | הגעתם למגבלת האחסון המקסימלית וההגדלה האוטומטית של נפח האחסון לא מופעלת.
עורכים את המכונה כדי להפעיל את |
| השהיית השכפול גבוהה באופן עקבי. | עומס הכתיבה גבוה מדי והרפליקה לא יכולה לטפל בו. השהיית שכפול מתרחשת כשה-SQL thread ברפליקה לא מצליח לעמוד בקצב של ה-IO thread. סוגים מסוימים של שאילתות או עומסי עבודה יכולים לגרום לעיכוב זמני או קבוע בשכפול של סכימה מסוימת. חלק מהסיבות הנפוצות לעיכוב ברפליקציה:
פתרונות אפשריים:
|
| יצירת הרפליקה נכשלת בגלל זמן קצוב לתפוגה. | טרנזקציות ארוכות שלא אושרו במכונה הראשית יכולות לגרום לכך שהיצירה של רפליקה לקריאה בלבד תיכשל.
יוצרים מחדש את הרפליקה אחרי שעוצרים את כל השאילתות שפועלות. |