נאמנות ההעברה

‫MySQL   |  PostgreSQL   |  PostgreSQL ל-AlloyDB

סקירה כללית

כשמעבירים את הסכימה, הנתונים והמטא-נתונים ממסד נתונים מקור למסד נתונים יעד, חשוב לוודא שכל המידע הזה מועבר בצורה מדויקת. Database Migration Service מספק דרך מדויקת להעברת אובייקטים של מסדי נתונים (כולל הסכימה, הנתונים והמטא-נתונים) ממסד נתונים אחד למסד נתונים אחר.

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

כל הרכיבים הבאים של נתונים, סכימה ומטא-נתונים מועברים כחלק מהעברת מסד הנתונים:

נתונים

• כל הטבלאות מכל מסדי הנתונים והסכימות, למעט הסכימות הבאות:

  • סכימת המידע information_schema
  • כל סכימה שמתחילה ב-pg (לדוגמה, pg_catalog)

  מידע נוסף על הסכימות האלה זמין במאמר מגבלות ידועות.

סכימה

• מתן שמות

• מפתח ראשי

• סוג נתונים

• מיקום סידורי

• ערך ברירת המחדל

• מאפיין המציין אם ערך יכול להיות ריק (nullability)

• מאפיינים עם ערך שגדל אוטומטית

• אינדקסים משניים

מטא-נתונים

• תהליכים מאוחסנים

• פונקציות

• טריגרים

• תצוגות

• אילוצים של מפתח זר

העברה רציפה

רק שינויים בשפת טיפול בנתונים (DML) מתעדכנים אוטומטית במהלך העברות רציפות. האחריות לניהול שינויים בשפת הגדרת נתונים (DDL) כדי שמסדי הנתונים של המקור והיעד יישארו תואמים מוטלת על המשתמש, ואפשר לעשות זאת בשתי דרכים:

1. הפסקת הכתיבה למקור והרצת פקודות DDL גם במקור וגם ביעד. לפני שמריצים פקודות DDL ביעד, צריך להעניק את ההרשאה cloudsqlexternalsync למשתמש Cloud SQL שמחיל את שינויי ה-DDL. כדי לאפשר שאילתות או שינוי של הנתונים, צריך להעניק את התפקיד cloudsqlexternalsync למשתמשי Cloud SQL הרלוונטיים.
2. שימוש ב-pglogical.replicate_ddl_command כדי לאפשר הפעלה של DDL במקור וביעד בנקודה עקבית. למשתמש שמריץ את הפקודה הזו צריך להיות אותו שם משתמש גם במקור וגם ביעד, והוא צריך להיות משתמש-על או הבעלים של הארטיפקט שמועבר (לדוגמה, הטבלה, הרצף, התצוגה או מסד הנתונים).

   הנה כמה דוגמאות לשימוש ב-pglogical.replicate_ddl_command.

   מחליפים את:

   • ‫[SCHEMA] בשם סכימת הטבלה שבה רוצים להשתמש
   • ‫[TABLE_NAME] עם שם הטבלה
   • ‫[NEW_NAME_FOR_TABLE] עם השם החדש של הטבלה כשמבצעים את פעולת השינוי

   הוספת עמודה לטבלת מסד נתונים עם מפתח ראשי

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] add column surname varchar(20)',
     '{default}'
   );

   הוספת עמודה לטבלת מסד נתונים ללא מפתח ראשי

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] add column surname varchar(20)',
     '{default_insert_only}'
   );

   שינוי השם של טבלת מסד נתונים עם מפתח ראשי

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
     '{default}'
   );

   שינוי השם של טבלת מסד נתונים ללא מפתח ראשי

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
     '{default_insert_only}'
   );

   יצירת טבלת מסד נתונים עם מפתח ראשי

   מריצים את הפקודות הבאות:

   1. select pglogical.replicate_ddl_command(
        command := 'CREATE TABLE [SCHEMA].[TABLE_NAME]
          (id INTEGER PRIMARY KEY, name VARCHAR);',
        replication_sets := ARRAY['default']
      );

   2. select pglogical.replication_set_add_table('default', '[SCHEMA].[TABLE_NAME]');

   יצירת טבלת מסד נתונים ללא מפתח ראשי

   מריצים את הפקודות הבאות:

   1. select pglogical.replicate_ddl_command(
        command := 'CREATE TABLE [SCHEMA].[TABLE_NAME]
         (id INTEGER PRIMARY KEY, name VARCHAR);',
        replication_sets := ARRAY['default_insert_only']
      );

   2. select pglogical.replication_set_add_table(
        'default_insert_only', '[SCHEMA].[TABLE_NAME]'
      );

מה לא מועבר

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

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

• אי אפשר לשכפל אובייקטים גדולים כי מתקן הפענוח הלוגי של PostgreSQL לא תומך בפענוח שינויים באובייקטים גדולים. בטבלאות עם סוג העמודה oid שמפנה לאובייקטים גדולים, השורות מסונכרנות ושורות חדשות משוכפלות. עם זאת, ניסיון לגשת לאובייקט הגדול במסד הנתונים של היעד (קריאה באמצעות lo_get, ייצוא באמצעות lo_export או בדיקת הקטלוג pg_largeobject עבור oid) נכשל, ומוצגת הודעה שהאובייקט הגדול לא קיים.

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

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

• המצבים SEQUENCE (לדוגמה, last_value) ביעד החדש עשויים להיות שונים מהמצבים במקור SEQUENCE.

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