פתרון בעיות

מריצים את הפקודה gcloud sql operations list כדי להציג רשימה של כל הפעולות עבור המכונה הנתונה של Cloud SQL.

בודקים ביומנים ומסננים לפי טקסט כדי למצוא את המשתמש. יכול להיות שתצטרכו להשתמש ביומני ביקורת כדי לגשת למידע פרטי. קובצי יומן רלוונטיים כוללים:

• cloudsql.googlapis.com/mysql-general.log
• cloudsql.googleapis.com/mysql.err
• אם Cloud Audit Logs מופעלות ויש לכם את ההרשאות הנדרשות לצפייה בהן, יכול להיות שגם cloudaudit.googleapis.com/activity יהיה זמין.

אם מוחקים מופע בלי ליצור גיבוי סופי של הנתונים, לא ניתן לשחזר את הנתונים. עם זאת, אם משחזרים את המכונה, Cloud SQL משחזר גם את הגיבויים. מידע נוסף על שחזור מופע שנמחק זמין במאמר שמירת גיבויים אחרי מחיקת מופע.

אם ביצעתם פעולת ייצוא, צריך ליצור מופע חדש ואז לבצע פעולת ייבוא כדי ליצור מחדש את מסד הנתונים. קובצי הייצוא נכתבים ב-Cloud Storage וקובצי הייבוא נקראים משם.

אם אתם ממש צריכים לבטל את הפעולה, אתם יכולים לבקש מ תמיכת הלקוחות לבטלforce restart את המופע.

יוצרים את משתמשי מסד הנתונים לפני שמשחזרים את קובץ ה-SQL.

כדי לשמור גיבויים ללא הגבלת זמן, אתם יכולים ליצור גיבוי לפי דרישה, כי הם לא נמחקים כמו גיבויים אוטומטיים. גיבויים לפי דרישה נשארים ללא הגבלת זמן. כלומר, הן נשארות עד שהן נמחקות או עד שהמופע שאליו הן שייכות נמחק. הגיבוי הזה לא נמחק אוטומטית, ולכן הוא יכול להשפיע על החיוב.

כדי לפתור את הבעיה, צריך להסיר תוויות מיותרות כך שיהיו למופע 50 תוויות או פחות שהוגדרו על ידי המשתמש. מידע נוסף מופיע במאמר בנושא הוספת תוויות למופעים.

• מגדירים את ערך הגיבוי הסופי כך שיתאים להגדרת הגיבוי הקיימת של המופע.
• כשמוחקים את המופע, משאירים את השדה של הגיבוי הסופי ריק. אם משאירים את השדה ריק, Cloud SQL משתמש בהגדרות הגיבוי הסופי שמוגדרות בהגדרות המכונה כדי ליצור גיבוי סופי ולהגדיר את תקופת השמירה שלו.

אתם מנסים לבטל פעולת ייבוא או ייצוא שהסתיימה, נכשלה או בוטלה. אם הפעולה פועלת, אפשר לבטל אותה.

‫Cloud SQL לא תומך בביטול הפעולה כי סוג הפעולה שלה שונה מ-IMPORT או מ-EXPORT.

בשלב הזה, אי אפשר לבטל את פעולת הייבוא או הייצוא ב-Cloud SQL. אפשר לנסות שוב בעוד כמה שניות. אם הבעיה נמשכת, אפשר לפנות אל Cloud de Confiance by S3NS התמיכה.

אם אפשר, מסירים את כל הערכים של Authorized Networks מהמכונה של Cloud SQL. אחרת, יוצרים העתק בלי ערכים של Authorized Networks.

ניסיתם להשתמש במסוף Cloud de Confiance כדי לשכפל מכונה עם כתובת IP פרטית, אבל לא ציינתם את טווח כתובות ה-IP שהוקצה שבו אתם רוצים להשתמש, והמכונה המקורית לא נוצרה עם הטווח שצוין. כתוצאה מכך, המכונה המשובטת נוצרת בטווח אקראי.

משתמשים ב-gcloud כדי לשכפל את המופע ומספקים ערך לפרמטר
--allocated-ip-range-name. מידע נוסף זמין במאמר בנושא שיבוט של מופע עם כתובת IP פרטית.

