אבחון בעיות בהעברות מ-PostgreSQL ל-AlloyDB

פתרון בעיות בהעברה

יכול להיות שיתרחשו שגיאות במהלך זמן הריצה של תהליך העברת המשימות.

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

כשמתרחשת שגיאה, סטטוס משימת ההעברה משתנה ל-Failed, וסטטוס המשנה משקף את הסטטוס האחרון לפני הכשל.

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

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

בטבלה הבאה מפורטות כמה דוגמאות לבעיות ופתרונות אפשריים:

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

במהלך תהליך הסנכרון הראשוני (dump מלא), צריך להימנע משימוש ב-DDL או בתוכניות שדורשות ACCESS EXCLUSIVE נעילות כמו ALTER TABLE או DROP TABLE בטבלאות. אחרת, ה-DDL או התוכניות ימתינו עד לסיום הסנכרון הראשוני.

לדוגמה, אם טבלה עדיין נמצאת בתהליך הסנכרון הראשוני ומופעלת פקודת ALTER TABLE באותה טבלה, הפקודה לא תופעל ופקודות DDL ו-DML הבאות ייחסמו עד שהסנכרון הראשוני יסתיים.

הודעת שגיאה: No pglogical extension installed on databases (X) במסד נתונים אחד או יותר של מקורות לא מותקן pglogical. כדי להתקין את pglogical במסדי הנתונים במופע המקור, פועלים לפי ההנחיות האלה.
הודעת שגיאה: Replication user 'x' doesn't have sufficient privileges. למשתמש שמשתמש ב-Database Migration Service אין את ההרשאות הנדרשות לביצוע הפעולה שצוינה. כדי לוודא שלמשתמש הזה יש את ההרשאות הנדרשות, צריך לפעול לפי ההנחיות האלה.
הודעת שגיאה: Unable to connect to source database server. Database Migration Service לא יכול ליצור חיבור לשרת של מסד הנתונים המקורי. מוודאים שמופעי מסד הנתונים של המקור והיעד יכולים לתקשר זה עם זה, ושהשלמתם את כל הדרישות המוקדמות שהופיעו כשהגדרתם את ההגדרות של משימת ההעברה.
הודעת שגיאה: The source database 'wal_level' configuration must be equal to 'logical'. הערך של wal_level עבור מסד הנתונים של המקור מוגדר לערך שאינו logical. מגדירים את wal_level לערך logical.
הודעת שגיאה: The source database 'max_replication_slots' configuration is not sufficient. הפרמטר max_replication_slots לא הוגדר בצורה נכונה. כדי להגדיר את הפרמטר הזה בצורה נכונה, צריך לפעול לפי ההנחיות האלה.
הודעת שגיאה: The source database 'max_wal_senders' configuration is not sufficient. הפרמטר max_wal_senders לא הוגדר בצורה נכונה. כדי להגדיר את הפרמטר הזה בצורה נכונה, צריך לפעול לפי ההנחיות האלה.
הודעת שגיאה: The source database 'max_worker_processes' configuration is not sufficient. הפרמטר max_worker_processes לא הוגדר בצורה נכונה. כדי להגדיר את הפרמטר הזה בצורה נכונה, צריך לפעול לפי ההנחיות האלה.

הודעת שגיאה: Cleanup may have failed on source due to error: generic::unknown: failed to connect to on-premises database.

או

הודעת שגיאה: Error promoting EM replica: finished drop replication with errors.

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

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

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

הודעת שגיאה: x509 certificate signed by unknown authority.

יכול להיות שאישור ה-CA של המקור שסופק ל-Database Migration Service יכיל רק את אישור הבסיס. עם זאת, אישור המקור דורש גם את אישור הבסיס וגם את כל אישורי הביניים.

לדוגמה, ב-Amazon Relational Database Service, שימוש באישור rds-ca-2019-root.pem עלול לגרום לבעיה הזו.

יוצרים אישור משולב של רשות אישורים (CA) שמכיל גם את אישור הבסיס וגם את כל אישורי הביניים הנדרשים.

בתרחיש השימוש של Amazon Relational Database Service, במקום באישור rds-ca-2019-root.pem, משתמשים באישור rds-combined-ca-bundle.pem.

הודעת שגיאה: ERROR: Out of shared memory HINT: You might need to increase max_locks_per_transaction.

הערך שהוגדר לפרמטר max_locks_per_transaction לא מספיק. הערך של הפרמטר הזה צריך להיות לפחות {max_number_of_tables_per_database}/(max_connections + max_prepared_transactions).

הודעת שגיאה: ERROR: no data left in message.

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

הודעת שגיאה: Cannot assign TransactionIds during recovery.

