מגבלות ידועות

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

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

  • התוסף pglogical לא תומך ברפליקציה של עמודות שנוצרו ב-PostgreSQL 12 ואילך.

  • שינויים במבני הטבלאות (DDL) לא משוכפלים באמצעות פקודות DDL רגילות, אלא רק באמצעות פקודות שמבוצעות באמצעות התוסף pglogical שמשמש לשכפול. זה כולל שינויים בenum סוגים.

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

  • בטבלאות שאין בהן מפתחות ראשיים, אפשר להשתמש ב-Database Migration Service כדי להעביר את תמונת המצב הראשונית ואת הצהרות INSERT במהלך שלב סימון הנתונים שהשתנו (CDC). העברת הצהרות UPDATE ו-DELETE שונה עבור:

    • העברות רגילות: הצהרות UPDATE ו-DELETE לא מועברות לטבלאות בלי מפתחות ראשיים. לפני ההעברה, צריך להוסיף מפתחות ראשיים לעמודות, או להעביר הצהרות UPDATE ו-DELETE באופן ידני.
    • העברות בהפעלה מהירה: בהעברות בהפעלה מהירה, לא נדרשים מפתחות ראשיים כדי לשכפל פעולות UPDATE ו-DELETE אם מגדירים את זהות הרפליקה ל-INDEX או ל-FULL. הגדרת REPLICA IDENTITY FULL מגדילה את נפח יומן הכתיבה מראש (WAL) ואת התקורה של המשאבים. מומלץ להוסיף מפתח ראשי כשאפשר. מידע נוסף זמין במאמרי עזרה זהות רפליקה של PostgreSQL וב מדריך להעברת נתונים (מיגרציה) למתחילים.

  • ‫Database Migration Service לא מעביר נתונים מתצוגות מהותיות, אלא רק את הסכימה של התצוגה. כדי לאכלס את התצוגות במסד הנתונים של היעד, מריצים את הפקודה: REFRESH MATERIALIZED VIEW view_name.

  • יכול להיות שהמצבים של SEQUENCE (לדוגמה, last_value) ביעד יהיו שונים מהמקור במהלך CDC מתמשך. ערכי הרצף מסונכרנים במהלך שלב הקידום הסופי.

  • הטבלאות UNLOGGED ו-TEMPORARY לא משוכפלות ואי אפשר לשכפל אותן.

  • סוג הנתונים Large Object (oid שמפנה אל pg_largeobject) לא נתמך בפענוח הלוגי של PostgreSQL.

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

  • התוסף pg_cron (או כל משימת cron שמוגדרת בתוסף) לא מועבר על ידי Database Migration Service, אבל נתמך ביעדים של Cloud SQL ל-PostgreSQL. אם אתם משתמשים ב-pg_cron במסדי הנתונים של המקור, אחרי שההעברה מסתיימת אתם צריכים להתקין מחדש את התוסף ולהגדיר את משימות ה-cron במכונה של היעד.

  • ב-Database Migration Service אין תמיכה בהעברה מרפליקות לקריאה בלבד שנמצאות במצב שחזור.

  • ‫Database Migration Service לא תומך במקורות של Amazon RDS שבהם מופעלת חבילת התוספים של AWS SCT.

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

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

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

  • אתם יכולים לבחור מסדי נתונים ספציפיים כשאתם מבצעים העברה באמצעות Database Migration Service. כל הטבלאות והסכימות ממסדי הנתונים שנבחרו מועברות, חוץ מ:

    • סכימת המידע (information_schema).
    • כל הסכימות שמתחילות ב-pg_ (לדוגמה, pg_catalog, ‏ pg_toast, ‏ pgtemp*). לרשימה המלאה של קטלוגי PostgreSQL שמתחילים ב-pg_, עיינו בקטע קטלוגי מערכת של PostgreSQL במסמכי התיעוד של PostgreSQL.
    • פרטי כניסה ותפקידים של משתמשים.

  • אם מסדי הנתונים המוצפנים דורשים מפתחות הצפנה בניהול הלקוח (CMEK) כדי לפענח את הנתונים, ול-Database Migration Service אין גישה למפתחות, אי אפשר להעביר את מסדי הנתונים. עם זאת, אפשר להעביר נתונים שמוצפנים באמצעות התוסף pgcrypto, כי Cloud SQL תומך ב-pgcrypto. בנוסף, אפשר להשתמש ב-Database Migration Service כדי להעביר מסדי נתונים מוצפנים של Amazon Aurora או Amazon RDS, כי AWS מטפלת בפענוח באופן שקוף. מידע נוסף זמין במאמרים הצפנת משאבים של Amazon Aurora והצפנת משאבים של Amazon RDS.

  • התנהגות תפעולית של מסד הנתונים של היעד במהלך ההעברה:

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

    • הימנעו מפעולות כתיבה בנתונים שמועברים: אל תבצעו פעולות כתיבה (כמו INSERT,‏ UPDATE,‏ DELETE או שינויים בסכימת DDL) בטבלאות או במסדי נתונים שמשתתפים בהעברה. ביצוע פעולות כתיבה בנתונים שמועברים עלול לגרום להתנגשויות בשכפול עם הזרם הנכנס של סימון נתונים שהשתנו (CDC).

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

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

  • ההתנהגות של הטריגר תלויה בהגדרות שלו. כברירת מחדל, טריגרים לא מופעלים ברפליקה במהלך הרפליקציה, אלא אם הם מוגדרים עם ALTER EVENT TRIGGER או ALTER TABLE ... ENABLE ALWAYS TRIGGER.

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

  • ב-Cloud SQL אין תמיכה במרחבי טבלאות בהתאמה אישית. כל האובייקטים בתוך מרחבי טבלאות בהתאמה אישית מועברים למרחב הטבלאות שמוגדר כברירת מחדל ב-Cloud SQL, שהוא pg_default.

  • שיטת הקישוריות של ממשקי Private Service Connect נתמכת רק בהעברה למכונות יעד קיימות. אם אתם רוצים להשתמש בקישור דרך IP פרטי ולהעביר למכונה חדשה ביעד, השתמשו ב-VPC Peering.