• חוסר יציבות ברשת.
• אין תגובה לפקודות TCP keep-alive (יכול להיות שהלקוח או השרת לא מגיבים, אולי בגלל עומס יתר)
• חלף הזמן הקצוב של החיבור למנוע מסד הנתונים והשרת מסיים את החיבור.

האפליקציות צריכות להיות עמידות בפני כשלים ברשת ולפעול לפי השיטות המומלצות, כמו איגום חיבורים וניסיון חוזר. רוב כלי הניהול של מאגרי החיבורים מזהים את השגיאות האלה כשהדבר אפשרי. אחרת, האפליקציה צריכה לנסות שוב או להיכשל בצורה מסודרת.

כדי לנסות שוב להתחבר, מומלץ להשתמש בשיטות הבאות:

1. השהיה מעריכית לפני ניסיון חוזר (exponential backoff). להגדיל את מרווח הזמן בין כל ניסיון חוזר, באופן מעריכי.
2. כדאי גם להוסיף השהיה אקראית.

שילוב של השיטות האלה עוזר לצמצם את ההגבלה.

ניסיונות החיבור נכשלים עם שגיאות כלליות של זמן קצוב לתפוגה או שגיאות חיבור ללא פרטי אבחון.

שלבים לפתרון בעיות:

1. מריצים בדיקת קישוריות של Network Intelligence Center בין לקוח המקור לבין כתובת ה-IP הפרטית של Cloud SQL ביציאת מסד הנתונים (3306 ל-MySQL,‏ 5432 ל-PostgreSQL או 1433 ל-SQL Server). הבדיקה עוקבת אחרי נתיב החבילה ומזהה אם תעבורת הנתונים נחסמת בגלל כללים של חומת האש, מסלולים חסרים או הגדרות שגויות של שיתוף פעולה בין רשתות.
2. מוודאים שסטטוס החיבור של VPC Network Peering הוא ACTIVE.
3. מוודאים שכללי חומת האש ברשת ה-VPC מאפשרים תעבורת נתונים נכנסת (ingress) ביציאת מסד הנתונים.
4. אם משתמשים בטווחים של כתובות שאינן RFC 1918, צריך לוודא שעדכנתם את הגדרות הקישור בין רשתות שכנות (peering) כדי לייצא נתיבי תת-רשת עם IP גלוי.

פרטים נוספים ופקודות אבחון של gcloud זמינים במאמר אבחון כשלים בחיבור לרשת VPC ולכתובות IP פרטיות.

• פעולות איטיות ליצירת התחברויות ל-Microsoft Entra ID
• אי אפשר ליצור כניסות ל-Microsoft Entra ID
• אי אפשר להתחבר למופע באמצעות אימות של Microsoft Entra ID

מידע נוסף על פתרון הבעיות האלה זמין במאמר בנושא פתרון בעיות בשילוב עם Microsoft Entra ID.

תוקף האישורים של הלקוח פג או שהנתיב לאישור לא נכון.

יוצרים מחדש את האישורים כדי ליצור אותם מחדש.

החיבור למכונה של Cloud SQL באמצעות אימות IAM למסד הנתונים נמשך כמה שניות או מסתיים בטיימאאוט, בעוד שאימות מובנה למסד הנתונים מתבצע כרגיל.

הגורם: המופע משתמש בסוג מכונה עם ליבה משותפת (db-f1-micro או db-g1-small). במסגרת ויסות המעבד, אימות מסד הנתונים של IAM נמשך זמן רב יותר מאימות סיסמה מובנה, כי הוא דורש יותר משאבי מחשוב.

הפתרון:

• כדי לעשות שימוש חוזר בחיבורים מאומתים, אפשר להשתמש באיגום חיבורים או להתחבר דרך שרת proxy ל-Cloud SQL Auth.
• להגדיל את הזמן הקצוב לתפוגה של חיבור הלקוח (לדוגמה, ל-10 עד 15 שניות).
• עורכים את המכונה כדי להשתמש בסוג מכונה עם ליבה ייעודית (כמו db-custom-* או db-n1-standard-*).

