פתרון בעיות בהעברה
יכול להיות שיתרחשו שגיאות במהלך זמן הריצה של תהליך העברת המשימות.
- אפשר לתקן שגיאות מסוימות, כמו סיסמה שגויה במסד הנתונים של המקור, והעברת הנתונים תתחדש באופן אוטומטי.
- חלק מהשגיאות לא ניתנות לתיקון, כמו שגיאות בשכפול נתונים, ולכן צריך להפעיל מחדש את משימת ההעברה מההתחלה.
כשמתרחשת שגיאה, סטטוס משימת ההעברה משתנה ל-Failed, וסטטוס המשנה משקף את הסטטוס האחרון לפני הכשל.
כדי לפתור שגיאה, עוברים אל משימת ההעברה שנכשלה כדי לראות את השגיאה ופועלים לפי השלבים שמפורטים בהודעת השגיאה.
כדי לראות פרטים נוספים על השגיאה, עוברים אל Cloud Monitoring באמצעות הקישור למשימת ההעברה. היומנים מסוננים לפי משימת ההעברה הספציפית.
בטבלה הבאה מפורטות כמה דוגמאות לבעיות ופתרונות אפשריים:
| תיאור הבעיה | סיבות אפשריות | פעולות שכדאי לנסות |
|---|---|---|
| החיבור למופע של מסד הנתונים המקורי נכשל. | הייתה בעיית קישוריות בין מופע מסד הנתונים של המקור לבין מופע היעד. | פועלים לפי השלבים במאמר בנושא ניפוי באגים בקישוריות. |
| הפעלת משימת ההעברה נכשלה בגלל גרסאות לא תואמות של מסד הנתונים של המקור ומסד הנתונים של היעד. | גרסאות מסד הנתונים של המקור והיעד לא נתמכות בשילוב. באופן ספציפי, גרסת מסד הנתונים של המקור לא תואמת לגרסת מסד הנתונים של היעד. | מוודאים שגרסת מסד הנתונים של היעד זהה לגרסת מסד הנתונים של המקור או גבוהה ממנה בגרסה ראשית אחת. לאחר מכן, יוצרים משימת העברה חדשה. |
| שפות להגדרת נתונים (DDL) או שפות לטיפול בנתונים (DML) חסומות במקור. | פקודות DDL שדורשות ACCESS EXCLUSIVE נעילה ומופעלות במהלך שלב הגיבוי המלא נחסמות. |
במהלך תהליך הסנכרון הראשוני (dump מלא), צריך להימנע משימוש ב-DDL או בתוכניות שדורשות לדוגמה, אם טבלה עדיין נמצאת בתהליך הסנכרון הראשוני ומופעלת פקודת |
הודעת שגיאה: 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 לא הוגדר בצורה נכונה. |
כדי להגדיר את הפרמטר הזה בצורה נכונה, צריך לפעול לפי ההנחיות האלה. |
|
הודעת שגיאה: או
הודעת שגיאה: |
אי אפשר לנקות את ההגדרות שנדרשות לשכפול במהלך קידום של משימת העברה. | לכל מסד נתונים, מריצים פקודות בתור משתמש עם הרשאת מידע נוסף על הפקודות שצריך להריץ זמין במאמר הסרת משבצות רפליקציה. |
|
הודעת שגיאה: |
יכול להיות שאישור ה-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. |
|
הודעת שגיאה: |
הערך שהוגדר לפרמטר max_locks_per_transaction לא מספיק. |
הערך של הפרמטר הזה צריך להיות לפחות {max_number_of_tables_per_database}/(max_connections + max_prepared_transactions). |
|
הודעת שגיאה: |
חבילת pglogical לא מותקנת בצורה תקינה במופע המקור. | מידע נוסף על התקנה נכונה של החבילה זמין במאמר בנושא התקנת החבילה pglogical במופע המקור. |
|
הודעת שגיאה: |
המקור שהוגדר נמצא במצב שחזור. | הגדרה של מקור שלא נמצא במצב שחזור. |
| הפריקה המלאה איטית. | יכול להיות שייקח זמן רב לייבא נתונים גדולים ממסד הנתונים של המקור ליעד ב-AlloyDB. |
|
הודעת שגיאה: subscriber {subscriber_name} initialization failed during nonrecoverable step (d), please try the setup again |
העברת העבודה נכשלה במהלך שלב הגיבוי המלא, ואי אפשר לשחזר את העבודה. הופעלה מחדש של מופע מסד הנתונים של המקור, או שהוא במצב שחזור, או שהחיבורים לשכפול הסתיימו בגלל ערך לא מספיק שהוגדר לפרמטר כדי למצוא את שורש הבעיה:
|
|
הודעת שגיאה: ERROR: unknown column name {column_name} |
עמודה נוספה לטבלה משוכפלת בצומת הראשי, אבל לא בצומת המשוכפל. |
במהלך העברות רציפות, רק שינויים בשפת טיפול בנתונים (DML) מתעדכנים באופן אוטומטי. המשתמש אחראי לניהול השינויים בשפת הגדרת הנתונים (DDL) כדי שמסדי הנתונים של המקור והיעד יישארו תואמים. אפשר לעשות זאת בשתי דרכים:
דוגמאות לשימוש ב- |
הודעת שגיאה: ERROR: cannot truncate a table referenced in a foreign key constraint |
המשתמש ניסה לחתוך טבלה שיש לה אילוץ של מפתח זר. |
קודם מסירים את אילוץ המפתח הזר, ואז חותכים את הטבלה. |
הודעת שגיאה: ERROR: connection to other side has died |
החיבור לשכפול הסתיים בגלל ערך לא מספיק שהוגדר ל- |
כדאי להגדיל את ערך הפרמטר |
| כשמעבירים מסדי נתונים נבחרים ועבודת ההעברה לא מצליחה לשכפל נתונים למסד נתונים אחד או יותר, הסטטוס נכשל מוצג ברשימת מסדי הנתונים. | שגיאות שונות בעבודת ההעברה. | בעמודה שגיאות, לוחצים על הצגת שגיאות ומתקנים אותן. אפשר גם להסיר את מסדי הנתונים שנכשלו מעבודת ההעברה. מידע נוסף על הסרת מסד נתונים שנכשל מהעברת נתונים זמין במאמר ניהול של משימות העברה. |
ניקוי משבצות שכפול
אחת מההודעות הבאות תופיע:
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:
מעתיקים את שמות משבצות השכפול מהודעת השגיאה ומריצים את הפקודה הבאה כדי להסיר את המשבצות, אחת אחרי השנייה:
select pg_drop_replication_slot({slot_name});-
אם שמות משבצות השכפול לא מופיעים בהודעת השגיאה, מריצים את הפקודה הבאה כדי לשלוח שאילתה לגבי משבצות השכפול הקיימות:
select pg_drop_replication_slot(slot_name) from pg_replication_slots where slot_name like '%alloydb%' and active = 'f';
-
אם אין רפליקות של AlloyDB שמשתמשות במופע המקור, מריצים את הפקודה הבאה כדי לנקות את ההגדרות של
pglogical:select pglogical.drop_node(node_name) from pglogical.node where node_name like
'alloydb'; -
אם כבר אין צורך בתוסף
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.