הגדרת המקור

‫MySQL   |  PostgreSQL   |  PostgreSQL ל-AlloyDB

סקירה כללית

Database Migration Service תומך בהעברות רציפות ממסדי נתונים של מקור למסדי נתונים של יעד ב-AlloyDB.

מסדי הנתונים הנתמכים כמקורות ל-PostgreSQL כוללים:

• ‫Amazon RDS 9.6.10+, ‏ 10.5+, ‏ 11.1+, ‏ 12, ‏ 13, ‏ 14, ‏ 15, ‏ 16, ‏ 17
• ‫Amazon Aurora 10.11+, ‏ 11.6+, ‏ 12.4+, ‏ 13.3+, ‏ 14, ‏ 15, ‏ 16, ‏ 17
• ‫PostgreSQL בניהול עצמי (במקום או במכונה וירטואלית בענן שאתם שולטים בה באופן מלא) 9.4, ‏ 9.5, ‏ 9.6, ‏ 10, ‏ 11, ‏ 12, ‏ 13, ‏ 14, ‏ 15, ‏ 16, ‏ 17
• ‫Cloud SQL‏ 9.6, ‏ 10, ‏ 11, ‏ 12, ‏ 13, ‏ 14, ‏ 15, ‏ 16, ‏ 17

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

הגדרת מופע המקור

כדי להגדיר את מופע המקור:

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

הגדרת מסדי הנתונים של המקור

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

• למקורות מקומיים: מסדי נתונים של תבניות template0 ו-template1
• למקורות Amazon RDS: ‏ template0,‏ template1 וגם rdsadmin
• למקורות Cloud SQL: מסדי נתונים של תבניות template0 ו-template1

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

1. למקורות בגרסה 9.4 של PostgreSQL בלבד, מתקינים את התוספים הבאים pglogical בכל מסד נתונים במופע המקור:

   • CREATE EXTENSION IF NOT EXISTS pglogical;
   • CREATE EXTENSION IF NOT EXISTS pglogical_origin;

2. בכל הגרסאות האחרות, מתקינים רק את התוסף pglogical בכל מסד נתונים במופע המקור: CREATE EXTENSION IF NOT EXISTS pglogical.

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

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

4. לUSER שמשמש לחיבור למופע המקור (שיוגדר כמשתמש בדף פרופילים של חיבורים) צריכות להיות הרשאות מסוימות בכל אחד ממסדי הנתונים שהועברו, וגם במסד הנתונים postgres שמוגדר כברירת מחדל. אתם יכולים ליצור משתמש חדש או להשתמש במשתמש קיים. כדי להגדיר את ההרשאות האלה, מתחברים למופע ומריצים את הפקודות הבאות:

   1. GRANT USAGE on SCHEMA SCHEMA to USER בכל הסכימות (מלבד סכימת המידע וסכימות שמתחילות ב-pg_) בכל מסד נתונים שרוצים להעביר.
   2. GRANT USAGE on SCHEMA pglogical to PUBLIC; בכל מסד נתונים שרוצים להעביר.
   3. GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER בכל מסדי הנתונים כדי לקבל מידע על השכפול ממסדי הנתונים של המקור.
   4. GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER בכל הסכימות (מלבד סכימת המידע וסכימות שמתחילות ב-pg_) בכל מסד נתונים שרוצים להעביר.
   5. GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER בכל הסכימות (מלבד סכימת המידע וסכימות שמתחילות ב-pg_) בכל מסד נתונים שרוצים להעביר.
   6. אם המקור הוא Amazon RDS, מריצים את הפקודה הבאה:
      1. GRANT rds_replication to USER
   7. אם המקור שלכם הוא לא Amazon RDS, מריצים את הפקודה הבאה:
      1. ALTER USER USER with REPLICATION תפקיד

התקנת חבילת pglogical במופע המקור

בקטע הזה מוסבר איך להגדיר את חבילת pglogical, כולל הגדרות לפרמטרים max_replication_slots,‏ max_wal_senders ו-max_worker_processes. אפשר גם לקבל את הערכים הנכונים של הפרמטרים האלה על ידי הפעלת בדיקה של עבודת ההעברה כשיוצרים את עבודת ההעברה. במהלך הבדיקה הזו, Database Migration Service יכול לאמת את ההגדרות ולהציע את הערכים הנכונים.

