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

בדף הזה מוסבר איך להגדיר את מכונות מסד הנתונים במקור להעברות סטנדרטיות והומוגניות של PostgreSQL. אם אתם רוצים להשתמש בהעברות מהירות, פעלו לפי ההוראות במדריך שימוש בהעברות מהירות. העברות ב-Quick Start מספקות תהליך העברה פשוט שמשתמש ברפליקציה של pgnative ובקישוריות מיוחדת שמבוססת על ממשקי Private Service Connect. מידע נוסף מופיע במאמר מידע על העברות בהפעלה מהירה במסמכי התיעוד הראשיים של Database Migration Service.

הדף הזה כולל קטעים לכל מקור נתמך:

הגדרת מקור PostgreSQL בניהול עצמי

כדי להגדיר מכונה של מקור PostgreSQL בניהול עצמי (מקומית או מתארחת במכונה וירטואלית של Compute Engine) לתהליך ההעברה:

  1. במקורות PostgreSQL בניהול עצמי, Database Migration Service מעביר את כל מסדי הנתונים במכונה של המקור, חוץ ממסדי הנתונים של התבניות template0 ו-template1.
  2. מוודאים שמכונת המקור כוללת את מסד הנתונים postgres שמוגדר כברירת מחדל. אם מסד הנתונים הזה לא קיים, צריך ליצור אותו לפני שמגדירים את ההעברה.
  3. מגדירים את האימות של לקוח הרשת בקובץ pg_hba.conf. מוסיפים רשומות שמאפשרות חיבורי רפליקציה וגישה למסד הנתונים מכתובת ה-IP היוצאת של Cloud SQL, מטווח ה-CIDR של ה-VPC או מהיעד המבוצר (bastion host) של ה-SSH ההפוך: 
    # Allow replication connections
host  replication  MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5
# Allow database access
host  all          MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5

    טוענים מחדש את ההגדרות של PostgreSQL כדי להחיל את הכללים של pg_hba.conf:

    SELECT pg_reload_conf();
  4. בודקים את תוספי PostgreSQL שמותקנים במסדי הנתונים של המקור. ‫Database Migration Service לא מעביר תוספים שלא נתמכים ב-Cloud SQL. מוודאים שהאובייקטים של מסד הנתונים במקור והשאילתות של האפליקציה לא מפנים לתוספים שלא נתמכים. לפני שממשיכים, צריך להסיר תוספים והפניות לא נתמכים ממסדי הנתונים של המקור.

    התוסף pg_cron לא מועבר אוטומטית על ידי Database Migration Service, אבל הוא נתמך ביעדים של Cloud SQL ל-PostgreSQL. אם אתם משתמשים ב-pg_cron במסד הנתונים של המקור, צריך להתקין אותו מחדש ולהגדיר אותו במכונה של היעד אחרי שמקדמים את ההעברה.

  5. יוצרים חשבון משתמש ייעודי להעברה במכונה של המקור, ונותנים לו את ההרשאות הנדרשות:
    1. מתחברים למכונה של המקור באמצעות חשבון אדמין, יוצרים את המשתמש ומקצים את תפקיד הרפליקציה: 
      CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
