הגדרת המקור

‫MySQL   |  PostgreSQL   |  PostgreSQL ל-AlloyDB

סקירה כללית

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

מסדי הנתונים הנתמכים כמקורות ל-MySQL כוללים:

• ‫Amazon RDS 5.6, ‏ 5.7, ‏ 8.0, ‏ 8.4, ‏ 9.7
• ‫MySQL בניהול עצמי (במקום או במכונה וירטואלית בענן שאתם שולטים בה באופן מלא) 5.5, ‏ 5.6, ‏ 5.7, ‏ 8.0, ‏ 8.4, ‏ 9.7
• ‫Cloud SQL ל-MySQL 5.6, ‏ 5.7, ‏ 8.0, ‏ 8.4, ‏ 9.7
• ‫Amazon Aurora 5.6, ‏ 5.7, ‏ 8.0, ‏ 8.4, ‏ 9.7
• ‫Microsoft Azure Database for MySQL 5.7, ‏ 8.0, ‏ 8.4, ‏ 9.7

בנוסף, Database Migration Service תומך בגרסאות המשניות הבאות של מקורות MySQL 8.0: ‫8.0.18, ‏ 8.0.26, ‏ 8.0.27, ‏ 8.0.28, ‏ 8.0.30, ‏ 8.0.31, ‏ 8.0.32, ‏ 8.0.33, ‏ 8.0.34, ‏ 8.0.35, ‏ 8.0.36, ‏ 8.0.37, ‫8.0.39, ‏ 8.0.40, ‏ 8.0.41, ‏ 8.0.42, ‏ 8.0.43.

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

1. למקורות Cloud SQL: אם אתם מבצעים העברה ממכונת Cloud SQL שמשתמשת בקישור דרך IP פרטי למכונת Cloud SQL שמשתמשת בטווח של כתובות IP מסוג non-RFC 1918, צריך להוסיף את הטווח הזה להגדרת הרשת של מכונת המקור של Cloud SQL. מידע נוסף על הגדרת רשתות מורשות בתיעוד של Cloud SQL.
2. לפני שמעבירים נתונים ממסד הנתונים של המקור למסד הנתונים של היעד, צריך לוודא שמפסיקים את כל פעולות הכתיבה של שפת הגדרת הנתונים (DDL) במהלך שלב הגיבוי המלא. אפשר להשתמש בסקריפט כדי לוודא שפעולות ה-DDL הופסקו. אחרי שההעברה נמצאת בשלב ה-CDC, אפשר להמשיך בפעולות ה-DDL.
3. מוודאים שמסד הנתונים של המקור לא מכיל מטא-נתונים שהוגדרו על ידי משתמשים עם פסקה DEFINER. מידע נוסף זמין במאמר בנושא יצירה והפעלה של משימת העברה של MySQL שמכילה מטא-נתונים עם פסקה של DEFINER.
4. אם מסד הנתונים של המקור מכיל אובייקטים שמפנים לטבלאות בסכימות המערכת mysql, performance_schema, information_schema, ndbinfo או sys, צריך לוודא שגם מסדי הנתונים של העותקים כוללים את הטבלאות האלה של סכימת המערכת.

   אם מסדי הנתונים המשוכפלים לא כוללים את הטבלאות האלה, יכול להיות שעבודת ההעברה תיכשל עם השגיאה Unknown table in system schema .

5. צריך להגדיר את האפשרות server-id לערך של 1 או יותר. מידע נוסף זמין במאמר Replication and Binary Logging Options and Variables.
6. כדי להגדיר רישום של מזהה עסקה גלובלי (GTID), צריך להגדיר את הערך GTID_MODE ל-ON או ל-OFF. הערך GTID_MODE של ON_PERMISSIVE לא נתמך.

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

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