מידע נוסף זמין במאמר בנושא ביצועים במופעים עם ליבת מעבד משותפת.

בזמן שליחת הבקשה ליצירת המופע, לא היה מספיק קיבולת באזור שנבחר למשאבים המבוקשים או לסוג המכונה הווירטואלית. יכול להיות שבזמן הבקשה יש ביקוש גבוה בו-זמנית לפעולות באותו מיקום אזורי ספציפי.

כדי לפתור את הבעיה, נסו שוב ליצור את המכונה באזור אחר, או נסו שוב ליצור את המכונה באותו אזור שבו התקבלה השגיאה, בשעה אחרת ביום.

• הגודל של טווח כתובות ה-IP שהוקצה לחיבור הפרטי לשירות קטן מ-‎ /24.
• הגודל של טווח כתובות ה-IP שהוקצה לחיבור הפרטי לשירות קטן מדי ביחס למספר המכונות של Cloud SQL.
• הדרישה לגבי הגודל של טווח כתובות ה-IP שהוקצה תהיה גדולה יותר אם המכונות הווירטואליות נוצרות בכמה אזורים. הצגת גודל הטווח שהוקצה

כדי לפתור את הבעיה, אפשר להרחיב את טווח כתובות ה-IP הקיים שהוקצה או להקצות טווח כתובות IP נוסף לחיבור הפרטי לשירות. מידע נוסף זמין במאמר בנושא הקצאת טווח של כתובות IP.

אם השתמשתם בדגל --allocated-ip-range-name כשיצרתם את מופע Cloud SQL, תוכלו להרחיב רק את טווח כתובות ה-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
    

מפעילים את Service Networking API באמצעות הפקודה הבאה ומנסים שוב ליצור את מכונת Cloud SQL.

gcloud services enable servicenetworking.googleapis.com \
--project=PROJECT_ID
    

מוודאים ששמות ה-DNS שרוצים להוסיף לאישור השרת של מופע Cloud SQL עומדים בקריטריונים הבאים:

• הם לא כוללים תווים כלליים לחיפוש.
• הן לא מסתיימות בנקודות.
• הם עומדים במפרטים של RFC 1034.

שימוש בייצוא ל-CSV כדי לייצא רק את מה שצריך.

שימוש ב העברת עומס הייצוא. באופן כללי, בייצוא להפחתת עומס, במקום להפעיל ייצוא במכונת המקור, Cloud SQL מפעיל מכונה להפחתת עומס כדי לבצע את הייצוא. לייצוא לא פעיל יש כמה יתרונות, כולל שיפור הביצועים במופע המקור וביטול החסימה של פעולות ניהול בזמן שהייצוא פועל. אם משתמשים בהעברת עומס לייצוא, זמן האחזור הכולל עשוי להתארך בפרק הזמן שנדרש להפעלת מופע העברת העומס. בדרך כלל, בייצוא בגודל סביר, זמן האחזור לא משמעותי. עם זאת, אם הייצוא קטן מספיק, יכול להיות שתבחינו בעלייה בחביון.

אפשר ליצור מערכת ייצוא אוטומטית משלכם באמצעות Cloud de Confiance by S3NSמוצרים כמו Cloud Scheduler,‏ Pub/Sub ופונקציות Cloud Run, בדומה למאמר הזה בנושא גיבוי אוטומטי.

מוודאים שהמקור הראשי החיצוני זמין לחיבור. אפשר גם לשנות את הערכים של הדגלים net_read_timeout ו-net_write_timeout במופע המקור כדי שהשגיאה לא תופיע. מידע נוסף על הערכים המותרים של הדגלים האלה זמין במאמר בנושא הגדרת דגלים של מסד נתונים.

מידע נוסף על שימוש בדגלים של mysqldump לייבוא מנוהל של נתונים זמין במאמר .

פתרון: אל תריצו הצהרות DDL במסד הנתונים של המקור במהלך שלב ההעברה הראשוני. לפני שמריצים הצהרות DDL, מפעילים מחדש את ההעברה וממתינים לסיום שלב הגיבוי הראשוני.