ALTER USER MIGRATION_USER_ACCOUNT_NAME WITH REPLICATION;
    2. נותנים לחשבון המשתמש להעברה את ההרשאות הנדרשות למסד הנתונים postgres שמוגדר כברירת מחדל, וגם לכל מסד נתונים שרוצים להעביר. מריצים את הפקודות הבאות בכל מסד נתונים לכל סכימה (חוץ מסכימת המידע וסכימות שמתחילות ב-pg_): 
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. מתקינים את התוסף pglogical בכל מסד נתונים שרוצים להעביר, חוץ מ-template0 ומ-template1:
    • ב-PostgreSQL גרסה 9.4: מריצים את הפקודה הבאה: 
      CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
    • ב-PostgreSQL בגרסה 9.5 ואילך: מריצים את הפקודה הבאה: 
      CREATE EXTENSION IF NOT EXISTS pglogical;
  7. מוודאים שבטבלאות יש מפתחות ראשיים. בהעברות רציפות, כדי לשכפל פעולות UPDATE ו-DELETE במהלך שלב סימון הנתונים שהשתנו (CDC), צריך להגדיר מפתחות ראשיים בטבלאות של השכפול הלוגי של PostgreSQL:
    • טבלאות עם מפתח ראשי משכפלות את כל הפעולות של INSERT,‏ UPDATE ו-DELETE באופן אוטומטי.
    • בטבלאות שאין בהן מפתחות ראשיים, Database Migration Service תומך בהעברה רק של תמונת המצב הראשונית והצהרות INSERT הבאות במהלך שלב ה-CDC. צריך להעביר הצהרות UPDATE ו-DELETE באופן ידני.

      מומלץ להוסיף מפתחות ראשיים לטבלאות שאין בהן מפתחות כאלה לפני שמתחילים את ההעברה. במאמר ניפוי באגים וכלים אחרים מוסבר איך ליצור שאילתה כדי להציג רשימה של טבלאות במסד נתונים של PostgreSQL בלי מפתחות ראשיים, או איך להעביר באופן ידני פעולות של UPDATE ו-DELETE.

      לחלופין, אתם יכולים לנסות להשתמש בתהליך ההעברה המהיר: תרחיש העברה פשוט שבו אפשר להשתמש ב-REPLICA IDENTITY כדי להעביר טבלאות בלי מפתחות ראשיים. מידע נוסף זמין במדריך שימוש בהעברות מהירות.

  8. מקורות שפועלים בגרסה 9.5 ומטה של PostgreSQL: מדד העיכוב ברפליקציה לא זמין למכונות מקור שפועלות בגרסאות של PostgreSQL שקודמות ל-9.6. אם אתם רוצים להשתמש במדד הזה כדי לעקוב אחרי התקדמות ההעברה, קראו את המאמר הפעלת עיכוב בשכפול.
  9. מתקינים את החבילה pglogical ומגדירים את הפרמטרים של WAL ושל הרפליקציה בשרת PostgreSQL:
    1. מתקינים את החבילה pglogical במערכת ההפעלה של המארח של שרת מסד הנתונים. כדי לקבל חבילות והוראות התקנה להפצה שלכם, עיינו במאגר pglogical ב-GitHub.
    2. מתחברים למכונה של PostgreSQL באמצעות חשבון אדמין ומגדירים את הפרמטרים הבאים:
      1. מגדירים את shared_preload_libraries כך שיכלול את 'pglogical': 
        ALTER SYSTEM SET shared_preload_libraries = 'pglogical';
      2. מגדירים את wal_level לערך 'logical': 
        ALTER SYSTEM SET wal_level = 'logical';

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

      3. מגדירים את wal_sender_timeout לערך 0: 
        ALTER SYSTEM SET wal_sender_timeout = 0;

        הערך 0 משבית את מנגנון הזמן הקצוב לתפוגה שמסיים חיבורי רפליקציה לא פעילים. wal_sender_timeout

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

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

        ALTER SYSTEM SET max_replication_slots = MAX_REPLICATION_SLOTS;

        ערך ברירת המחדל של הפרמטר הזה הוא 10. למידע נוסף, ראו max_replication_slots.

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

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

        ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;

        ערך ברירת המחדל של הפרמטר הזה הוא 10. למידע נוסף, ראו max_wal_senders.

      6. מגדירים את max_worker_processes לפחות למספר מסדי הנתונים שרוצים להעביר, בתוספת תהליכי ה-worker הקיימים במכונה. אם אתם מתכננים להשתמש בהגדרות מותאמות של מקביליות ב-data dump, קחו בחשבון שני תהליכי עבודה נוספים לכל חיבור (עד למקסימום של 20 תהליכי עבודה): 
        ALTER SYSTEM SET max_worker_processes = MAX_WORKER_PROCESSES;

        ערך ברירת המחדל של הפרמטר הזה הוא 8. למידע נוסף, ראו max_worker_processes.

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

