פתרון בעיות

מריצים את הפקודה 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• הגודל של טווח כתובות ה-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 מפעיל מכונה להפחתת עומס כדי לבצע את הייצוא. לייצוא offloading יש כמה יתרונות, כולל שיפור הביצועים במופע המקור וביטול החסימה של פעולות אדמיניסטרטיביות בזמן שהייצוא פועל. אם משתמשים בהעברת עומס לייצוא, זמן האחזור הכולל עשוי להתארך בפרק הזמן שנדרש להפעלת מופע העברת העומס. בדרך כלל, בייצוא בגודל סביר, זמן האחזור לא משמעותי. עם זאת, אם הייצוא קטן מספיק, יכול להיות שתבחינו בעלייה בחביון.

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

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

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

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

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

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

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

יוצרים קובץ 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: יש מדיניות תואמת לחיבור שירות, אבל מופע השירות לא מוגדר לאפשר חיבור למופע הזה. כדי להגדיר מחדש את מדיניות חיבור השירות, אפשר לעיין במאמר עדכון מדיניות חיבור שירות.
• ‫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, צריך להשבית ואז להפעיל מחדש את Service Networking API. הפעולה הזו יוצרת את חשבון השירות שנדרש כדי להמשיך בתהליך.

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

עורכים את המופע כדי להפעיל את 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

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