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

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

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

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

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

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

  • מגבלות לגבי אובייקטים:

    • טבלאות זרות לא משוכפלות על ידי שכפול לוגי.
    • הטבלאות UNLOGGED ו-TEMPORARY לא משוכפלות ואי אפשר לשכפל אותן.
    • סוג הנתונים Large Object (oid שמפנה אל pg_largeobject) לא נתמך בפענוח לוגי של PostgreSQL.
    • ‫Database Migration Service לא מעביר נתונים מתצוגות מוחשיות, אלא רק את הסכימה של התצוגה. כדי לאכלס את התצוגות במסד הנתונים של היעד, מריצים את הפקודה REFRESH MATERIALIZED VIEW view_name;.
    • יכול להיות שהמצבים של SEQUENCE (לדוגמה, last_value) ביעד יהיו שונים מהמקור במהלך CDC מתמשך. ערכי הרצף מסונכרנים במהלך שלב הקידום הסופי.

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

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

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

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

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

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

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

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

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

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

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

  • מסדי נתונים שמועברים לא מוגנים מפני כתיבה במהלך ההעברה: AlloyDB ל-PostgreSQL לא מריץ את המכונה של היעד במצב קריאה בלבד במהלך ההעברה. אפשר להתחבר לאשכול היעד כדי ליצור ולנהל משתמשים במסד הנתונים או כדי להחיל את השינויים הנדרשים בסכימה (DDL), אבל אסור לבצע פעולות כתיבה (כמו INSERT,‏ UPDATE או DELETE) במסדי נתונים או בטבלאות שמועברים. כתיבה לנתונים שמועברים יכולה לגרום ל התנגשויות בשכפול או לכשלים בהעברה.

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

  • מרחבי טבלאות בהתאמה אישית ממופים למרחב הטבלאות שמוגדר כברירת מחדל, pg_default, ב-AlloyDB ל-PostgreSQL.

  • שיטת הקישוריות של ממשקי Private Service Connect נתמכת רק בהעברה לאשכולות יעד קיימים. אם אתם רוצים להשתמש בקישוריות IP פרטית ולהעביר לאשכול יעד חדש בהעברה רגילה, השתמשו בקישור בין רשתות VPC שכנות (peering).

  • אין תמיכה באימות מסד נתונים של ניהול זהויות והרשאות גישה (IAM) לאשכולות יעד. ‫Database Migration Service מתחבר למסד הנתונים של היעד באמצעות אימות משתמש של מסד הנתונים. מידע נוסף על IAM זמין במאמר ניהול אימות IAM במסמכי התיעוד של AlloyDB ל-PostgreSQL.

פונקציות של מגדיר אבטחה

פונקציות שמוגדרות באמצעות SECURITY DEFINER פועלות עם ההרשאות של המשתמש שבבעלותו הפונקציה, ולא של המשתמש שמפעיל אותה.

במהלך העברה רציפה ל-AlloyDB ל-PostgreSQL, רוטינות שמוגדרות באמצעות SECURITY DEFINER הופכות להיות בבעלות משתמש שירות ההעברה הפנימי alloydbexternalsync במכונה הראשית של היעד. מכיוון של-alloydbexternalsync יש הרשאות אדמין מורחבות, כולל התפקידים alloydbsuperuser ו-alloydbreplica, כל משתמש שמורשה להפעיל את הפונקציות האלה מפעיל אותן עם זכויות מלאות של alloydbsuperuser. המצב הזה יוצר סיכון לא מכוון של הרחבת הרשאות.

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

REVOKE EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) TO "AUTHORIZED_USER";

התאמה של השוואה ומיקום גיאוגרפי

‫AlloyDB ל-PostgreSQL משתמש כברירת מחדל בלוקאלים C.UTF-8 ו-en_US.utf8 שסופקו על ידי libc. כל שאר הלוקאלים ב-AlloyDB ל-PostgreSQL משתמשים ב-International Components for Unicode (ICU) collations.

אם מסד הנתונים של המקור משתמש בברירת מחדל של השוואה שמבוססת על לוקאל אחר של libc, ברירת המחדל הזו לא מועברת באופן אוטומטי. כדי לוודא שהמיון יהיה עקבי בשאילתות שמשתמשות ב-ORDER BY, יכול להיות שתצטרכו לעדכן את הטבלאות עם השוואות מפורשות של ICU אחרי ההעברה. מידע נוסף זמין במאמר הגדרות מקומיות נתמכות לנתונים מיובאים במסמכי התיעוד של AlloyDB ל-PostgreSQL.

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

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

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

  • יש תמיכה בהעברה לאשכולות עם מכונות של מאגר קריאה. מידע נוסף על אשכולות ומכונות של AlloyDB ל-PostgreSQL זמין בסקירה הכללית על AlloyDB ל-PostgreSQL.

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

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

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

מכסות

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

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

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

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

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

המאמרים הבאים