הגדרת מקור Amazon RDS ל-PostgreSQL

כדי להגדיר מכונה של Amazon RDS ל-PostgreSQL כמקור לתהליך ההעברה:

  1. במקורות של Amazon RDS ל-PostgreSQL, שירות Database Migration Service מעביר את כל מסדי הנתונים במכונה של המקור, חוץ ממסדי הנתונים של התבניות template0, template1 וממסד הנתונים הפנימי של AWS‏ rdsadmin.
  2. מוודאים שמכונת המקור כוללת את מסד הנתונים postgres שמוגדר כברירת מחדל. אם מסד הנתונים הזה לא קיים, צריך ליצור אותו לפני שמגדירים את ההעברה.
  3. מגדירים את הכללים לתעבורת נתונים נכנסת בקבוצת האבטחה של Amazon RDS VPC. מאפשרים חיבורי TCP נכנסים ביציאה 5432 מכתובת ה-IP היוצאת של Cloud SQL, מטווח ה-CIDR של ה-VPC או מהמכונה הווירטואלית של היעד המבוצר (bastion host) של ה-SSH ההפוך.
  4. בודקים את תוספי PostgreSQL שמותקנים במסדי הנתונים של המקור. ‫Database Migration Service לא מעביר תוספים שלא נתמכים ב-Cloud SQL. מוודאים שהאובייקטים של מסד הנתונים במקור והשאילתות של האפליקציה לא מפנים לתוספים שלא נתמכים. לפני שממשיכים, צריך להסיר ממסדי הנתונים של המקור את התוספים וההפניות שלא נתמכים.

    התוסף pg_cron לא מועבר אוטומטית על ידי Database Migration Service, אבל הוא נתמך ביעדים של Cloud SQL ל-PostgreSQL. אם אתם משתמשים ב-pg_cron במסד הנתונים של המקור, צריך להתקין אותו מחדש ולהגדיר אותו במכונה של היעד אחרי שמקדמים את ההעברה.

  5. יוצרים חשבון משתמש ייעודי להעברה במכונה של המקור, ונותנים לו את ההרשאות הנדרשות:
    1. מתחברים למכונה של המקור באמצעות חשבון אדמין, יוצרים את המשתמש ונותנים לו את התפקיד rds_replication שמנוהל על ידי AWS: 
      CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
    2. נותנים לחשבון המשתמש להעברה את ההרשאות הנדרשות למסד הנתונים postgres שמוגדר כברירת מחדל, וגם לכל מסד נתונים שרוצים להעביר. מריצים את הפקודות הבאות בכל מסד נתונים לכל סכימה (חוץ מסכימת המידע וסכימות שמתחילות ב-pg_): 
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. מתקינים את התוסף pglogical בכל מסד נתונים שרוצים להעביר, חוץ מ-template0,‏ template1 ו-rdsadmin:
    • ב-PostgreSQL גרסה 9.4: מריצים את הפקודה הבאה: 
      CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
    • ב-PostgreSQL בגרסה 9.5 ואילך: מריצים את הפקודה הבאה: 
      CREATE EXTENSION IF NOT EXISTS pglogical;

    לפרטים נוספים על הדרישות, קראו את המאמר שימוש בתוספים של PostgreSQL עם Amazon RDS ל-PostgreSQL במסמכי התיעוד של AWS.

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

      מומלץ להוסיף מפתחות ראשיים לטבלאות שאין בהן מפתחות כאלה לפני שמתחילים את ההעברה. במאמר ניפוי באגים וכלים אחרים מוסבר איך ליצור שאילתה כדי להציג רשימה של טבלאות במסד נתונים של PostgreSQL בלי מפתחות ראשיים, או איך להעביר באופן ידני פעולות של UPDATE ו-DELETE.

      לחלופין, אתם יכולים לנסות להשתמש בתהליך ההעברה המהיר: תרחיש העברה פשוט שבו אפשר להשתמש ב-REPLICA IDENTITY כדי להעביר טבלאות בלי מפתחות ראשיים. מידע נוסף זמין במדריך שימוש בהעברות מהירות.

  8. מקורות שפועלים בגרסה 9.5 ומטה של PostgreSQL: מדד העיכוב ברפליקציה לא זמין למכונות מקור שפועלות בגרסאות של PostgreSQL שקודמות ל-9.6. אם אתם רוצים להשתמש במדד הזה כדי לעקוב אחרי התקדמות ההעברה, קראו את המאמר הפעלת עיכוב ברפליקציה.
  9. מגדירים קבוצת פרמטרים מותאמת אישית של מסד נתונים ומצרפים אותה למכונה:
    1. יוצרים קבוצת פרמטרים בהתאמה אישית (ראו עבודה עם קבוצות פרמטרים של מסדי נתונים במסמכי התיעוד של AWS) ומגדירים את הפרמטרים הבאים:
      1. מגדירים את shared_preload_libraries כך שיכלול את pglogical.
      2. מגדירים את rds.logical_replication להיות 1. הפרמטר הזה מפעיל רישום לוג לוגי של WAL ב-Amazon RDS. רפליקציה לוגית של Amazon RDS ל-PostgreSQL
      3. מגדירים את wal_sender_timeout להיות 0. הערך 0 משבית את מנגנון הזמן הקצוב לתפוגה שמסיים חיבורי רפליקציה לא פעילים.
      4. מגדירים את max_replication_slots לפחות למספר מסדי הנתונים שרוצים להעביר כפול מספר משימות ההעברה, בתוספת רזרבות לסנכרון הטבלאות:

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

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

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

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

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

      6. מגדירים את max_worker_processes לפחות למספר מסדי הנתונים שרוצים להעביר, בתוספת תהליכי ה-worker הקיימים במכונה. אם אתם מתכננים להשתמש בהגדרות מותאמות של מקביליות ב-data dump, קחו בחשבון שני תהליכי עבודה נוספים לכל חיבור (עד למקסימום של 20 תהליכי עבודה):

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

    2. מצרפים את קבוצת הפרמטרים למכונה של מסד הנתונים ב-RDS. אם יוצרים מכונה חדשה, האפשרות הזו נמצאת בקטע Additional Configuration. אחרת, משנים את המכונה כדי לצרף את קבוצת הפרמטרים.
  10. מפעילים מחדש את המכונה של Amazon RDS כדי שהשינויים בקבוצת הפרמטרים ייכנסו לתוקף.

