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

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

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

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

נתונים

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

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

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

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

סכימה

• מתן שמות לאובייקטים

• מקש במקלדת הראשית

• סוגי הנתונים

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

• ערכי ברירת מחדל

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

• מאפייני זהות ומאפיינים סידוריים

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

מטא-נתונים

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

• פונקציות

• טריגרים

• תצוגות

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

העברה רציפה

שינויים בשפת טיפול בנתונים (DML) (כמו פעולות INSERT, UPDATE ו-DELETE בטבלאות עם מפתח ראשי או זהות רפליקה) משוכפלים באופן אוטומטי במהלך העברות רציפות.

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

1. הפעלה ידנית של DDL: מפסיקים את הכתיבה למסד הנתונים של המקור, מריצים את פקודות ה-DDL במסד הנתונים של המקור ומריצים פקודות DDL תואמות במסד הנתונים של היעד. לפני שמריצים פקודות DDL ביעד, צריך לתת את התפקיד alloydbexternalsync למשתמש ב-AlloyDB ל-PostgreSQL שמחיל את השינויים.

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

בכרטיסיות הבאות מופיעות פקודות SQL לדוגמה לפעולות DDL נפוצות באמצעות pglogical.replicate_ddl_command:

טבלאות עם מפתחות ראשיים

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

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] RENAME TO [NEW_NAME_FOR_TABLE]',
  '{default}'
);

יצירת טבלה עם מפתח ראשי

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

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

טבלאות בלי מפתחות ראשיים

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

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_insert_only}'
);

יצירת טבלה בלי מפתח ראשי

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

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

מה לא מועבר

• משתמשים והרשאות: פרטי הכניסה והתפקידים של המשתמשים לא מועברים. בפעם הראשונה שמתחברים לאשכול יעד חדש, משתמשים בחשבון postgres. מכיוון ש-AlloyDB ל-PostgreSQL הוא שירות מנוהל, משתמשי PostgreSQL לא יכולים לקבל הרשאות SUPERUSER. מידע נוסף זמין במאמר ניהול משתמשים במסד הנתונים במסמכי התיעוד של AlloyDB ל-PostgreSQL.

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

• אובייקטים גדולים: אובייקטים גדולים של PostgreSQL (סוג נתונים oid שמפנה אל pg_largeobject) לא משוכפלים על ידי פענוח לוגי.

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

  • העברות רגילות: בהעברות רגילות, לטבלאות צריכים להיות מפתחות ראשיים כדי לשכפל הצהרות UPDATE ו-DELETE.

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

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

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

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

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

• לפרטים מלאים על המגבלות, ראו מגבלות ידועות.

• איך מתחילים העברות ל-AlloyDB ל-PostgreSQL