‫PostgreSQL מקומי או בניהול עצמי

1. מתקינים את חבילת pglogical בשרת.
2. מתחברים למופע ומגדירים את הפרמטרים הבאים לפי הצורך:

   • shared_preload_libraries חייב לכלול את pglogical.

     כדי להגדיר את הפרמטר הזה, מריצים את הפקודה ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]';.

     כדי לקבל את הספריות הקיימות של המכונה, מריצים את הפקודה show shared_preload_libraries.

   • מגדירים את wal_level להיות logical.

     כדי להגדיר את הפרמטר הזה, מריצים את הפקודה ALTER SYSTEM SET wal_level = 'logical';.

   • מגדירים את wal_sender_timeout להיות 0.

     כדי להגדיר את הפרמטר הזה, מריצים את הפקודה ALTER SYSTEM SET wal_sender_timeout = 0;, כאשר 0 משבית את מנגנון הזמן הקצוב לתפוגה שמשמש לסיום חיבורי שכפול לא פעילים.

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

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

     לדוגמה, אם יש 5 מסדי נתונים במופע המקור ויש 2 משימות העברה שנוצרו עבור המקור, מספר משבצות השכפול צריך להיות לפחות 5 * 2 = 10, ועוד מספר משבצות השכפול שכבר נמצאות בשימוש. אם אתם מתכננים להשתמש בהגדרות מקביליות של העברת נתונים מותאמת, חשוב להגדיל את מספר משבצות השכפול ו להריץ את בדיקת משימת ההעברה כשיוצרים את משימת ההעברה כדי לוודא שההגדרה נכונה.

     כדי להגדיר את הפרמטר הזה, מריצים את הפקודה ALTER SYSTEM SET max_replication_slots = #;, כאשר # מייצג את המספר המקסימלי של משבצות שכפול.

   • הערך של max_wal_senders צריך להיות לפחות כמו הערך של max_replication_slots, ועוד מספר השולחים שכבר נמצאים בשימוש במופע.

     לדוגמה, אם הפרמטר max_replication_slots מוגדר ל-10, ואתם כבר משתמשים ב-2 תהליכי שליחה, מספר התהליכים של WAL sender שפועלים בו-זמנית יהיה 10 + 2 = 12. אם אתם מתכננים להשתמש בהגדרות מקביליות של יצוא נתונים מותאמים, חשוב להגדיל את מספר השולחים ו להריץ את הבדיקה של משימת ההעברה כשיוצרים את משימת ההעברה כדי לוודא שההגדרה נכונה.

     כדי להגדיר את הפרמטר הזה, מריצים את הפקודה ALTER SYSTEM SET max_wal_senders = #;, כאשר # מייצג את מספר התהליכים של WAL sender שפועלים בו-זמנית.

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

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

     כדי להגדיר את הפרמטר הזה, מריצים את הפקודה ALTER SYSTEM SET max_worker_processes = #;, כאשר # מייצג את מספר מסדי הנתונים שיועברו.

   הפרמטרים שאתם מגדירים בשלב הזה חלים על שרת מסד נתונים של PostgreSQL שפועל. אפשר גם להוסיף את שורות הקוד הבאות לקובץ postgresql.conf כדי שהשינויים האלה יישמרו:

   • shared_preload_libraries = 'pglogical';
   • wal_level = 'logical';
   • wal_sender_timeout = 0;
   • max_replication_slots = #;
   • max_wal_senders = #;
   • max_worker_processes = #;
3. כדי להחיל את שינויי ההגדרה, מפעילים מחדש את מופע המקור.

‫Amazon RDS PostgreSQL

1. מתקינים את התוסף pglogical במסד הנתונים של המקור. מידע נוסף זמין במאמר Using PostgreSQL extensions with Amazon RDS for PostgreSQL במסמכי העזרה של Amazon RDS.

