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

לפני שבוחרים להעביר את מסדי הנתונים ל-Cloud SQL, כדאי להביא בחשבון את המגבלות הידועות בתרחיש ההעברה הזה.

הערה: אפשר גם להשתמש ב-Google Cloud Migration Center כדי לגלות פערים בתמיכה בתכונות. איך מאתרים ומייבאים מסדי נתונים במאמרי העזרה של Migration Center.

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

• כדי להעביר מסדי נתונים מוצפנים, צריך לספק את מפתחות ההצפנה ל-Database Migration Service. אפשר להעביר נתונים ממסדי נתונים מוצפנים של Amazon Aurora או Amazon RDS באמצעות Database Migration Service, כי מסדי הנתונים האלה מטפלים בפענוח באופן שקוף בשירותים שלהם. מידע נוסף זמין במאמרים הבאים: הצפנת משאבים של Amazon Aurora, הצפנת משאבים של Amazon RDS ו הגדרת מפתחות הצפנה בניהול הלקוח (CMEK).

• אי אפשר להעביר ל-MySQL 5.6, ל-MySQL 8.4 או ל-MySQL 9.7 באמצעות קובץ גיבוי פיזי של Percona XtraBackup.

• להעברות מ-MySQL 8.0 ל-MySQL 8.4 ומ-MySQL 8.4 ל-MySQL 9.7:

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

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

• כשמעבירים נתונים בין גרסאות ראשיות של MySQL (לדוגמה, מ-MySQL 8.0 ל-MySQL 8.4), צריך לטפל בבעיות תאימות אפשריות כדי לוודא שההעברה תתבצע בצורה חלקה בלי בעיות בעקביות הנתונים.

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

  • ‫MySQL 9.7
  • MySQL 8.4
  • ‫MySQL 8.0
  • MySQL 5.7

• בשלב של העברת הנתונים המלאה, אי אפשר לבצע פעולות של שפת הגדרת נתונים (DDL) (כמו ALTER TABLE, DROP TABLE, TRUNCATE TABLE) במסד הנתונים של המקור. הפעלת הפעולות האלה במהלך השלב של הגיבוי המלא עלולה לגרום לקיפאון של המטא-נתונים, ולגרום לתהליך ההעברה להיכשל (עם השגיאה Table definition has changed) או להפסיק להגיב (ולדווח על שגיאות של פסק זמן כמו ERROR: While 'Loading data': Dump timeout או MySQL Error 2013 (HY000): Lost connection to MySQL server during query). אפשר לבצע שינויים ב-DDL במסד הנתונים של המקור במהלך השלב של CDC. למידע נוסף, קראו את הערכים הבאים בקטע "פתרון בעיות":

  • Table definition has changed
  • While 'Loading data': dump timeout
  • MySQL Error 2013: Lost connection to MySQL server during query
  • Timeout waiting for no write traffic on the source: context deadline exceeded

• אם המקור הוא Amazon RDS MySQL,‏ Amazon Aurora MySQL או מקור שלא מעניק הרשאות SUPERUSER, נדרשים שלבים נוספים להעברה מוצלחת, כולל השבתה קצרה של הכתיבה במקור. מידע נוסף זמין בקטעים הגדרת מסד נתונים של מקור ל-Amazon RDS וספציפי ל-Amazon Aurora.

• ‫Database Migration Service לא יכול להעביר נתונים ממכונה של רפליקה לקריאה בלבד של Amazon Aurora או ממכונה של רפליקה לקריאה בלבד של Oracle Cloud Infrastructure (OCI) MySQL, כי אי אפשר לאחזר קובצי יומן בינאריים מהמכונה. מידע נוסף על Amazon Aurora זמין בקטע הספציפי בנושא Amazon Aurora.

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

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

• כשמבצעים העברה באמצעות Database Migration Service (שירות העברת מסדי נתונים), אפשר לבחור מסדי נתונים ספציפיים להעברה, אבל אי אפשר לסנן או לבחור אובייקטים ספציפיים במסד נתונים (כמו טבלאות, תצוגות או פרוצדורות מאוחסנות ספציפיות). כל הטבלאות והאובייקטים של InnoDB מכל מסד נתונים שנבחר מועברים, למעט סכימות המערכת הבאות: mysql,‏ performance_schema,‏ information_schema ו-sys. לפני שמתחילים את ההעברה, חשוב לוודא שמסד הנתונים של המקור לא מכיל אובייקטים שמפנים לטבלאות בסכימות האלה. אחרת, יכול להיות שההעברה תיכשל ותופיע ההודעה ERROR 1109 (42S02): Unknown table in <schema name here>. אפשר לקרוא מידע נוסף במאמרים הגדרת מסד הנתונים של המקור ואבחון בעיות.

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

• ‫Database Migration Service לא תואם ל-MariaDB.

• צריך להגדיר את הפורמט של היומן הבינארי ל-ROW. אם מגדירים את היומן הבינארי לפורמט אחר, כמו STATEMENT או MIXED, יכול להיות שהרפליקציה תיכשל. לדוגמה, באמצעות ההצהרה LOAD DATA IN FILE.

  מידע נוסף על ההגבלה הזו בפורמטים STATEMENT או MIXED.

• אם אתם יוצרים משימת העברה רציפה באמצעות קובץ dump משלכם, אל תשתמשו בכלי mysqldump מגרסה 5.7.36 של MySQL. מידע נוסף זמין בבאג מספר 105761 במאמרי העזרה של MySQL.

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

• שיטת הקישוריות של ממשקי Private Service Connect נתמכת רק להעברה למכונות יעד קיימות. אם אתם רוצים להשתמש בקישוריות של כתובת IP פרטית ולהעביר למכונה חדשה ביעד, השתמשו בקישור בין רשתות VPC שכנות (peering).

שיקולים לגבי מקביליות של העברת נתונים

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

• אפשר להשתמש ב-Data dump parallelism רק כשמעבירים לגרסאות 5.7,‏ 8.0,‏ 8.4 או 9.7 של MySQL.

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

  מספר הטבלאות	הזמן המשוער לנעילה
  100	שנייה אחת
  10,000	‫9 שניות
  50,000	‫49 שניות

הערה: אם אי אפשר לנעול את מסד הנתונים של המקור, השתמשו ברפליקה לקריאה בלבד בתור מסד הנתונים של המקור. למידע על העברה מרפליקות לקריאה בלבד ב-Amazon RDS, קראו את המאמר העברה מ-RDS MySQL.

מגבלות על העברות למופעי יעד קיימים

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

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

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

מכסות

• בכל זמן נתון יכולים להיות עד 2,000 פרופילי חיבור ו-1,000 משימות העברה. כדי לפנות מקום, אפשר למחוק משימות העברה (כולל משימות שהושלמו) ופרופילי חיבור.