7. צריך להגדיר את חשבון המשתמש שמשמש לחיבור למסד הנתונים של המקור כך שיקבל חיבורים מכל מקום (host = %). אפשר להגביל את הגישה למשתמש הזה בשלב מאוחר יותר.

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

   יש ארבעה סוגים של שילובים של העברות וגיבויים:

   • סוג 1: העברה רציפה וגיבוי מנוהל
   • סוג 2: העברה רציפה וגיבוי ידני
   • סוג 3: העברה חד-פעמית ופריקה מנוהלת
   • סוג 4: העברה חד-פעמית ופריקה ידנית

   בכרטיסיות שלמטה מפורטות ההרשאות לכל שילוב של סוג ההעברה והגיבוי.

   סוג 1

   לחשבון המשתמש שאתם מגדירים צריכות להיות ההרשאות הבאות:

   • REPLICATION SLAVE
   • EXECUTE
   • SELECT
   • SHOW VIEW
   • REPLICATION CLIENT
   • RELOAD
   • TRIGGER
   • (להעברה מ-Amazon RDS ומ-Amazon Aurora בלבד) LOCK TABLES

   ‫MySQL גרסה 8.0 ואילך: מוודאים שלחשבון ההעברה אין הרשאת BACKUP_ADMIN.

   מידע נוסף על הרשאות זמין במאמר Privileges Provided by MySQL. מידע נוסף על חשבונות משתמשים זמין במאמר בנושא פורמט של חשבון משתמש ב-MySQL.

   Type 2

   לחשבון המשתמש שאתם מגדירים צריכות להיות ההרשאות הבאות:

   • REPLICATION SLAVE
   • EXECUTE

   מידע נוסף על הרשאות זמין במאמר Privileges Provided by MySQL. מידע נוסף על חשבונות משתמשים זמין במאמר בנושא פורמט של חשבון משתמש ב-MySQL.

   סוג 3

   לחשבון המשתמש שאתם מגדירים צריכות להיות ההרשאות הבאות:

   • SELECT
   • SHOW VIEW
   • TRIGGER
   • (להעברה מ-Amazon RDS ומ-Amazon Aurora בלבד) LOCK TABLES
   • (להעברה ממקורות עם ההגדרה GTID_MODE = ON בלבד)RELOAD

   ‫MySQL גרסה 8.0 ואילך: מוודאים שלחשבון ההעברה אין הרשאת BACKUP_ADMIN.

   מידע נוסף על הרשאות זמין במאמר Privileges Provided by MySQL. מידע נוסף על חשבונות משתמשים זמין במאמר בנושא פורמט של חשבון משתמש ב-MySQL.

   סוג 4

   לא נדרשות הרשאות.

   מידע נוסף על הרשאות זמין במאמר Privileges Provided by MySQL. מידע נוסף על חשבונות משתמשים זמין במאמר בנושא פורמט של חשבון משתמש ב-MySQL.

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

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

   Cloud SQL ל-MySQL

   ב-Cloud SQL ל-MySQL, רישום בינארי מופעל באופן אוטומטי כשמשתמשים בשחזור מערכת מנקודה מסוימת בזמן (PITR). אפשר להגדיר את פורמט היומן ואת תקופת השמירה באמצעות דגלי המערכת שזמינים ב-Cloud SQL:

   1. מפעילים את התכונה PITR במופע כדי להפעיל רישום ביומן בינארי. מידע נוסף זמין במאמר שחזור מערכת מנקודה מסוימת בזמן (PITR) במאמרי העזרה של Cloud SQL.
   2. משתמשים בדגלים של Cloud SQL כדי לשנות את הגדרות הרישום ביומן. פרטים נוספים זמינים במאמר הגדרת דגלים של מסד נתונים במסמכי התיעוד של Cloud SQL.
      1. לא צריך לשנות את ההגדרות של פורמט היומן. ב-Cloud SQL ל-MySQL, הדגל binlog_format מוגדר אוטומטית לערך ROW.
      2. כדי להגדיר את מועד התפוגה של היומן, משתמשים באחד מהדגלים הבאים:
         • ‫MySQL 5.6 - 5.7: expire_logs_days
         • ‫MySQL 8.0 ואילך: expire_logs_days, binlog_expire_logs_seconds

   ‫MySQL באירוח עצמי

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

   • ‫MySQL 5.5 עד 5.7: expire_logs_days
   • ‫MySQL 8.0: ‏ expire_logs_days, ‏ binlog_expire_logs_seconds

   Microsoft Azure Database for MySQL

   רישום ביומן בינארי מופעל כברירת מחדל ב-Microsoft Azure Database for MySQL. אין צורך להפעיל אותה. מידע נוסף זמין במאמרי העזרה של Microsoft.

   מגדירים את הפרמטרים הנדרשים הבאים:

   1. מגדירים את binlog_expire_logs_seconds לתקופה ארוכה מספיק כדי לתמוך בהעברת מסד הנתונים.

      מידע נוסף זמין במאמר הגדרת פרמטרים של שרת ב-Azure Database for PostgreSQL ובפרמטר binlog_expire_logs_seconds במסמכי העזרה של מיקרוסופט.

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

   ‫Amazon RDS

   ב-Amazon RDS, מגדירים את ההגדרה מבוססת השורה בקבוצת הפרמטרים על ידי הגדרת הפרמטר binlog retention hours. הפרמטר הזה משמש כדי לציין כמה שעות מערכת Amazon RDS צריכה לשמור קבצים של יומן בינארי.

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

   call mysql.rds_set_configuration('binlog retention hours',168);

   הערך המקסימלי שאפשר להגדיר לפרמטר הזה הוא 168 שעות (או 7 ימים).

   Amazon Aurora

   כדי לעשות זאת ב-Amazon Aurora:

   1. הפעלת רישום ביומן בינארי למסד הנתונים של MySQL.
   2. מגדירים את תקופת השמירה של יומן בינארי:

      mysql> call mysql.rds_set_configuration('binlog retention hours', 168);

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

   מידע נוסף על InnoDB זמין במאמר The InnoDB Storage Engine. מידע נוסף על המרה ל-InnoDB זמין במאמר בנושא המרת טבלאות מ-MyISAM ל-InnoDB.

10. הסיסמה של חשבון המשתמש שמשמש לחיבור למסד הנתונים של המקור לא יכולה להיות ארוכה מ-32 תווים. זו בעיה שספציפית לשכפול של MySQL.

    מידע נוסף על ההגבלה של אורך הסיסמה של משתמש MySQL זמין במאמר MySQL Bug #43439.

11. למקורות של Microsoft Azure Database for MySQL בלבד: בודקים את הערך של ההגדרה require_secure_transport.

    כברירת מחדל, מסדי נתונים של Microsoft Azure דורשים הצפנה מסוג SSL/TLS לכל החיבורים הנכנסים. בהתאם לערך של require_secure_transport, משתמשים באחת מהגדרות ההצפנה הבאות כשיוצרים את פרופיל חיבור המקור:

    • אם הערך של require_secure_transport הוא on, בוחרים באפשרות בסיסי, TLS או mTLS.
    • אם הערך של require_secure_transport הוא off, בוחרים באפשרות ללא.