סקירה כללית
לפני שבוחרים להעביר את מסדי הנתונים ל-Cloud SQL, חשוב לקחת בחשבון את המגבלות הידועות של תרחיש ההעברה הזה.
המגבלות הידועות על שימוש במסד נתונים של MySQL כמקור כוללות:
אין תמיכה בהעברה ל-MySQL 5.6 או ל-MySQL 8.4 עם קובץ גיבוי פיזי של Percona XtraBackup.
להעברות מ-MySQL 8.0 ל-MySQL 8.4: שיקולים נוספים להעברות מ-8.0 ל-8.4 כוללים:
- במסד הנתונים של היעד, הדגל
local_infileצריך להיות מוגדר לערךON. - לחשבון ההעברה הייעודי במופע המקור לא יכולות להיות הרשאות
BACKUP_ADMIN.
ההיבטים האלה מוסברים גם בקטעים הרלוונטיים, כמו הדף הגדרת מסד נתונים של מקור.
- במסד הנתונים של היעד, הדגל
כשמבצעים מיגרציה בין גרסאות ראשיות של MySQL (לדוגמה, מ-MySQL 8.0 ל-MySQL 8.4), צריך לטפל בחוסר תאימות אפשרי כדי להבטיח מיגרציה חלקה ללא בעיות של עקביות נתונים.
כשמתכוננים להעברה בין גרסאות, כדאי לעיין בתכונות הנתמכות ב-Cloud SQL ל-MySQL ובהערות לגבי הגרסה הראשית של היעד כדי לזהות בעיות תאימות שצריך לטפל בהן.
במהלך השלב של יצירת עותק מלא של הנתונים, אי אפשר לבצע פעולות בשפת הגדרת נתונים (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. מידע נוסף זמין בסעיף הבא, העוסק בפתרון בעיות:אם המקור הוא Amazon RDS MySQL, Amazon Aurora MySQL או מקור שלא מעניק הרשאות SUPERUSER, נדרשים שלבים נוספים כדי שההעברה תצליח, כולל השבתה קצרה של הכתיבה במקור. מידע נוסף זמין בקטעים Amazon RDS-specific ו-Amazon Aurora-specific.
Database Migration Service לא יכול להעביר נתונים ממופע של העתק לקריאה של Amazon Aurora של אשכול מסדי נתונים של MySQL, כי אי אפשר לאחזר קבצים של יומן בינארי מהמופע. מידע נוסף זמין בקטע שמתייחס ספציפית ל-Amazon Aurora.
מסד הנתונים של מערכת MySQL לא מועבר כחלק מהעברת השרת, מה שאומר שמידע על תפקידי משתמשים לא נכלל.
כשמעבירים נתונים באמצעות Database Migration Service, אפשר לבחור מסדי נתונים ספציפיים. כל הטבלאות והסכימות ממסדי הנתונים שנבחרו מועברות, למעט סכימות המערכת הבאות:
mysql,performance_schema,information_schemaו-sys. לפני שמתחילים בהעברה, חשוב לוודא שבמסד הנתונים של המקור לא קיימים אובייקטים שמפנים לטבלאות בסכימות האלה. אחרת, ההעברה עלולה להיכשל עם ההודעהERROR 1109 (42S02): Unknown table in <schema name here>. אפשר לעיין במאמרים בנושא הגדרת מסד הנתונים של המקור ואבחון בעיות.אם מסדי נתונים מוצפנים דורשים מפתחות הצפנה בניהול הלקוח כדי לפענח את המידע במסדי הנתונים, ול-Database Migration Service אין גישה למפתחות, אי אפשר להעביר את מסדי הנתונים.
Database Migration Service תומך בהעברת נתונים ממסדי נתונים מוצפנים של Amazon Aurora או Amazon RDS, כי מסדי הנתונים האלה מטפלים בפענוח באופן שקוף בשירותים שלהם. מידע נוסף זמין במאמרים בנושא הצפנת משאבי Amazon Aurora והצפנת משאבי Amazon RDS.
במהלך ההעברה, מסד הנתונים של Cloud SQL ביעד נמצא במצב קריאה בלבד, כדי למנוע שינוי של מסד הנתונים שעלול לשבש את תהליך ההעברה או את תקינות הנתונים. אחרי שמקדמים את יעד ההעברה, אפשר לכתוב בו.
בשלב הזה, Database Migration Service לא תואם ל-MariaDB.
צריך להגדיר את הפורמט של יומן הרישום הבינארי לערך
ROW. הגדרת יומן בינארי לפורמט אחר, כמוSTATEMENTאוMIXED, עלולה לגרום לכשל בשכפול. לדוגמה, באמצעות ההצהרהLOAD DATA IN FILE.אם יוצרים משימת העברה רציפה באמצעות קובץ dump משלכם, אל תשתמשו בכלי
mysqldumpמגרסה 5.7.36 של MySQL. מידע נוסף זמין בבאג מספר 105761 במאמרי העזרה של MySQL.InnoDB הוא מנוע האחסון היחיד שנתמך ב-Cloud SQL. העברה באמצעות MyISAM עלולה לגרום לחוסר עקביות בנתונים, ולכן נדרש אימות נתונים. לקבלת עזרה בהמרת טבלאות מ-MyISAM ל-InnoDB, אפשר לעיין בתיעוד של MySQL.
שיטת הקישוריות של ממשקי Private Service Connect נתמכת רק להעברה למכונות יעד קיימות. אם רוצים להשתמש בקישוריות של כתובות IP פרטיות ולבצע העברה למופע יעד חדש, צריך להשתמש בקישור בין רשתות VPC שכנות (peering).
שיקולים לגבי מקביליות של העתקת נתונים
ההגדרה 'מקביליות של גיבוי נתונים' מאפשרת לכם לבצע מיגרציה ממסדי נתונים של MySQL באמצעות מנגנון גיבוי עם ביצועים גבוהים, וכך לשפר משמעותית את מהירות המיגרציה. כשמשתמשים בהקצאת מקביליות לגיבוי נתונים, חשוב לזכור את הנקודות הבאות:
ההקצאה המקבילה של נתוני ה-dump זמינה כרגע רק כשמבצעים העברה ל-MySQL בגרסאות 5.7 או 8.
בתחילת פריקת הנתונים, השירות להעברת נתונים נועל את מסד הנתונים של המקור לזמן קצר, כך שהוא לא זמין זמנית לכתיבה. משך הנעילה תלוי במספר הטבלאות במסד הנתונים של המקור:
מספר הטבלאות שעה משוערת לנעילת המכשיר 100 שנייה אחת 10K 9 שניות 50,000 49 שניות
מגבלות בהעברות למופעי יעד קיימים
- מופע היעד הקיים יכול להכיל רק מסדי נתונים של מערכת ברירת המחדל, שמוגדרים באופן אוטומטי כשיוצרים את מופע היעד.
העברה למופעים קיימים של יעד שמכילים נתוני משתמשים (כמו טבלאות בסכימות של המערכת או מסדי נתונים) לא נתמכת.
אם נתקלתם בבעיות בגלל נתונים נוספים במופע היעד הקיים, צריך לנקות את מסדי הנתונים במופע היעד ולנסות שוב להפעיל את משימת ההעברה. אפשר לעיין במאמר בנושא ניקוי נתונים נוספים ממופע היעד הקיים.
- אפשר להגדיר רק משימת העברה אחת לכל מופע יעד.
- אפשר להעביר רק למכונות עצמאיות של Cloud SQL. אין תמיכה בהעברה אל רפליקות של שרתים חיצוניים.
- כדי לבצע מיגרציה למופע של Cloud SQL שיש בו רפליקה לקריאה, צריך להפעיל את הרישום של מזהה עסקה גלובלי (GTID) במופע המקור.
- אי אפשר להשתמש ברפליקות לקריאה של Cloud SQL ל-MySQL כמכונת היעד להעברה.
- למשתמשי Terraform: Database Migration Service משנה את הגדרות הגיבוי והשחזור של מופע היעד. יכול להיות שההגדרות של מופע היעד יהיו שונות מההגדרות של Terraform שבהן השתמשתם להקצאת המשאבים. אם נתקלתם בבעיה הזו, כדאי לפעול לפי ההנחיות שבמאמר אבחון בעיות.
מכסות
- יכולים להיות עד 2,000 פרופילים של חיבורים ו-1,000 משימות העברה בכל זמן נתון. כדי לפנות מקום לעוד משימות העברה (כולל משימות שהושלמו) ופרופילים של חיבורים, אפשר למחוק אותם.