שאלות נפוצות על Database Migration Service for AlloyDB

‫MySQL   |  PostgreSQL   |  PostgreSQL ל-AlloyDB

• מה זה Database Migration Service?
• אילו מקורות נתמכים?
• האם יש תמיכה בגרסאות שונות?
• אילו נתונים, סכימות ורכיבי מטא-נתונים מועברים?
• אילו שינויים משוכפלים במהלך העברה רציפה?
• מה לא מועבר?
• באילו שיטות רשת נעשה שימוש?
• מהן המגבלות הידועות?

מהו Database Migration Service?

Database Migration Service הוא שירות שמקל על העברת נתונים אל Google Cloud. בעזרת Database Migration Service (שירות העברת מסדי נתונים) אפשר להעביר את עומסי העבודה של PostgreSQL ל-AlloyDB.

אילו מקורות נתמכים?

• ‫Amazon RDS 9.6.10+, ‏ 10.5+, ‏ 11.1+, ‏ 12, ‏ 13, ‏ 14, ‏ 15, ‏ 16, ‏ 17
• ‫Amazon Aurora 10.11+, ‏ 11.6+, ‏ 12.4+, ‏ 13.3+, ‏ 14, ‏ 15, ‏ 16, ‏ 17
• ‫PostgreSQL בניהול עצמי (במקום או במכונה וירטואלית בענן שאתם שולטים בה באופן מלא) 9.4, ‏ 9.5, ‏ 9.6, ‏ 10, ‏ 11, ‏ 12, ‏ 13, ‏ 14, ‏ 15, ‏ 16, ‏ 17
• ‫Cloud SQL‏ 9.6, ‏ 10, ‏ 11, ‏ 12, ‏ 13, ‏ 14, ‏ 15, ‏ 16, ‏ 17

אילו יעדים נתמכים?

• ‫AlloyDB ל-PostgreSQL‏ 14, 15, 16, 17, 18

האם יש תמיכה בכמה גרסאות?

Database Migration Service תומך בהעברות מ-PostgreSQL ל-AlloyDB מכל אחת מגרסאות מסד הנתונים הנתמכות של המקור.

אילו רכיבים של נתונים, סכימה ומטא-נתונים מועברים?

‫

Database Migration Service מעביר סכימה, נתונים ומטא-נתונים מהמקור ליעד. כל הרכיבים הבאים של נתונים, סכימה ומטא-נתונים מועברים כחלק מהעברת מסד הנתונים:

העברת נתונים

• כל הסכימות וכל הטבלאות ממסד הנתונים שנבחר.

העברת סכימה

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

העברת מטא-נתונים

• נהלים מאוחסנים
• פונקציות
• טריגרים
• תצוגות
• אילוצים של מפתח זר

אילו שינויים משוכפלים במהלך העברה רציפה?

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

