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

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

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

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

נתונים

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

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

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

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

סכימה

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

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

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

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

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

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

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

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

מטא-נתונים

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

• פונקציות

• טריגרים

• תצוגות

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

העברה רציפה

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

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

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

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 PRIMARY KEY, name VARCHAR);',
  replication_sets := ARRAY['default_insert_only']
);
SELECT pglogical.replication_set_add_table('default_insert_only', '[SCHEMA].[TABLE_NAME]');

מה לא מועבר

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

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

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

• טבלאות בלי מפתחות ראשיים: השירות Database Migration Service מעביר את תמונת המצב הראשונית ומשכפל הצהרות 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 מתמשך. ערכי הרצף מסונכרנים במהלך שלב הקידום הסופי.

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

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

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

• התחלת העבודה עם העברות ל-Cloud SQL ל-PostgreSQL