מגבלות על העברות למופעי יעד קיימים

  • הורדה בדרגה של מכונת היעד בהעברות רגילות: בהעברות רגילות למכונות קיימות של Cloud SQL, שירות Database Migration Service מוריד בדרגה את המכונה העצמאית כדי להגדיר אותה כרפליקה חיצונית של מסד הנתונים במקור.
    • הורדת המכונה בדרגה לא מעבירה את מנוע PostgreSQL למצב קריאה בלבד, אבל צריך להימנע מפעולות כתיבה בטבלאות שמועברות כדי למנוע התנגשויות ברפליקציה.
    • הורדה בדרגה של המכונה משעה את הגיבויים האוטומטיים ואת שחזור המערכת מנקודה מסוימת בזמן (PITR), ומונעת הוספה של רפליקות לקריאה בלבד ב-Cloud SQL עד לקידום.
    • כדי לאשר את ההורדה בדרגה, כשיוצרים את משימת ההעברה במסוף Google Cloud צריך להזין את המזהה של מכונת היעד (או להריץ את הפקודה gcloud database-migration migration-jobs demote-destination).
    • בהעברות מהירות נעשה שימוש ברפליקציה לוגית של PostgreSQL pgnative, ואין צורך להוריד בדרגה את מכונת היעד.
  • מופע היעד הקיים יכול להכיל רק מסדי נתונים של המערכת שמוגדרים כברירת מחדל באופן אוטומטי כשיוצרים את מופע היעד. אין תמיכה בהעברה למופעי יעד קיימים שמכילים נתוני משתמשים.

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

  • אפשר להגדיר רק משימת העברה אחת לכל מופע יעד.
  • אפשר להעביר רק למכונות Cloud SQL עצמאיות. אי אפשר להעביר ל רפליקות של שרתים חיצוניים.
  • אחרי שמקדמים מכונה, צריך להפעיל את שחזור המערכת מנקודה מסוימת בזמן (PITR).
  • אם למכונה יש הגדרות גיבוי בהתאמה אישית (לדוגמה, מיקום גיבוי בהתאמה אישית), צריך לשחזר את הגדרות הגיבוי שוב אחרי הקידום. במהלך תהליך הקידום, Cloud SQL מאפס את הגדרות הגיבוי לערכי ברירת המחדל שלהן.
  • למשתמשי Terraform: ‏Database Migration Service משנה את הגדרות הגיבוי והשחזור של מכונת היעד. יכול להיות שההגדרות של מכונת היעד יהיו שונות מההגדרות של Terraform ששימשו להקצאה. אם נתקלתם בבעיה הזו, תוכלו להיעזר בהנחיות שבמאמר אבחון בעיות.

מכסות

  • בכל זמן נתון יכולים להיות עד 2,000 פרופילי חיבור ו-1,000 משימות העברה. כדי לפנות מקום, מחקו משימות העברה ופרופילי חיבור שלא בשימוש.

תאימות של גרסאות התוספים של PostgreSQL במהלך שדרוגים של גרסאות ראשיות

כשמעבירים לגרסה ראשית גבוהה יותר של PostgreSQL, שירות Database Migration Service משתמש בכלי pg_restore, שמתקין את גרסת ברירת המחדל של התוסף של הגרסה הראשית של PostgreSQL ביעד. אי אפשר לציין גרסת תוסף מדויקת לכלי pg_restore.

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

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