אחת הסיבות האפשריות לכך היא שבמסד הנתונים של המקור הוגדרו דגלי שכפול שגורמים לכך שחלק מהשינויים במסד הנתונים או כולם לא משוכפלים.

מוודאים שדגלי השכפול, כמו binlog-do-db,‏ binlog-ignore-db,‏ replicate-do-db או replicate-ignore-db, לא מוגדרים בצורה שיוצרת התנגשות.

מריצים את הפקודה show master status במופע הראשי כדי לראות את ההגדרות הנוכחיות.

פעולות שכדאי לנסות:

• בודקים את מדדי השכפול של מופע הרפליקה בקטע Cloud Monitoring במסוף Cloud de Confiance .
• השגיאות משרשור הקלט/פלט או משרשור ה-SQL של MySQL מופיעות בCloud Logging בקובצי היומן mysql.err.
• השגיאה יכולה להופיע גם כשמתחברים למופע המשוכפל. מריצים את הפקודה SHOW REPLICA STATUS ובודקים את השדות הבאים בפלט:
  • Replica_IO_Running
  • Replica_SQL_Running
  • Last_IO_Error
  • Last_SQL_Error

אם מופיעה השגיאה Unknown database DATABASE_NAME on query. Error_code: MY-001049, המשמעות היא שהשכפול נכשל בגלל הצהרת SQL משוכפלת שמנסה להפנות למסד נתונים שלא נבחר להעברה. כדי לשחזר את השכפול, צריך לקבוע אם השגיאה מבוססת על הודעה שנובעת מ-DDL באחד מהאובייקטים הבאים:

• אירוע או פעולה שגרתית. אפשר להריץ את הפקודה CALL mysql.skipReplicationError() ברפליקה, וכך למנוע את השכפול של האירוע או השגרה ולהמשיך את השכפול.
• אילוץ או תצוגה של מפתח זר. אחרי שקובעים באיזה מסד נתונים נמצא האובייקט ששונה על ידי ההצהרה, יש שתי אפשרויות לשחזור. אפשר להסיר את מסד הנתונים ממסדי הנתונים שנבחרו להעברה, או להריץ את הפקודה CALL mysql.skipReplicationError() על העותק המשוכפל כדי להמשיך את השכפול תוך דילוג על האילוץ או על ההפצה של התצוגה לעותק המשוכפל.

מגדילים את גודל הדיסק של מכונת ההעתקה. אפשר להגדיל את גודל הדיסק באופן ידני או להפעיל הגדלה אוטומטית של נפח האחסון.

יוצרים קובץ dump חדש באמצעות הגדרות הדגל הנכונות, ומגדירים את העותק החיצוני באמצעות הקובץ הזה.

1. מתחברים ללקוח mysql דרך מכונה של Compute Engine.
2. מריצים את הפקודה mysqldump ומשתמשים בדגלים --master-data=1 ו---flush-privileges.

   חשוב: אל תכללו את הדגל --set-gtid-purged=OFF.

   מידע נוסף

3. מוודאים שקובץ ה-dump שנוצר מכיל את השורה SET @@GLOBAL.GTID_PURGED='...'.
4. מעלים את קובץ ה-dump לקטגוריה של Cloud Storage ו מגדירים את העותק המשוכפל באמצעות קובץ ה-dump.

עורכים את המכונה כדי לשדרג לגודל מכונה גדול יותר ולקבל יותר מעבדי CPU וזיכרון.

סוגרים פעולות שלא בשימוש. כדאי לבדוק את המעבד (CPU) ואת השימוש בזיכרון במכונת Cloud SQL כדי לוודא שיש מספיק משאבים זמינים. הדרך הטובה ביותר לוודא שמשימת הייבוא מקבלת את מרב המשאבים היא להפעיל מחדש את המכונה לפני התחלת הפעולה.

הפעלה מחדש:

• סגירת כל החיבורים.
• מפסיק את כל המשימות שעשויות לצרוך משאבים.

לפני הייבוא, צריךליצור את המשתמשים במסד הנתונים.

פעולות שכדאי לנסות:

מוסיפים את השורה הבאה בתחילת קובץ ה-dump:

SET FOREIGN_KEY_CHECKS=0;
  