הגדרת מקור Amazon Aurora for PostgreSQL

כדי להגדיר אשכול מקור של Amazon Aurora PostgreSQL לתהליך ההעברה:

  1. במקורות של Amazon Aurora for PostgreSQL, ‏Database Migration Service מעביר את כל מסדי הנתונים באשכול המקור, חוץ ממסדי הנתונים של התבניות template0, template1 וממסד הנתונים הפנימי של AWS‏ rdsadmin.
  2. מוודאים שאשכול המקור כולל את מסד הנתונים postgres שמוגדר כברירת מחדל. אם מסד הנתונים הזה לא קיים, צריך ליצור אותו לפני שמגדירים את ההעברה.
  3. מגדירים את הכללים לתעבורת נתונים נכנסת בקבוצת האבטחה של ה-VPC באשכול Amazon Aurora. מאפשרים חיבורי TCP נכנסים ביציאה 5432 מכתובת ה-IP היוצאת של Cloud SQL, מטווח ה-CIDR של ה-VPC או מהמכונה הווירטואלית של היעד המבוצר (bastion host) של ה-SSH ההפוך.
  4. בודקים את תוספי PostgreSQL שמותקנים במסדי הנתונים של המקור. ‫Database Migration Service לא מעביר תוספים שלא נתמכים ב-Cloud SQL. מוודאים שהאובייקטים של מסד הנתונים במקור והשאילתות של האפליקציה לא מפנים לתוספים שלא נתמכים. לפני שממשיכים, צריך להסיר ממסדי הנתונים של המקור את התוספים וההפניות שלא נתמכים.

    התוסף pg_cron לא מועבר אוטומטית על ידי Database Migration Service, אבל הוא נתמך ביעדים של Cloud SQL ל-PostgreSQL. אם אתם משתמשים ב-pg_cron במסד הנתונים של המקור, צריך להתקין אותו מחדש ולהגדיר אותו במכונה של היעד אחרי שמקדמים את ההעברה.

  5. יוצרים חשבון משתמש ייעודי להעברה באשכול המקור ונותנים לו את ההרשאות הנדרשות:
    1. מתחברים לאשכול המקור באמצעות חשבון אדמין, יוצרים את המשתמש ומקצים את התפקיד rds_replication שמנוהל על ידי AWS: 
      CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
    2. נותנים לחשבון המשתמש להעברה את ההרשאות הנדרשות למסד הנתונים postgres שמוגדר כברירת מחדל, וגם לכל מסד נתונים שרוצים להעביר. מריצים את הפקודות הבאות בכל מסד נתונים לכל סכימה (חוץ מסכימת המידע וסכימות שמתחילות ב-pg_): 
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. מתקינים את התוסף pglogical בכל מסד נתונים שרוצים להעביר, חוץ מ-template0,‏ template1 ו-rdsadmin: 
    CREATE EXTENSION IF NOT EXISTS pglogical;
  7. מוודאים שבטבלאות יש מפתחות ראשיים. בהעברות רציפות, כדי לשכפל פעולות UPDATE ו-DELETE במהלך שלב סימון הנתונים שהשתנו (CDC), צריך להגדיר מפתחות ראשיים בטבלאות של השכפול הלוגי של PostgreSQL:
    • טבלאות עם מפתח ראשי משכפלות את כל הפעולות של INSERT,‏ UPDATE ו-DELETE באופן אוטומטי.
    • בטבלאות שאין בהן מפתחות ראשיים, Database Migration Service תומך בהעברה רק של תמונת המצב הראשונית והצהרות INSERT הבאות במהלך שלב ה-CDC. צריך להעביר הצהרות UPDATE ו-DELETE באופן ידני.

      מומלץ להוסיף מפתחות ראשיים לטבלאות שאין בהן מפתחות כאלה לפני שמתחילים את ההעברה. במאמר ניפוי באגים וכלים אחרים מוסבר איך ליצור שאילתה כדי להציג רשימה של טבלאות במסד נתונים של PostgreSQL בלי מפתחות ראשיים, או איך להעביר באופן ידני פעולות של UPDATE ו-DELETE.

      לחלופין, אתם יכולים לנסות להשתמש בתהליך ההעברה המהיר: תרחיש העברה פשוט שבו אפשר להשתמש ב-REPLICA IDENTITY כדי להעביר טבלאות בלי מפתחות ראשיים. מידע נוסף זמין במדריך שימוש בהעברות מהירות.

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

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

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

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

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

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

      6. מגדירים את max_worker_processes לפחות למספר מסדי הנתונים שרוצים להעביר, בתוספת תהליכי ה-worker הקיימים במכונה. אם אתם מתכננים להשתמש בהגדרות מותאמות של מקביליות ב-data dump, קחו בחשבון שני תהליכי עבודה נוספים לכל חיבור (עד למקסימום של 20 תהליכי עבודה):

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

    2. מצרפים את קבוצת הפרמטרים של אשכול מסד הנתונים לאשכול מסד הנתונים של Aurora.
  9. מפעילים מחדש את אשכול מסד הנתונים של Amazon Aurora כדי שהשינויים בקבוצת הפרמטרים ייכנסו לתוקף.