2. מגדירים את מופע המקור באמצעות קבוצות פרמטרים.

   • יצירת קבוצת פרמטרים חדשה. בקבוצת הפרמטרים:
   • מוודאים שהפרמטר shared_preload_libraries כולל את הערך pglogical.
   • מגדירים את הפרמטר rds.logical_replication לערך 1. הפעולה הזו תפעיל יומני WAL ברמה הלוגית.
   • מגדירים את הפרמטר wal_sender_timeout ל-0. הפעולה הזו תשבית את מנגנון פסק הזמן שמשמש להפסקת חיבורי שכפול לא פעילים.

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

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

     לדוגמה, אם יש 5 מסדי נתונים במופע המקור וייווצרו 2 משימות העברה למקור, מספר משבצות השכפול צריך להיות לפחות 5 * 2 = 10, ועוד מספר משבצות השכפול שכבר נמצאות בשימוש. אם אתם מתכננים להשתמש בהגדרות מקביליות של העברת נתונים מותאמת, הקפידו להגדיל את מספר משבצות השכפול ו להריץ את בדיקת משימת ההעברה כשאתם יוצרים את משימת ההעברה כדי לוודא שההגדרה שלכם נכונה.

     ערך ברירת המחדל של הפרמטר הזה הוא 10.

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

     לדוגמה, אם הפרמטר max_replication_slots מוגדר ל-10, ואתם כבר משתמשים ב-2 שולחים, מספר התהליכים של WAL sender שפועלים בו-זמנית יהיה 10 + 2 = 12. אם אתם מתכננים להשתמש בהגדרות מקביליות של העברת נתונים מותאמות, הקפידו להגדיל את מספר השולחים ו להריץ את הבדיקה של משימת ההעברה כשאתם יוצרים את משימת ההעברה כדי לוודא שההגדרה נכונה.

     ערך ברירת המחדל של הפרמטר הזה הוא 10.

   • מגדירים את פרמטר המקור max_worker_processes למספר זהה לפחות למספר מסדי הנתונים שהשירות להעברת נתונים יעביר (כלומר כל מסדי הנתונים שמתחת למופע המקור), ועוד המספר max_worker_processes שכבר נמצא בשימוש במופע. אם אתם מתכננים להשתמש בהגדרות מקביליות של יצוא נתונים מותאמים, הקפידו להגדיל את מספר תהליכי העובד ו להריץ את הבדיקה של משימת ההעברה כשאתם יוצרים את משימת ההעברה כדי לוודא שההגדרה שלכם נכונה.

     ערך ברירת המחדל של הפרמטר הזה הוא 8.

3. מצרפים את קבוצת הפרמטרים למופע. אם יוצרים מופע חדש, האפשרות הזו נמצאת בקטע Additional Configuration (הגדרה נוספת). אחרת, משנים את המופע כדי לצרף את קבוצת הפרמטרים.

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

הערה: התוסף pglogical יכול לרשום פרטי כניסה בטקסט רגיל במופע המקור. ההתנהגות הזו נגרמת בגלל התוסף עצמו, והיא לא קשורה ל-Database Migration Service או ל-Cloud SQL.

Cloud SQL ל-PostgreSQL

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

כל ההגדרות בקטע הזה מוגדרות באמצעות דגלים ב-Cloud SQL. כדי להפעיל דגלים ב-Cloud SQL, ראו הגדרת דגלים במסדי נתונים.

1. מגדירים את הדגלים cloudsql.logical_decoding ו-cloudsql.enable_pglogical לערך on.

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

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

   לדוגמה, אם יש 5 מסדי נתונים במופע המקור וייווצרו 2 משימות העברה למקור, מספר משבצות השכפול צריך להיות לפחות 5 * 2 = 10, ועוד מספר משבצות השכפול שכבר נמצאות בשימוש. אם אתם מתכננים להשתמש בהגדרות מקביליות של העברת נתונים מותאמת, חשוב להגדיל את מספר משבצות השכפול ו להריץ את בדיקת משימת ההעברה כשיוצרים את משימת ההעברה כדי לוודא שההגדרה נכונה.

   ערך ברירת המחדל של הדגל הזה הוא 10.

