בעיות מוכרות

בדף הזה מפורטות בעיות מוכרות ב-Cloud SQL ל-PostgreSQL, וגם דרכים להימנע מהן או לפתור אותן.

בעיות בחיבור למופע

• אישורי SSL/TLS שפג תוקפם

  אם המופע מוגדר לשימוש ב-SSL, עוברים אל הדף Cloud SQL Instances במסוף Cloud de Confiance ופותחים את המופע. פותחים את הדף Connections (חיבורים), בוחרים בכרטיסייה Security (אבטחה) ומוודאים שאישור השרת תקף. אם התוקף שלו פג, צריך להוסיף אישור חדש ולעבור אליו.

• גרסת שרת proxy ל-Cloud SQL Auth

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

• אין הרשאה להתחבר

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

• אי אפשר ליצור מכונה של Cloud SQL

  אם מופיעה הודעת השגיאה Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID], נסו ליצור שוב את מכונת Cloud SQL.

• הפעולות הבאות פועלות רק עם משתמש ברירת המחדל (postgres): gcloud sql connect --user

  אם תנסו להתחבר באמצעות הפקודה הזו עם משתמש אחר, תוצג הודעת השגיאה FATAL: database 'user' does not exist. הפתרון העקיף הוא להתחבר באמצעות משתמש ברירת המחדל (postgres) ואז להשתמש בפקודה "\c" psql כדי להתחבר מחדש בתור המשתמש השונה.

• חיבורים ל-PostgreSQL נתקעים כשמופעל אימות של שרת proxy למסד נתונים ב-IAM.

  כשמפעילים את שרת ה-proxy ל-Cloud SQL Auth באמצעות שקעי TCP ועם הדגל -enable_iam_login, לקוח PostgreSQL נתקע במהלך חיבור TCP. פתרון עקיף אחד הוא להשתמש ב-sslmode=disable במחרוזת החיבור של PostgreSQL. לדוגמה:

  psql "host=127.0.0.1 dbname=postgres user=me@google.com sslmode=disable"

  פתרון עקיף נוסף הוא הפעלת שרת proxy ל-Cloud SQL Auth באמצעות שקעי Unix. הפעולה הזו משביתה את הצפנת ה-SSL של PostgreSQL ומאפשרת לשרת ה-proxy ל-Cloud SQL Auth לבצע את הצפנת ה-SSL במקום זאת.

בעיות אדמיניסטרטיביות

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

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

בעיות בייבוא ובייצוא של נתונים

• אם במכונת Cloud SQL שלכם נעשה שימוש ב-PostgreSQL 17, אבל במסדי הנתונים נעשה שימוש ב-PostgreSQL 16 ובגרסאות קודמות, לא תוכלו להשתמש ב-Cloud SQL כדי לייבא את מסדי הנתונים האלה למכונה. כדי לעשות את זה, צריך להשתמש בDatabase Migration Service.

• אם משתמשים ב-Database Migration Service כדי לייבא מסד נתונים של PostgreSQL 17 אל Cloud SQL, הוא מיובא כמסד נתונים של PostgreSQL 16.

• ב-PostgreSQL מגרסה 15 ואילך, אם מסד הנתונים של היעד נוצר מ-template0, יכול להיות שייבוא הנתונים ייכשל ותוצג הודעת השגיאה permission denied for schema public. כדי לפתור את הבעיה, צריך להריץ את פקודת ה-SQL‏ GRANT ALL ON SCHEMA public TO cloudsqlsuperuser כדי להעניק הרשאות סכמה ציבוריות למשתמש cloudsqlsuperuser.

• ייצוא של הרבה אובייקטים גדולים גורם למופע להפסיק להגיב

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

• ‫Cloud SQL לא תומך במרחבי טבלאות מותאמים אישית, אבל הוא כן תומך בהעברת נתונים ממרחבי טבלאות מותאמים אישית למרחב הטבלאות שמוגדר כברירת מחדל, pg_default, במופע היעד. לדוגמה, אם יש לכם מרחב טבלאות בשם dbspace שנמצא במיקום /home/data, אחרי ההעברה כל הנתונים ב-dbspace יועברו אל pg_default. אבל Cloud SQL לא ייצור במקרה הזה tablespace בשם dbspace בדיסק.

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

• ב-Cloud Storage יש תמיכה ב גודל אובייקט יחיד של עד חמישה טביבייט (5 TiB). מכיוון ש-Cloud SQL דוחס את הנתונים לפני ההעלאה ל-Cloud Storage, פעולת ייצוא נכשלת רק אם הגודל הדחוס של קובץ הייצוא חורג מ-5 TiB.

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

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

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

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

יומני עסקאות וגידול בנפח האחסון בדיסק

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

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

בעיות שקשורות ל-Cloud Monitoring או ל-Cloud Logging

מקרים שבהם שמות האזורים הבאים מוצגים בצורה שגויה בהקשרים מסוימים:

• הערך us-central1 מוצג כ-us-central
• הערך europe-west1 מוצג כ-europe
• הערך asia-east1 מוצג כ-asia

הבעיה הזו מתרחשת בהקשרים הבאים:

• התראות ב-Cloud Monitoring
• Metrics Explorer
• Cloud Logging

כדי לפתור את הבעיה ב-Alerting ב-Cloud Monitoring וב-Metrics Explorer, אפשר להשתמש בתוויות של מטא-נתונים של משאבים. במקום תווית המשאב המפוקח cloudsql_database ‏[region], צריך להשתמש בתווית המטא-נתונים של המערכת region.

בעיה שקשורה למחיקה של מסד נתונים של PostgreSQL

כשמוחקים מסד נתונים שנוצר במסוף Cloud de Confiance באמצעות לקוח psql, יכול להיות שתופיע השגיאה הבאה:

ERROR: must be owner of database [DATABASE_NAME]

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

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

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

SELECT d.datname as Name,
pg_catalog.pg_get_userbyid(d.datdba) as Owner
FROM pg_catalog.pg_database d
WHERE d.datname = 'DATABASE_NAME';

מחליפים את מה שכתוב בשדות הבאים:

• ‫DATABASE_NAME: השם של מסד הנתונים שרוצים למצוא לגביו מידע על הבעלים.

אם הבעלים של מסד הנתונים הוא cloudsqlsuperuser, צריך להשתמש במסוףCloud de Confiance כדי למחוק את מסד הנתונים. אם הבעלים של מסד הנתונים הוא משתמש מסד נתונים של לקוח psql, צריך להתחבר כבעלים של מסד הנתונים ולהריץ את הפקודה DROP DATABASE.