בנוסף, מוסיפים את השורה הזו בסוף קובץ ה-dump:

SET FOREIGN_KEY_CHECKS=1;
  

ההגדרות האלה משביתות את בדיקות תקינות הנתונים בזמן פעולת הייבוא, ומפעילות אותן מחדש אחרי שהנתונים נטענים. הפעולה הזו לא משפיעה על שלמות הנתונים במסד הנתונים, כי הנתונים כבר אומתו במהלך יצירת קובץ dump.

לדוגמה, משתמש נמחק אבל אי אפשר לגלות מי עשה את זה. היומנים מראים שהפעולה התחילה, אבל לא מספקים מידע נוסף. כדי שפרטים מזהים מפורטים ופרטים אישיים מזהים (PII) כמו אלה יירשמו ביומן, צריך להפעיל את רישום הפעולות ביומן הביקורת.

מתחברים למסד הנתונים ומריצים את הפקודות האלה כדי לקבל פרטים על כל סוג:

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 \
"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
   

כדי לדעת מה הגודל של היומנים הכלליים, מתחברים למסד הנתונים ומריצים את השאילתה הבאה:

פעולות שכדאי לנסות:

• כדי לבדוק את נפח האחסון שתופסים יומנים בינאריים, משתמשים בפקודה הבאה בממשק שורת הפקודה של MySQL: SHOW BINARY LOGS;
• יכול להיות שגם טבלאות זמניות תופסות נפח אחסון משמעותי. כדי לבדוק את השימוש במקום האחסון הזמני, משתמשים בפקודה הבאה: SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G.
• הפקודה הבאה מאפשרת לבדוק את הגודל של יומן Redo: SHOW VARIABLES LIKE 'innodb_log_file%';
• אם general_log מופעל, אפשר לבדוק את הגודל שלו באמצעות הפקודה הבאה: SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) AS GB from mysql.general_log;
• במקרה הצורך, אפשר לקצץ את טבלאות היומן באמצעות ה-API. מידע נוסף זמין בדף העזרה בנושא instances.truncateLog.
• מידע נוסף על הגדרה ו קביעת תצורה של יומני שאילתות איטיות

מתחברים למסד הנתונים ומריצים את השאילתה הבאה:

SHOW PROCESSLIST.

יכול להיות שהפריט הראשון ברשימה הוא זה שמחזיק את הנעילה, והפריטים הבאים ממתינים לו.

SHOW INNODB STATUS השאילתה יכולה לעזור גם כן.

SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G

מתחברים למסד הנתונים ומריצים את השאילתה הבאה:

SELECT TABLE_SCHEMA, TABLE_NAME, sum(DATA_LENGTH+INDEX_LENGTH)/pow(1024,2) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA NOT IN ('PERFORMANCE_SCHEMA','INFORMATION_SCHEMA','SYS','MYSQL') GROUP BY TABLE_SCHEMA, TABLE_NAME;

מפצלים את המכונה אם אפשר. עדיף להשתמש בהרבה מכונות קטנות של Cloud SQL מאשר במכונה גדולה אחת.

הפעלה מחדש מוחקת את הקבצים הזמניים אבל לא מפחיתה את נפח האחסון. רק תמיכת לקוחות יכולה לאפס את גודל המופע.

בודקים ביומנים את השעה שבה בוצעה המחיקה, ומחפשים אם יש סקריפט לא מורשה שפועל מלוח בקרה או מתהליך אוטומטי אחר.

אלה כמה הסברים אפשריים:

• מתבצעת כרגע פעולה אחרת. פעולות ב-Cloud SQL לא מורצות בו-זמנית. ממתינים לסיום הפעולה השנייה.
• האזהרה INSTANCE_RISKY_FLAG_CONFIG מופעלת בכל פעם שמשתמשים בדגל beta אחד לפחות. מסירים את הגדרות הדגל של הסיכון ומפעילים מחדש את המופע

לצערנו, אי אפשר להקטין את הקובץ ibtmp1 בשום שיטה, אלא אם מפעילים מחדש את השירות.