1. מפסיקים את הכתיבה למקור ומריצים את פקודות ה-DDL גם במקור וגם ביעד. לפני שמריצים פקודות DDL ביעד, צריך להעניק את התפקיד alloydbexternalsync למשתמש Cloud SQL שמחיל את שינויי ה-DDL. כדי לאפשר שאילתות או שינוי של הנתונים, צריך להעניק את התפקיד alloydbexternalsync למשתמשי Cloud SQL הרלוונטיים.

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

   הנה כמה דוגמאות לשימוש ב-pglogical.replicate_ddl_command.

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

   select pglogical.replicate_ddl_command('ALTER TABLE [schema].[table] add column surname varchar(20)', '{default}');

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

   select pglogical.replicate_ddl_command('ALTER TABLE [schema].[table] RENAME TO [table_name]','{default}');

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

   1. select pglogical.replicate_ddl_command(command := 'CREATE TABLE [schema].[table] (id INTEGER PRIMARY KEY, name VARCHAR);', replication_sets := ARRAY['default'']);
   2. select pglogical.replication_set_add_table('default', '[schema].[table]');

מה לא מועבר?

כדי להוסיף משתמשים למכונת היעד של AlloyDB, מוסיפים אותם מלקוח PostgreSQL. מידע נוסף על יצירה וניהול של משתמשי PostgreSQL

אי אפשר לשכפל אובייקטים גדולים כי מתקן הפענוח הלוגי של PostgreSQL לא תומך בפענוח שינויים באובייקטים גדולים. בטבלאות עם column type oid שמתייחסות לאובייקטים גדולים, השורות עדיין מסונכרנות ושורות חדשות משוכפלות. עם זאת, ניסיון לגשת לאובייקט הגדול במסד הנתונים של היעד (קריאה באמצעות lo_get, ייצוא באמצעות lo_export או בדיקה בקטלוג pg_largeobject של ה-oid הנתון) נכשל, ומוצגת הודעה שלפיה האובייקט הגדול לא קיים.

בטבלאות שאין להן מפתחות ראשיים, Database Migration Service תומך בהעברה של התמונה הראשונית ושל הצהרות INSERT במהלך השלב של סימון נתונים שהשתנו (CDC). מומלץ להעביר את הדוחות UPDATE ו-DELETE באופן ידני.

Database Migration Service לא מעביר נתונים מתצוגות חומריות, אלא רק את סכימת התצוגה. כדי לאכלס את התצוגות, מריצים את הפקודה הבאה: REFRESH MATERIALIZED VIEW view_name.

המצבים של SEQUENCE (לדוגמה, last_value) ביעד החדש של AlloyDB עשויים להיות שונים מהמצבים של SEQUENCE במקור.

באילו שיטות ליצירת רשת נעשה שימוש?

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

שיטת ה-Networking	תיאור	יתרונות	חסרונות
מנהרת SSH הפוכה דרך מכונה וירטואלית שמתארחת בענן	יוצר קישוריות מהיעד למקור דרך מנהרת SSH הפוכה ומאובטחת. נדרשת מכונה וירטואלית של יעד מבוצר (bastion host) ב Google Cloud פרויקט ומכונה (לדוגמה, מחשב נייד ברשת) שיש לה קישוריות למקור. Database Migration Service אוסף את המידע הנדרש בזמן יצירת ההעברה, ומפיק באופן אוטומטי את הסקריפט להגדרת ההעברה.	קל להגדיר. לא נדרשת הגדרה מותאמת אישית של חומת האש. מומלץ לתרחישי העברה לזמן קצר (הוכחת היתכנות או העברות של מסדי נתונים קטנים).	אתם הבעלים של מכונת ה-VM של Bastion ואתם מנהלים אותה. יכול להיות שיהיו עלויות נוספות.
שרת proxy ל-TCP דרך מכונה וירטואלית (VM) שמתארחת בענן	יוצר קישוריות מהיעד למקור דרך שרת proxy של TCP באמצעות מכונה וירטואלית שמתארחת בענן. Database Migration Service אוסף את המידע הנדרש בזמן יצירת ההעברה, ומפיק באופן אוטומטי את הסקריפט להגדרת ההעברה. רלוונטי להעברות ל-AlloyDB שבהן המקור נמצא בארכיטקטורת הרשת הישנה.	קל להגדיר. לא נדרשת הגדרה מותאמת אישית של חומת האש.	המכונה הווירטואלית של Bastion נמצאת בבעלותכם ובניהולכם, ויכול להיות שיהיו לה עלויות נוספות.
קישור בין רשתות VPC שכנות (peering)	השיטה הזו פועלת על ידי הגדרת רשתות ה-VPC כך שיוכלו לתקשר זו עם זו.	פתרון Google Cloud מקורי. קל להגדיר. רוחב פס גבוה מומלץ להשתמש באפשרות הזו להעברות ארוכות או להעברות של נפח גדול של נתונים.	האפשרות הזו רלוונטית רק אם מסדי הנתונים של המקור והיעד מתארחים ב- Google Cloud.
VPN	הגדרת מנהרת IPSec VPN שמחברת בין הרשת הפנימית לבין Google Cloud VPC באמצעות חיבור מאובטח באינטרנט הציבורי. משתמשים ב- Google Cloud VPN או בכל פתרון VPN שהוגדר לרשת הפנימית.	פתרון קישוריות חזק וניתן להרחבה. רוחב פס בינוני-גבוה. אבטחה מובנית. מוצעים כ Google Cloud פתרונות או מצדדים שלישיים אחרים.	עלות נוספת. הגדרה לא טריוויאלית (אלא אם היא כבר קיימת).
Cloud Interconnect	השימוש בחיבור עם זמן אחזור קצר וזמינות גבוהה בין הרשת המקומית לבין Google Cloud.	רוחב הפס הגבוה ביותר, אידיאלי להעברות ארוכות של נפח גדול של נתונים.	עלות נוספת. החיבור לא מאובטח כברירת מחדל. הגדרה לא טריוויאלית (אלא אם היא כבר קיימת).

מהן המגבלות הידועות?

מגבלות ידועות