אבחון בעיות בהעברות הומוגניות אל 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, אחרי כמה ניסיונות חוזרים להתחבר, קורה אחד מהדברים הבאים:
  • מוצגת הודעת השגיאה Cannot connect to invalid database.
  • המדד Storage usage migration job לא מראה התקדמות אחרי הרבה זמן, כשמשימת ההעברה מבצעת את ה-dump המלא של מסד הנתונים.
הבעיה הזו קשורה בדרך כלל לבעיית המבוי הסתום בתוסף 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. הגדרת רמת WAL
הודעת השגיאה: 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 המלא נעשה שימוש בעומס עבודה אינטנסיבי של כתיבת קלט/פלט, ודיסק גדול יותר מספק ביצועי קלט/פלט טובים יותר. מידע נוסף זמין במאמר ביצועים של אחסון בלוקים.
  • כדי לקבל את רוחב הפס המקסימלי הזמין לרשת ולדיסק, צריך לבחור רמה גבוהה יותר ליעד של Cloud SQL.
  • מכווננים את הדגל max_wal_size של יעד Cloud SQL. בדרך כלל, 32GB או 64GB הם ערכים טובים להגדרה של הדגל הזה. לא צריך להפעיל מחדש את השרת כדי לעדכן את הדגל הזה.
הודעת השגיאה: subscriber {subscriber_name} initialization failed during nonrecoverable step (d), please try the setup again

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

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

  1. נכנסים לדף Logs Explorer במסוף Google Cloud .
  2. ברשימת המשאבים, בוחרים את הרפליקה של Cloud SQL. מופיעה רשימה של היומנים האחרונים של הרפליקה.
  3. בוחרים באפשרות postgres.log מתוך שמות קובצי היומן.
  4. מגדירים את רמת החומרה של היומן לכל הרמות שמעל Warning. יכול להיות שיומני השגיאות הראשונים הם הסיבה העיקרית לכשל.
  • חשוב לוודא ש-Database Migration Service תמיד יכול להתחבר למכונה של מסד הנתונים במקור במהלך שלב ה-dump המלא.
  • בודקים אם הערך של הפרמטר 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 לא מספיק. השגיאה בדרך כלל מתרחשת בשלב השכפול, אחרי שההעתקה הראשונית הושלמה.

כדאי להגדיל את ערך הפרמטר wal_sender_timeout או להשבית את מנגנון הזמן הקצוב לתפוגה על ידי הגדרת הערך שלו ל-0 במכונה של מסד הנתונים במקור.
הודעת אזהרה: migration job test configuration has returned the following warnings: Some table(s) have limited support.

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

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

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

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

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

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

כשמעבירים למכונה קיימת ביעד, מופיעה הודעת השגיאה הבאה: 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 ב-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 שהועברה באמצעות Database Migration Service ל-Cloud Storage, ואז מייבאים את הנתונים מ-Cloud Storage למכונה עצמאית של Cloud SQL, יכול להיות שהייבוא ייכשל כי המשתמש cloudsqlexternalsync לא קיים במכונת היעד.

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