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

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

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

  • אי אפשר לאמת את מסד הנתונים של ניהול הזהויות והרשאות הגישה (IAM) של אשכולות או מכונות יעד. ‫Database Migration Service מתחבר למסד הנתונים של היעד באמצעות אימות משתמש של מסד הנתונים. למידע נוסף על IAM, קראו את המאמר אימות IAM במסמכי התיעוד של Cloud SQL.

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

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

שיקולים לגבי מקביליות של העברת נתונים

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

  • לפני שמשתמשים במקביליות מקסימלית, חשוב לוודא שלמסד הנתונים של המקור יש מספיק מעבד (CPU), זיכרון ו-I/O.
  • כשמשתמשים בהתאמה של מקביליות ה-dump של הנתונים, צריך להגדיר ערכים גבוהים יותר ל-max_replication_slots, ל-max_wal_senders ול-max_worker_processes במסד הנתונים של המקור. לחישובים מפורטים של הפרמטרים, ראו הגדרת מסד הנתונים של המקור.
  • התוסף pglogical משכפל נתונים ברמת הטבלה במהלך ה-dump המלא הראשוני. טבלה אחת ללא מחיצות מוקצית למינוי אחד, ולא מפוצלת בין כמה מינויים מקבילים או שרשורי עבודה.
  • התוסף pglogical משכפל מחיצות עלים נפרדות כטבלאות נפרדות, ויכול להפיץ כמה מחיצות עלים בין מינויים מקבילים במהלך ה-dump המלא הראשוני. אי אפשר לפצל מחיצת עלה גדולה אחת בין כמה מינויים, והיא מועתקת על ידי שרשור אחד.
  • ‫Database Migration Service ממיין את הטבלאות לפי גודל ומוסיף מינויים מקבילים רק כשאפשר להקטין את נפח הנתונים הכולל של המינוי הגדול ביותר. שירות Database Migration Service יוצר עד 2 מינויים לכל מסד נתונים במקביליות אופטימלית, ועד 4 מינויים לכל מסד נתונים במקביליות מקסימלית. המינויים מוקצים לפי גודל מסד הנתונים מתוך מאגר יעד של 10 מינויים בכל מסדי הנתונים (עם מינוי אחד לפחות לכל מסד נתונים שהועבר). אם במסד נתונים יש גדלים של טבלאות עם הטיה משמעותית, Database Migration Service מקצה פחות מינויים מהמכסה המקסימלית. לדוגמה, אם מסד נתונים מכיל טבלה אחת בגודל 1TB וכמה טבלאות קטנות, Database Migration Service מבודד את הטבלה בגודל 1TB במינוי אחד ומקבץ את הטבלאות הקטנות יותר במינוי שני. בתרחיש הזה, Database Migration Service משתמש רק ב-2 מינויים, גם אם המקביליות מוגדרת ל-Maximum.
  • ‫Database Migration Service מקצה טבלאות בלי מפתחות ראשיים לקבוצות רפליקציה ייעודיות להוספה בלבד (אחת לכל מינוי מקביל). אפשר להפיץ כמה טבלאות בלי מפתחות ראשיים בין מינויים מקבילים, אבל במהלך ה-dump המלא הראשוני, כל טבלה מועתקת כסטרימינג של טבלה אחת במינוי אחד, ולא מפוצלת בין כמה שרשורים מקבילים.

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

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

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

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