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

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

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

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

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

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

בטבלה הבאה מפורטות בעיות נפוצות והפתרונות שלהן:

בבעיה הזו… יכול להיות שהבעיה היא... אפשר לנסות את זה…
כשמעבירים לאשכול יעד קיים, מופיעה הודעת השגיאה הבאה: The destination cluster contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty clusters. Clear your destination cluster and retry the migration job. אשכול היעד של AlloyDB ל-PostgreSQL מכיל נתוני משתמשים נוספים. אפשר להעביר רק לאשכולות קיימים וריקים. מגבלות ידועות מוחקים את הנתונים הנוספים או הנתונים שמתנגשים מאשכול היעד ומנסים שוב להפעיל את משימת ההעברה. מחיקת נתונים מיותרים מאשכול היעד הקיים.
החיבור למכונה של מסד הנתונים במקור נכשל. הייתה בעיית קישוריות בין מכונת מסד הנתונים במקור לבין אשכול AlloyDB ל-PostgreSQL ביעד. פועלים לפי השלבים שמפורטים בקטע ניפוי באגים בקישוריות.
הפעלת משימת ההעברה נכשלה כי הגרסאות של מסד הנתונים של המקור והיעד לא תואמות. הגרסאות של מסד הנתונים של המקור והיעד הן לא שילוב נתמך. באופן ספציפי, גרסת מסד הנתונים של המקור שצוינה לא תואמת לגרסת מסד הנתונים של היעד. מוודאים שגרסת מסד הנתונים של היעד זהה לגרסה הראשית הנתמכת של מסד הנתונים של המקור, או שהיא גרסה מאוחרת יותר. אחר כך יוצרים משימת העברה חדשה.
שפות הגדרת נתונים (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.
  • המדד Total destination 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 RDS, שימוש באישור בסיס עצמאי במקום בחבילת אישורים עלול לגרום לבעיה הזו.

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

במקורות של Amazon RDS, צריך להשתמש בחבילת אישורים שכוללת גם את אישור הביניים וגם את אישור הבסיס. מידע נוסף זמין במאמר הורדת חבילות אישורים במסמכי התיעוד של Amazon RDS.

הודעת השגיאה: 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 לא מותקנת בצורה נכונה במכונה של המקור. למידע נוסף על התקנה נכונה של החבילה הזו, ראו הגדרת מסד הנתונים של המקור.

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

המקור שהוגדר נמצא במצב שחזור. צריך להגדיר מקור שלא נמצא במצב שחזור.
ההורדה המלאה איטית. יכול להיות שהמכונה הראשית של אשכול היעד של AlloyDB ל-PostgreSQL תייבא לאט נתונים גדולים ממסד הנתונים של המקור.
  • כדי לקבל את רוחב הפס המקסימלי הזמין ברשת ואת קיבולת המעבד (CPU), בחרו רמת מכונה גבוהה יותר למכונה הראשית של AlloyDB ל-PostgreSQL ביעד.
  • מגדירים את הדגל max_wal_size של היעד. בדרך כלל, 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. ברשימת המשאבים, בוחרים את מכונת AlloyDB ל-PostgreSQL. מופיעה רשימה של היומנים האחרונים של המכונה.
  3. בוחרים באפשרות postgres.log מתוך שמות קובצי היומן.
  4. מגדירים את רמת החומרה של היומן לכל הרמות שמעל Warning. יכול להיות שיומני השגיאות הראשונים הם שורש הבעיה.
  • חשוב לוודא ש-Database Migration Service תמיד יכול להתחבר למכונה של מסד הנתונים במקור במהלך שלב ה-dump המלא.
  • בודקים אם הערך של הפרמטר wal_sender_timeout מוגדר למספר גדול יותר (לדוגמה, 0) במכונה של מסד הנתונים במקור.
  • מפעילים מחדש את משימת ההעברה ומנסים שוב.
הודעת השגיאה: ERROR: unknown column name {column_name}

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

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

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

בקטע העברה רציפה מופיעות דוגמאות לשימוש ב-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.

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

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

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

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

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

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

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

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

דברים שכדאי לנסות

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

  1. עצירת משימת ההעברה.
  2. מתחברים למכונה הראשית של אשכול היעד ב-AlloyDB ל-PostgreSQL באמצעות psql או AlloyDB Studio.
  3. מסירים נתונים מיותרים ממסדי הנתונים של אשכול היעד. היעד יכול להכיל רק נתוני הגדרות מערכת. מסדי הנתונים של היעד לא יכולים להכיל נתוני משתמשים (כמו טבלאות או שגרות שהוגדרו על ידי המשתמש). יש כמה הצהרות SQL שאפשר להריץ על מסדי הנתונים כדי למצוא נתונים שהם לא של המערכת:

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

    SELECT datname FROM pg_catalog.pg_database
WHERE datname NOT IN ('alloydbadmin', '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 NOT IN ('plpgsql', 'alloydb_utility');
  4. מוחקים את כל מסדי הנתונים שאינם של המערכת, טבלאות המשתמשים והפונקציות בהגדרת המשתמש שזוהו בשלב הקודם.
  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.

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

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

דברים שכדאי לנסות

לכל מסד נתונים, מריצים את הפקודות הבאות כמשתמש עם הרשאת 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 ל-PostgreSQL שמשתמשות במכונה המקורית, מריצים את הפקודה הבאה כדי לנקות את ההגדרות של pglogical:

    SELECT pglogical.drop_node(node_name) FROM pglogical.node WHERE node_name LIKE '%alloydb%';

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

    DROP EXTENSION IF EXISTS pglogical;

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

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

  • מוצגת הודעת השגיאה Cannot connect to invalid database.
  • המדד Total destination storage usage migration job לא מראה התקדמות אחרי הרבה זמן, כשמשימת ההעברה מבצעת את ה-dump המלא של מסד הנתונים.

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

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

דברים שכדאי לנסות

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

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

  1. מוחקים את משימת ההעברה שנכשלה. אפשר לקרוא מידע נוסף במאמר בדיקה של משימת העברה.
  2. מוחקים את אשכול היעד שבו נתקלתם בבעיה. ניהול אשכולות ב-AlloyDB
  3. יוצרים מחדש את משימת ההעברה. איך יוצרים משימת העברה
מעבר לגרסת ביניים

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

מחיקת אשכולות מיותרים של AlloyDB ל-PostgreSQL במצב אתחול

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

gcloud alloydb clusters delete CLUSTER_ID \
    --region=REGION_ID \
    --force

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

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

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

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

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

במהלך העברה רגילה, כל האובייקטים של מסד הנתונים ברפליקה של AlloyDB ל-PostgreSQL נמצאים בבעלות המשתמש alloydbexternalsync (בהעברות מהירות, המשתמש הוא postgres). אחרי שהנתונים מועברים ומשימת ההעברה מקודמת, אתם יכולים לשנות את הבעלות על האובייקטים למשתמשים אחרים באפליקציה. כדי לעשות את זה:

  • מריצים את הפקודה GRANT alloydbexternalsync TO USER;.
  • בכל מסד נתונים, מריצים את הפקודה REASSIGN OWNED BY alloydbexternalsync TO USER;.
  • כדי להסיר את המשתמש alloydbexternalsync, מריצים את הפקודה DROP ROLE alloydbexternalsync;.