אחת האפשרויות לצמצום הסיכון היא ליצור את הטבלה הזמנית באמצעות ROW_FORMAT=COMPRESSED, כדי שהיא תאוחסן במרחבי טבלאות של קובץ לכל טבלה בספריית הקבצים הזמניים. עם זאת, החיסרון הוא עלויות הביצועים שקשורות ליצירה ולהסרה של מרחב טבלאות של קובץ לכל טבלה עבור כל טבלה זמנית.

אם ייגמר נפח האחסון במופע שלכם, והאפשרות להגדלת נפח האחסון באופן אוטומטי לא מופעלת, המופע יעבור למצב אופליין. כדי למנוע את הבעיה הזו, אפשר לערוך את המופע כדי להפעיל הגדלה אוטומטית של נפח האחסון.

אם החיבורים נמשכים פחות מ-60 שניות, אפשר להימנע מרוב הכיבויים הלא תקינים, כולל חיבורים משורת הפקודה של מסד הנתונים. אם החיבורים האלה נשארים פתוחים במשך שעות או ימים, יכול להיות שהכיבוי לא יהיה תקין.

בודקים אילו אובייקטים תלויים במשתמש, ואז משמיטים או מקצים מחדש את האובייקטים האלה למשתמש אחר.

כדאי לעיין במיוחד ב טיפים כלליים לשיפור הביצועים.

אם פעולות ההוספה, העדכון או המחיקה במסד הנתונים מתבצעות לאט, כדאי לבצע את הפעולות הבאות:

• אם מפעילים את הדגל long_query_time, אפשר לבדוק את היומנים כדי לראות אילו שאילתות פועלות לאט. עוברים לדף Logs Explorer של הפרויקט ומריצים שאילתה כמו זו:

  resource.type="cloudsql_database"
  resource.labels.database_id="INSTANCE-ID"
  log_name="projects/PROJECT-ID/logs/cloudsql.googleapis.com%2Fmysql-slow.log"
        

  אפשר להוריד את היומנים בפורמט JSON או TEXT לעיבוד מקומי.

• בודקים את המיקומים של הכותב ומסד הנתונים. שליחת נתונים למרחק רב גורמת לזמן אחזור.
• בודקים את המיקום של הקורא ומסד הנתונים. זמן האחזור משפיע על ביצועי הקריאה אפילו יותר מאשר על ביצועי הכתיבה

כדי להקטין את זמן האחזור, מומלץ למקם את משאבי המקור והיעד באותו אזור.

יש עוד גורמים חוץ מעומס העבודה שיכולים להשפיע על השימוש בזיכרון, כמו מספר החיבורים הפעילים ותהליכי התקורה הפנימיים. השינויים האלה לא תמיד משתקפים בתרשימי המעקב.

מוודאים שיש מספיק תקורה למופע כדי להתחשב בעומס העבודה, בתוספת תקורה נוספת.

כדי לשמור את הנתונים, צריך לייצא אותם ל-Cloud Storage לפני ש מוחקים את המופע.

התפקיד Cloud SQL Admin כולל את ההרשאה למחוק את המופע. כדי למנוע מחיקה בטעות, כדאי להקצות את התפקיד הזה רק כשצריך.

יש דרכים אחרות להשיג את המטרה על ידי יצירת מופע חדש.

• אפשר לשכפל את המכונה שרוצים לשנות את השם שלה ולהגדיר שם חדש למכונה המשוכפלת. כך תוכלו ליצור את המופע החדש בלי לייבא נתונים באופן ידני. בדיוק כמו כשיוצרים מכונה חדשה, למכונה המשוכפלת יש כתובת IP חדשה.
• אפשר לייצא נתונים מהמכונה לקטגוריה של Cloud Storage, ליצור מכונה חדשה עם השם החדש שרוצים, ואז לייבא את הנתונים למכונה החדשה.

בשני המקרים, אפשר למחוק את המופע הישן אחרי שהפעולה מסתיימת. מומלץ לבחור באפשרות של שיבוט, כי היא לא משפיעה על הביצועים ולא מחייבת אתכם לבצע מחדש הגדרות של מופעים, כמו דגלים, סוג מכונה, גודל אחסון וזיכרון.