הגדרת מקור של Microsoft Azure Database for PostgreSQL Flexible Server

כדי להגדיר מכונה של מקור Microsoft Azure Database for PostgreSQL Flexible Server לתהליך ההעברה:

  1. במקורות מסוג Microsoft Azure Database for PostgreSQL Flexible Server, שירות Database Migration Service מעביר את כל מסדי הנתונים במכונה של המקור, חוץ ממסדי הנתונים של המערכת והתבניות של Azure: ‏azure_maintenance, ‏azure_sys, ‏template0 ו-template1.
  2. מוודאים שמכונת המקור כוללת את מסד הנתונים postgres שמוגדר כברירת מחדל. אם מסד הנתונים הזה לא קיים, צריך ליצור אותו לפני שמגדירים את ההעברה.
  3. מגדירים את חומת האש של Azure ואת הגדרות ה-SSL/TLS:
    1. בהגדרות הרשת של Azure, מוסיפים כללים של חומת אש שמאפשרים חיבורי TCP נכנסים ביציאה 5432 מכתובת ה-IP היוצאת של Cloud SQL, מטווח ה-CIDR של ה-VPC או מהמכונה הווירטואלית של היעד המבוצר (bastion host) של ה-SSH ההפוך.
    2. צריך לבדוק את הערך של הפרמטר require_secure_transport בשרת. כברירת מחדל, מסדי נתונים של Azure דורשים הצפנת SSL/TLS לחיבורים נכנסים. בהתאם להגדרה של require_secure_transport, בוחרים באחת מהגדרות ההצפנה הבאות כשיוצרים את פרופיל החיבור של המקור:
      • אם המדיניות require_secure_transport מוגדרת לערך on, בוחרים באפשרות בסיסי, TLS או mTLS.
      • אם require_secure_transport מוגדר ל-off, בוחרים באפשרות ללא.
  4. בודקים את תוספי PostgreSQL שמותקנים במסדי הנתונים של המקור. ‫Database Migration Service לא מעביר תוספים שלא נתמכים ב-Cloud SQL. מוודאים שהאובייקטים של מסד הנתונים במקור והשאילתות של האפליקציה לא מפנים לתוספים שלא נתמכים. לפני שממשיכים, צריך להסיר תוספים והפניות לא נתמכים ממסדי הנתונים של המקור.

    התוסף pg_cron לא מועבר אוטומטית על ידי Database Migration Service, אבל הוא נתמך ביעדים של Cloud SQL ל-PostgreSQL. אם אתם משתמשים ב-pg_cron במסד הנתונים של המקור, צריך להתקין אותו מחדש ולהגדיר אותו במכונה של היעד אחרי שמקדמים את ההעברה.

  5. יוצרים חשבון משתמש ייעודי להעברה במכונה של המקור, ונותנים לו את ההרשאות הנדרשות:
    1. מתחברים למכונה של המקור באמצעות חשבון אדמין, יוצרים את המשתמש ומקצים את תפקיד הרפליקציה: 
      CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
