אבחון בעיות בהעברות הומוגניות אל Cloud SQL ל-PostgreSQL

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

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

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

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

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

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

לבעיה הזו... יכול להיות שהבעיה היא... אפשר לנסות את הפעולות הבאות…
כשמעבירים אל מופע יעד קיים, מוצגת הודעת השגיאה הבאה: The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job. מכונת היעד של Cloud SQL מכילה נתונים נוספים. אפשר לבצע מיגרציה רק למופעים קיימים וריקים. מגבלות ידועות מקדמים את מופע היעד כדי שיהיה מופע לקריאה ולכתיבה, מסירים את הנתונים הנוספים ומנסים שוב להפעיל את משימת ההעברה. אפשר לעיין במאמר ניקוי נתונים נוספים ממופע היעד הקיים.
החיבור למופע של מסד הנתונים המקורי נכשל. הייתה בעיית קישוריות בין מופע מסד הנתונים של המקור לבין מופע היעד. פועלים לפי השלבים במאמר בנושא ניפוי באגים בקישוריות.
הפעלת משימת ההעברה נכשלה בגלל גרסאות לא תואמות של מסד הנתונים של המקור ומסד הנתונים של היעד. גרסאות מסד הנתונים של המקור והיעד לא נתמכות בשילוב. באופן ספציפי, גרסת מסד הנתונים של המקור לא תואמת לגרסת מסד הנתונים של היעד. מוודאים שגרסת מסד הנתונים של היעד זהה לגרסת מסד הנתונים של המקור או גבוהה ממנה בגרסה ראשית אחת. לאחר מכן, יוצרים משימת העברה חדשה.
שפות להגדרת נתונים (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 במסדי הנתונים במופע המקור, פועלים לפי ההנחיות האלה.
כשמבצעים מיגרציה ל-PostgreSQL גרסה 15, אחרי כמה ניסיונות חוזרים של חיבור, אחד מהתסמינים הבאים מתרחש: הבעיה הזו קורית בדרך כלל בגלל בעיית הקיפאון בתוסף pglogical. מידע נוסף זמין ב pglogical הכלי למעקב אחר בעיות ב-GitHub. מנסים שוב להפעיל את משימת ההעברה, או מעבירים קודם לגרסת ביניים של PostgreSQL. פרטים נוספים זמינים במאמר הודעת השגיאה: Cannot connect to invalid database.
הודעת שגיאה: 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.

המקור שהוגדר נמצא במצב שחזור. הגדרה של מקור שלא נמצא במצב שחזור.
הפריקה המלאה איטית. יכול להיות שייקח זמן רב לייבא נתונים גדולים ממסד הנתונים המקורי אל היעד ב-Cloud SQL.
  • כשיוצרים את היעד, מגדירים את הגודל של דיסק הנתונים כך שיהיה קרוב לגודל הסופי. בשלב המלא של ה-dump נעשה שימוש בעומס עבודה שדורש הרבה פעולות קלט/פלט (I/O) של כתיבה, וגודל דיסק גדול יותר מאפשר ביצועים טובים יותר של קלט/פלט. מידע נוסף מופיע במאמר ביצועים של אחסון בלוקים.
  • כדי לקבל את רוחב הפס המקסימלי הזמין ברשת ובדיסק, בוחרים רמה גבוהה יותר ליעד Cloud SQL.
  • כוונון של הדגל max_wal_size ביעד Cloud SQL. בדרך כלל, ערך טוב להגדרה של הדגל הזה הוא ‎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. ברשימת המשאבים, בוחרים את העותק המשוכפל של Cloud SQL. מופיעה רשימה של היומנים האחרונים של העותק.
  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 במופע של מסד הנתונים של המקור.
הודעת אזהרה: migration job test configuration has returned the following warnings: Some table(s) have limited support.

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

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

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

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

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

ניקוי נתונים נוספים ממופע היעד הקיים

כשמעבירים ל מופע יעד קיים, מוצגת הודעת השגיאה הבאה: The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job.

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

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

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

  1. הפסקת משימת ההעברה.
  2. בשלב הזה, מכונת היעד של Cloud SQL נמצאת במצב read-only (קריאה בלבד). קידום מופע היעד כדי לקבל גישת כתיבה.
  3. מתחברים למכונת היעד של Cloud SQL.
  4. מסירים נתונים מיותרים ממסדי הנתונים של מופע היעד. יעד הגיבוי יכול להכיל רק נתוני תצורת מערכת. מסדי נתונים של יעדים לא יכולים להכיל נתוני משתמשים (כמו טבלאות). יש כמה הצהרות SQL שאפשר להריץ במסדי הנתונים כדי למצוא נתונים שלא קשורים למערכת, למשל:

    דוגמה להוראת SQL לאחזור מסדי נתונים שאינם מסדי נתונים של המערכת (יש ללחוץ כדי להרחיב את הקטע)

    SELECT datname FROM pg_catalog.pg_database
WHERE datname NOT IN ('cloudsqladmin', 'template1', 'template0', 'postgres');

    דוגמה להוראת SQL לאחזור נתונים שאינם נתוני מערכת במסד הנתונים postgres (לחיצה להרחבה)

    מסד הנתונים postgres הוא מסד נתונים של המערכת, אבל הוא יכול להכיל נתונים שלא שייכים למערכת. חשוב להריץ את ההצהרות האלה במסד הנתונים postgres. אם משתמשים בלקוח psql כדי להתחבר למופע היעד, אפשר לעבור למסד נתונים אחר בלי לאפס את החיבור באמצעות הפקודה \connect {database_name_here}.

    SELECT table_schema, table_name FROM information_schema.tables
WHERE table_schema != 'information_schema' AND table_schema not like 'pg\_%';

SELECT routine_schema, routine_name FROM information_schema.routines
WHERE routine_schema != 'information_schema' AND routine_schema not like 'pg\_%';

SELECT extname FROM pg_extension WHERE extname != 'plpgsql';
  5. התחלת עבודת ההעברה.

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

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

  • 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.

יכול להיות שהבעיה היא

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

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

לכל מסד נתונים, מריצים את הפקודות הבאות כמשתמש עם הרשאת 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 '%cloudsql%' and active = 'f';

  3. אם אין רפליקות של Cloud SQL שמשתמשות במופע המקור, מריצים את הפקודה הבאה כדי לנקות את ההגדרות של pglogical:

    select pglogical.drop_node(node_name) from pglogical.node where node_name like 'cloudsql';

  4. אם כבר אין צורך בתוסף pglogical, מריצים את הפקודה הבאה כדי להסיר אותו:

    DROP EXTENSION IF EXISTS pglogical;

הודעת שגיאה: Cannot connect to invalid database

כשמבצעים מיגרציה ל-PostgreSQL בגרסה 15, אחרי כמה ניסיונות חוזרים של חיבור, אחת מהבעיות הבאות מתרחשת:

יכול להיות שהבעיה היא

הבעיה הזו קשורה בדרך כלל לבעיית הקיפאון בתוסף pglogical. מידע נוסף אפשר למצוא ב pglogical Issue Tracker ב-GitHub.

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

מבצעים שוב את עבודת ההעברה עם מופע יעד חדש

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

  1. מוחקים את מופע היעד שבו נתקלתם בבעיות. אפשר לעיין במאמר מחיקת מכונות במסמכי Cloud SQL ל-PostgreSQL.
  2. מוחקים את משימת ההעברה שנכשלה. אפשר לעיין במאמר בדיקת משימת העברה.
  3. יוצרים מחדש את עבודת ההעברה. איך יוצרים עבודת העברה

מעבר לגרסה ביניים

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

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

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

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

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

במהלך ההעברה, כל האובייקטים בעותק המשוכפל של Cloud SQL נמצאים בבעלות המשתמש cloudsqlexternalsync. אחרי העברת הנתונים, אפשר לשנות את הבעלות על האובייקטים למשתמשים אחרים. כך עושים זאת:

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

ייבוא נתונים למכונה חדשה של Cloud SQL

אם קודם מייצאים נתונים ממכונת Cloud SQL שהועברה אל Cloud Storage באמצעות Database Migration Service, ואז מייבאים את הנתונים מ-Cloud Storage אל מכונת Cloud SQL עצמאית, יכול להיות שהייבוא ייכשל כי המשתמש cloudsqlexternalsync לא קיים במכונת היעד.

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