1. בודקים את הסטטוס של נקודת הקצה.

   gcloud

   כדי לבדוק את הסטטוס, משתמשים בפקודה
   gcloud compute forwarding-rules describe.

   gcloud compute forwarding-rules describe ENDPOINT_NAME \
   --project=PROJECT_ID \
   --region=REGION_NAME \
   | grep pscConnectionStatus

   מחליפים את הפרטים הבאים:

   • ‫ENDPOINT_NAME: השם של נקודת הקצה
   • ‫PROJECT_ID: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט שמכיל את נקודת הקצה
   • ‫REGION_NAME: שם האזור של נקודת הקצה

   REST

   לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

   • ‫PROJECT_ID: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט שמכיל את נקודת הקצה של Private Service Connect
   • ‫REGION_NAME: שם האזור
   • ‫ENDPOINT_NAME: השם של נקודת הקצה

   ה-method של ה-HTTP וכתובת ה-URL:

   GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME

   כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

   ‫Curl (Linux,‏ macOS או Cloud Shell)

   מריצים את הפקודה הבאה:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME"

   ‎PowerShell (Windows)

   מריצים את הפקודה הבאה:

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME" | Select-Object -Expand Content

   אתם אמורים לקבל תגובת JSON שדומה לזו:

   {
     "kind": "compute#forwardingRule",
     "id": "ENDPOINT_ID",
     "creationTimestamp": "2024-05-09T12:03:21.383-07:00",
     "name": "ENDPOINT_NAME",
     "region": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME",
     "IPAddress": "IP_ADDRESS",
     "target": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/serviceAttachments/SERVICE_ATTACHMENT_NAME",
     "selfLink": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME",
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
     "serviceDirectoryRegistrations": [
       {
         "namespace": "goog-psc-default"
       }
     ],
     "networkTier": "PREMIUM",
     "labelFingerprint": "LABEL_FINGERPRINT_ID",
     "fingerprint": "FINGERPRINT_ID",
     "pscConnectionId": "CONNECTION_ID",
     "pscConnectionStatus": "ACCEPTED",
     "allowPscGlobalAccess": true
   }
   

2. מוודאים שהסטטוס של נקודת הקצה הוא ACCEPTED. אם הסטטוס הוא PENDING, המשמעות היא שהמופע לא מאפשר את Cloud de Confiance הפרויקט שמכיל את נקודת הקצה. מוודאים שהפרויקט ברשת שבו נוצרה נקודת הקצה מותר. מידע נוסף מופיע במאמר עריכת מופע עם Private Service Connect מופעל.

הרשת הצרכנית לא מוגדרת בצורה נכונה, או שהיא לא מוגדרת בכלל, ולכן אין נקודת קצה שאפשר להתחבר אליה. כדי להתחבר לנקודת הקצה, צריך לבדוק את הסטטוס שלה ולתקן את השגיאה לפני שמנסים להתחבר שוב.
כדי לבדוק את הסטטוס של נקודת קצה, אפשר לעיין במאמר אחזור נקודת הקצה. הסטטוס של נקודת הקצה יכול להיות אחד מהבאים:

• ‫CONNECTION_POLICY_MISSING: אין מדיניות תואמת לחיבור שירות ברשת הצרכן. מדיניות חיבור לשירותים מוגדרת לפי רשת, לפי אזור. כדי להגדיר מחדש את הרשת, אפשר לעיין במאמר בנושא עדכון מדיניות חיבור לשירות.
• ‫CONSUMER_INSTANCE_PROJECT_NOT_ALLOWLISTED: יש מדיניות תואמת של חיבור שירות, אבל השדה היקף מופע השירות במדיניות לא מוגדר כך שיאפשר חיבור למופע הזה של Cloud SQL. מעדכנים את המדיניות כדי להגדיר את הערך של השדה היקף מופע השירות (--producer-instance-location) עם הפרויקט, התיקייה או הארגון שבהם נמצא מופע Cloud SQL. כדי להגדיר מחדש את המדיניות של חיבור השירות, אפשר לעיין במאמר בנושא עדכון המדיניות של חיבור השירות.
• ‫POLICY_LIMIT_REACHED: מדיניות החיבור לשירות הגיעה למגבלת נקודות הקצה. כדי לפתור את הבעיה, צריך להגדיל את מגבלת נקודות הקצה על ידי עדכון מדיניות חיבור השירות.