ALTER USER MIGRATION_USER_ACCOUNT_NAME WITH REPLICATION;
    2. נותנים לחשבון המשתמש להעברה את ההרשאות הנדרשות למסד הנתונים postgres שמוגדר כברירת מחדל, וגם לכל מסד נתונים שרוצים להעביר. מריצים את הפקודות הבאות בכל מסד נתונים לכל סכימה (חוץ מסכימת המידע וסכימות שמתחילות ב-pg_): 
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. מתקינים את התוסף pglogical בכל מסד נתונים שרוצים להעביר, חוץ מ-azure_maintenance,‏ azure_sys,‏ template0 ו-template1:
    • ב-PostgreSQL גרסה 9.4: מריצים את הפקודה הבאה: 
      CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
    • ב-PostgreSQL בגרסה 9.5 ואילך: מריצים את הפקודה הבאה: 
      CREATE EXTENSION IF NOT EXISTS pglogical;
  7. מוודאים שבטבלאות יש מפתחות ראשיים. בהעברות רציפות, כדי לשכפל פעולות UPDATE ו-DELETE במהלך שלב סימון הנתונים שהשתנו (CDC), צריך להגדיר מפתחות ראשיים בטבלאות של השכפול הלוגי של PostgreSQL:
    • טבלאות עם מפתח ראשי משכפלות את כל הפעולות של INSERT,‏ UPDATE ו-DELETE באופן אוטומטי.
    • בטבלאות שאין בהן מפתחות ראשיים, Database Migration Service תומך בהעברה רק של תמונת המצב הראשונית והצהרות INSERT הבאות במהלך שלב ה-CDC. צריך להעביר הצהרות UPDATE ו-DELETE באופן ידני.

      מומלץ להוסיף מפתחות ראשיים לטבלאות שאין בהן מפתחות כאלה לפני שמתחילים את ההעברה. במאמר ניפוי באגים וכלים אחרים מוסבר איך ליצור שאילתה כדי להציג רשימה של טבלאות במסד נתונים של PostgreSQL בלי מפתחות ראשיים, או איך להעביר באופן ידני פעולות של UPDATE ו-DELETE.

      לחלופין, אתם יכולים לנסות להשתמש בתהליך ההעברה המהיר: תרחיש העברה פשוט שבו אפשר להשתמש ב-REPLICA IDENTITY כדי להעביר טבלאות בלי מפתחות ראשיים. מידע נוסף זמין במדריך שימוש בהעברות מהירות.

  8. מקורות שפועלים בגרסה 9.5 ומטה של PostgreSQL: מדד העיכוב ברפליקציה לא זמין למכונות מקור שפועלות בגרסאות של PostgreSQL שקודמות ל-9.6. אם אתם רוצים להשתמש במדד הזה כדי לעקוב אחרי התקדמות ההעברה, קראו את המאמר הפעלת עיכוב ברפליקציה.
  9. מגדירים את הפרמטרים הבאים של השרת ב-Azure. מידע נוסף זמין במאמר הגדרת פרמטרים של שרת ב-Azure Database for PostgreSQL.
    1. מגדירים את shared_preload_libraries כך שיכלול את pglogical.
    2. מגדירים את azure.extensions כך שיכלול את pglogical.
    3. מגדירים את wal_level להיות logical.
    4. מגדירים את wal_sender_timeout להיות 0. הערך 0 משבית את מנגנון הזמן הקצוב לתפוגה שמסיים חיבורי רפליקציה לא פעילים.
    5. מגדירים את max_replication_slots לפחות למספר מסדי הנתונים שרוצים להעביר כפול מספר משימות ההעברה, בתוספת רזרבות לסנכרון הטבלאות:

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

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

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

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

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

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

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

    לפרטים נוספים על הפרמטרים, עיינו ברשימה של כל הפרמטרים של השרת ב-Azure Database for PostgreSQL במסמכי התיעוד של Microsoft.

  10. מפעילים מחדש את המכונה של Microsoft Azure Database for PostgreSQL Flexible Server כדי שהשינויים בפרמטרים של השרת ייכנסו לתוקף.