המקור שהוגדר נמצא במצב שחזור. הגדרה של מקור שלא נמצא במצב שחזור.
הפריקה המלאה איטית. יכול להיות שייקח זמן רב לייבא נתונים גדולים ממסד הנתונים של המקור ליעד ב-AlloyDB.
  • כדי לקבל את רוחב הפס המקסימלי ברשת ובדיסק, בוחרים רמה גבוהה יותר ליעד AlloyDB.
  • משנים את הערך של הדגל max_wal_size ביעד AlloyDB. בדרך כלל, ערך טוב להגדרה של הדגל הזה הוא ‎32 GB או ‎64 GB. כדי לעדכן את הדגל הזה, לא צריך להפעיל מחדש את השרת.
הודעת שגיאה: subscriber {subscriber_name} initialization failed during nonrecoverable step (d), please try the setup again

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

כדי למצוא את שורש הבעיה:

  1. נכנסים לדף Logs Explorer ב Google Cloud מסוף.
  2. ברשימת המשאבים, בוחרים את מופע AlloyDB. מוצגת רשימה של היומנים האחרונים של המופע.
  3. בשמות של קובצי היומן, בוחרים באפשרות postgres.log.
  4. מגדירים את רמת החומרה של היומן לכל הרמות שמעל Warning. יכול להיות שיומני השגיאות הראשונים הם שורש הבעיה.
  • חשוב לוודא ש-Database Migration Service יכול להתחבר תמיד למופע של מסד נתוני המקור במהלך השלב של הגיבוי המלא.
  • בודקים אם הערך של הפרמטר wal_sender_timeout מוגדר למספר גדול יותר (לדוגמה, 0) במופע של מסד הנתונים של המקור.
  • מפעילים מחדש את עבודת המיגרציה ומנסים שוב.
הודעת שגיאה: ERROR: unknown column name {column_name}

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

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

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

הודעת שגיאה: ERROR: cannot truncate a table referenced in a foreign key constraint

המשתמש ניסה לחתוך טבלה שיש לה אילוץ של מפתח זר.

קודם מסירים את אילוץ המפתח הזר, ואז חותכים את הטבלה.

הודעת שגיאה: ERROR: connection to other side has died

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

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

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

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

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

ניקוי משבצות שכפול

אחת מההודעות הבאות תופיע:

  • Cleanup may have failed on source due to error: generic::unknown: failed to connect to on-premises database.
  • Error promoting EM replica: finished drop replication with errors.

סיבות אפשריות

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

פעולות שכדאי לנסות

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

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

    select pg_drop_replication_slot({slot_name});
  2. אם שמות משבצות השכפול לא מופיעים בהודעת השגיאה, מריצים את הפקודה הבאה כדי לשלוח שאילתה לגבי משבצות השכפול הקיימות:

    select pg_drop_replication_slot(slot_name) from pg_replication_slots where slot_name like '%alloydb%' and active = 'f';
  3. אם אין רפליקות של AlloyDB שמשתמשות במופע המקור, מריצים את הפקודה הבאה כדי לנקות את ההגדרות של pglogical:

    select pglogical.drop_node(node_name) from pglogical.node where node_name like 'alloydb';
  4. אם כבר אין צורך בתוסף pglogical, מריצים את הפקודה הבאה כדי להסיר אותו:

    DROP EXTENSION IF EXISTS pglogical;

מחיקת אשכולות AlloyDB יתומים במצב bootstrapping

במקרים נדירים, יכול להיות שתגלו שעבודת ההעברה שלכם נמחקה, אבל אשכול AlloyDB המשויך לא נמחק, והוא עדיין במצב אתחול. אפשר למחוק את האשכול באמצעות פקודת gcloud למחיקת אשכול ב-AlloyDB, בשילוב עם האפשרות --force.

שימו לב: מחיקה של אשכול bootstrapping בזמן שהוא בשימוש על ידי משימת העברה מובילה להתנהגות לא מוגדרת.

ניהול משתמשים ותפקידים

העברת משתמשים קיימים

בשלב הזה, Database Migration Service לא תומך בהעברת משתמשים קיימים ממופע מקור למופע יעד של AlloyDB. אתם יכולים לנהל את ההעברה הזו על ידי יצירת המשתמשים ב-AlloyDB באופן ידני.

מידע על המשתמש alloydbexternalsync

במהלך ההעברה, כל האובייקטים ב-AlloyDB הראשי הם בבעלות המשתמש alloydbexternalsync. אחרי העברת הנתונים, אפשר לשנות את הבעלות על האובייקטים למשתמשים אחרים. כך עושים זאת:

  • מריצים את הפקודה GRANT alloydbexternalsync to {USER}.
  • בכל מסד נתונים, מריצים את הפקודה reassign owned by alloydbexternalsync to {USER};.
  • כדי להסיר את המשתמש alloydbexternalsync, מריצים את הפקודה drop role alloydbexternalsync.