אין לכם את ההרשאות הנדרשות כדי ליצור מדיניות של חיבור שירות. כדי ליצור מדיניות לחיבור שירות, צריך את התפקיד Compute Network Admin IAM. מידע נוסף זמין במאמר בנושא תפקידים והרשאות.

אם הרשת החיצונית לא יכולה לקבל חיבורים מממשק Private Service Connect, יכול להיות שמדיניות החיבורים במחבר הרשת לא מוגדרת בצורה נכונה.

צריך להגדיר את הקבצים המצורפים לרשת כך שיקבלו את כל החיבורים באופן אוטומטי, או להגדיר אותם באופן ידני עם רשימה של חיבורים מאושרים. מידע נוסף זמין במאמר בנושא מדיניות חיבור.

כדי לאמת את החיבורים שאושרו בקובץ המצורף לרשת, משתמשים בפקודה הבאה:

      gcloud compute network-attachments describe default
      --region=REGION_ID

קודם כול, בודקים שהערך של הדגל max_connections גדול מהערך בשרת הראשי או שווה לו.

אם הדגל max_connections מוגדר בצורה מתאימה, בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.

אם השגיאה היא set Service Networking service account as servicenetworking.serviceAgent role on consumer project, אפשר ליצור באופן ידני את חשבון השירות הנדרש על ידי ביצוע ההוראות במאמר יצירה והקצאה של תפקידים לסוכני שירות.

מפעילים מחדש את מופע הרפליקה כדי לפנות את המקום הזמני בזיכרון.

עורכים את המופע כדי להפעיל את automatic storage increase.

• שאילתות איטיות בעותק המשוכפל. צריך לאתר את הבעיות ולתקן אותן.
• לכל הטבלאות צריך להיות מפתח ייחודי או מפתח ראשי. כל עדכון בטבלה כזו בלי מפתח ייחודי או ראשי גורם לסריקות מלאות של הטבלה ברפליקה.
• שאילתות כמו DELETE ... WHERE field < 50000000 גורמות לפיגור בשכפול עם שכפול מבוסס-שורות, כי מספר עצום של עדכונים מצטבר בעותק המשוכפל.

הנה כמה פתרונות אפשריים:

• הגדרת שכפול מקביל.
• מגדירים את הדגל innodb_flush_log_at_trx_commit בעותק לקריאה לערך 2.

  מידע נוסף על הדגל הזה זמין במאמר טיפים לעבודה עם דגלים.

• עורכים את המופע כדי להגדיל את הגודל של העותק המשוכפל.
• הפחתת העומס על מסד הנתונים.
• הפניית תנועת קריאה אל העותק לקריאה בלבד.
• יוצרים אינדקס לטבלאות.
• זיהוי ותיקון של שאילתות כתיבה איטיות.
• יוצרים את העותק המשוכפל מחדש.

כדי להימנע מעסקאות ארוכות, אפשר לנסות את הפתרונות הבאים:

• פיצול העסקה לכמה עסקאות קטנות
• פיצול שאילתת כתיבה גדולה אחת לקבוצות קטנות יותר
• כדאי להפריד שאילתות SELECT ארוכות מעסקאות שכוללות גם פקודות DML

במופע הראשי שבו מוצגת הודעת השגיאה, מגדירים את הדגלים של השכפול המקביל:

1. משנים את הדגלים binlog_transaction_dependency_tracking ו-transaction_write_set_extraction:
   • binlog_transaction_dependency_tracking=COMMIT_ORDER
   • transaction_write_set_extraction=OFF
2. מוסיפים את הדגל slave_pending_jobs_size_max:

   slave_pending_jobs_size_max=33554432

3. משנים את הדגל transaction_write_set_extraction:

   transaction_write_set_extraction=XXHASH64

4. משנים את הדגל binlog_transaction_dependency_tracking:

   binlog_transaction_dependency_tracking=WRITESET

אחרי שמפסיקים את כל השאילתות הפעילות, יוצרים מחדש את העותק.