הגדרת מקור ב-Cloud SQL ל-PostgreSQL

כדי להגדיר מכונה של Cloud SQL ל-PostgreSQL כמקור לתהליך ההעברה:

  1. במקורות של Cloud SQL ל-PostgreSQL, שירות Database Migration Service מעביר את כל מסדי הנתונים במכונת המקור, חוץ ממסדי הנתונים של התבניות template0 ו-template1.
  2. מוודאים שמכונת המקור כוללת את מסד הנתונים postgres שמוגדר כברירת מחדל. אם מסד הנתונים הזה לא קיים, צריך ליצור אותו לפני שמגדירים את ההעברה.
  3. אם אתם מעבירים ממכונה של Cloud SQL שמוגדרת עם כתובת IP פרטית למכונה של Cloud SQL שמשתמשת בטווח כתובות IP שאינו RFC 1918, הוסיפו את הטווח שאינו RFC 1918 לרשתות המורשות של מכונת המקור. מידע נוסף זמין במאמר הגדרת רשתות מורשות.
  4. בודקים את תוספי PostgreSQL שמותקנים במסדי הנתונים של המקור. ‫Database Migration Service לא מעביר תוספים שלא נתמכים ב-Cloud SQL. מוודאים שהאובייקטים של מסד הנתונים במקור והשאילתות של האפליקציה לא מפנים לתוספים שלא נתמכים. לפני שממשיכים, צריך להסיר ממסדי הנתונים של המקור את התוספים וההפניות שלא נתמכים.

    ‫Database Migration Service לא מעביר אוטומטית את התוסף pg_cron, אבל הוא נתמך ביעדים של Cloud SQL ל-PostgreSQL. אם משתמשים ב-pg_cron במסד הנתונים של המקור, צריך להתקין אותו מחדש ולהגדיר אותו במכונה של היעד אחרי שמקדמים את ההעברה.

  5. יוצרים חשבון משתמש ייעודי להעברה במכונה של המקור, ונותנים לו את ההרשאות הנדרשות:
    1. פועלים לפי השלבים שמפורטים בדף Create a user במסמכי התיעוד של Cloud SQL.
    2. נותנים לחשבון המשתמש להעברה את ההרשאות הנדרשות למסד הנתונים postgres שמוגדר כברירת מחדל, וגם לכל מסד נתונים שרוצים להעביר. מריצים את הפקודות הבאות בכל מסד נתונים לכל סכימה (חוץ מסכימת המידע וסכימות שמתחילות ב-pg_): 
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. מתקינים את התוסף pglogical בכל מסד נתונים שרוצים להעביר, חוץ מ-template0 ומ-template1:
    • ב-PostgreSQL גרסה 9.4: מריצים את הפקודה הבאה: 
      CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
    • ב-PostgreSQL בגרסה 9.5 ואילך: מריצים את הפקודה הבאה: 
      CREATE EXTENSION IF NOT EXISTS pglogical;
  7. מוודאים שבטבלאות יש מפתחות ראשיים. בהעברות רציפות, כדי לשכפל פעולות UPDATE ו-DELETE במהלך שלב סימון הנתונים שהשתנו (CDC), צריך להגדיר מפתחות ראשיים בטבלאות של הרפליקציה הלוגית של PostgreSQL:
    • טבלאות עם מפתח ראשי משכפלות את כל הפעולות של INSERT,‏ UPDATE ו-DELETE באופן אוטומטי.
    • בטבלאות שאין בהן מפתחות ראשיים, Database Migration Service מעביר את קובץ ה-snapshot הראשוני ואת הצהרות ה-INSERT הבאות במהלך שלב ה-CDC. צריך להעביר באופן ידני את ההצהרות UPDATE ו-DELETE.

      מומלץ להוסיף מפתחות ראשיים לטבלאות שאין בהן מפתחות כאלה לפני שמתחילים את ההעברה. במאמר ניפוי באגים וכלים אחרים מוסבר איך ליצור שאילתה כדי להציג רשימה של טבלאות במסד נתונים של PostgreSQL בלי מפתחות ראשיים, או איך להעביר באופן ידני פעולות של UPDATE ו-DELETE.

      לחלופין, אתם יכולים לנסות להשתמש בתהליך ההעברה המהיר: תרחיש העברה פשוט שבו אפשר להשתמש ב-REPLICA IDENTITY כדי להעביר טבלאות בלי מפתחות ראשיים. מידע נוסף זמין במדריך שימוש בהעברות מהירות.

  8. מקורות שפועלים בגרסה 9.5 ומטה של PostgreSQL: מדד העיכוב ברפליקציה לא זמין למכונות מקור שפועלות בגרסאות של PostgreSQL שקודמות ל-9.6. אם אתם רוצים להשתמש במדד הזה כדי לעקוב אחרי התקדמות ההעברה, קראו את המאמר הפעלת עיכוב ברפליקציה.
  9. מגדירים את הדגלים הבאים לניהול מסד הנתונים במכונה של מקור Cloud SQL:
    1. מגדירים את cloudsql.logical_decoding להיות on.
    2. מגדירים את cloudsql.enable_pglogical להיות on.
    3. מגדירים את wal_sender_timeout להיות 0. הערך 0 משבית את מנגנון הזמן הקצוב לתפוגה שמסיים חיבורי רפליקציה לא פעילים.
    4. מגדירים את max_replication_slots לפחות למספר מסדי הנתונים שרוצים להעביר כפול מספר משימות ההעברה, בתוספת רזרבות לסנכרון הטבלאות.

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

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

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

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

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

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

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

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

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

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