3. מגדירים את הדגל max_wal_senders לערך שהוא לפחות כמו max_replication_slots, ועוד מספר השולחים שכבר נמצאים בשימוש במופע.

   לדוגמה, אם הדגל max_replication_slots מוגדר ל-10, ואתם כבר משתמשים ב-2 שולחים, מספר התהליכים של WAL sender שפועלים בו-זמנית יהיה 10 + 2 = 12. אם אתם מתכננים להשתמש בהגדרות מקביליות של יצוא נתונים מותאמים, חשוב להגדיל את מספר השולחים ו להריץ את הבדיקה של משימת ההעברה כשיוצרים את משימת ההעברה כדי לוודא שההגדרה נכונה.

   ערך ברירת המחדל של הדגל הזה הוא 10.

4. מגדירים את דגל המקור max_worker_processes למספר שהוא לפחות מספר מסדי הנתונים שיועברו באמצעות שירות העברת הנתונים (כלומר כל מסדי הנתונים שמתחת למופע המקור), ועוד המספר max_worker_processes שכבר בשימוש במופע. אם אתם מתכננים להשתמש בהגדרות מקביליות של יצוא נתונים מותאם, צריך להביא בחשבון שני תהליכי עובד נוספים לכל חיבור (עד 20 עובדים לכל היותר).

   ערך ברירת המחדל של הדגל הזה הוא 8.

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

הפעלת מעקב אחר עיכוב בשכפול ב-PostgreSQL בגרסה נמוכה מ-9.6

אם אתם מעבירים נתונים מגרסת PostgreSQL קודמת לגרסה 9.6, מדד השהיית השכפול לא זמין כברירת מחדל. יש שלוש חלופות שיאפשרו לכם לעקוב אחרי המדד הזה כדי להבטיח זמן השבתה מינימלי כשמקדמים את מסד הנתונים:

1. אפשרות 1: מאפשרים ל-Database Migration Service לעקוב אחרי השהיית השכפול על ידי מתן גישה לשאילתה ספציפית. משתמשים עם הרשאה SUPERUSER יכולים לבצע את הפעולות הבאות:

   1. מגדירים את הפונקציה הבאה כדי לאפשר ל-Database Migration Service לבצע שאילתה לגבי העיכוב בשכפול.

      CREATE OR REPLACE FUNCTION pg_stat_replication_user()
      RETURNS TABLE (
      pid               integer                  ,
      usesysid          oid                      ,
      username          name                    ,
      application_name  text                     ,
      client_addr       inet                     ,
      client_hostname   text                     ,
      client_port       integer                  ,
      backend_start     timestamp with time zone ,
      backend_xmin      xid                      ,
      state             text                     ,
      sent_location     pg_lsn                   ,
      write_location    pg_lsn                   ,
      flush_location    pg_lsn                   ,
      replay_location   pg_lsn                   ,
      sync_priority     integer                  ,
      sync_state        text
      )
      LANGUAGE SQL
      SECURITY DEFINER
      AS $$
       SELECT *
       FROM pg_catalog.pg_stat_replication;
      $$;
      

   2. כדי להעניק את ההרשאה EXECUTE ל-USER, מריצים את הפקודות הבאות:

      1. REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
      2. GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};

2. אפשרות 2: מעניקים את ההרשאה SUPERUSER ישירות למשתמש USER שמשמש לחיבור למופע המקור. כך שירות העברת הנתונים יוכל לקרוא ישירות את עיכוב השכפול.

3. אפשרות 3: מעקב אחרי עיכוב השכפול בנפרד באמצעות השאילתה הבאה:

   בגרסאות של PostgreSQL מגרסה 9.6 ומטה, מריצים את הפקודה הזו בתור superuser.

       SELECT current_timestamp, application_name,
       pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.sent_location) AS sent_location_lag,
       pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.write_location) AS write_location_lag,
       pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.flush_location) AS flush_location_lag,
       pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.replay_location) AS replay_location_lag
       FROM pg_stat_replication
       WHERE application_name like 'cloudsql%';
     

   אם תבחרו באפשרות הזו, מדד השהיית השכפול לא יוצג בתרשימים או בתגובות של API ב-Database Migration Service.