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

בדף הזה מוסבר איך להגדיר את מופעי מסד הנתונים הבאים של המקור להעברות רציפות והומוגניות של MySQL:

הגדרת מקור ב-Cloud SQL ל-MySQL

כדי להגדיר מכונת מקור של Cloud SQL ל-MySQL לתהליך ההעברה:

  1. בודקים אם מסד הנתונים של המקור מכיל מטא-נתונים שהוגדרו על ידי משתמשים באמצעות פסקה DEFINER. אימות מטא-נתונים באמצעות משפט DEFINER

    השירות להעברת נתונים של מסדי נתונים להעברות הומוגניות של MySQL לא מעביר חשבונות משתמשים והתחברויות. מקורות שמכילים מטא-נתונים שמוגדרים על ידי חשבונות משתמשים עם הסעיף DEFINER עלולים לחסום את ההעברה.

  2. אם מסד הנתונים של המקור מכיל אובייקטים שמפנים לטבלאות בסכימות המערכת mysql,‏ performance_schema,‏ information_schema,‏ ndbinfo או sys, ודאו שגם מסדי הנתונים של הרפליקה מכילים את הטבלאות האלה של סכימות המערכת.

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

  3. מפעילים ומגדירים יומנים בינאריים במסד הנתונים של המקור.

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

    1. מפעילים PITR במופע. התכונה הזו מפעילה באופן אוטומטי רישום ביומן בינארי. אי אפשר להפעיל רישום בינארי ללא PITR ב-Cloud SQL. למידע נוסף, קראו את המאמר שחזור מערכת מנקודה מסוימת בזמן (PITR) במסמכי התיעוד של Cloud SQL.
    2. אפשר להשתמש בדגלים של Cloud SQL כדי לשנות את הגדרות הרישום ביומן. פרטים נוספים זמינים במאמר הגדרת דגלים של מסד נתונים במסמכי התיעוד של Cloud SQL.
      1. כדי להשתמש ב-Database Migration Service, צריך להגדיר את binlog_format לערך ROW. אין צורך לשנות את ההגדרה הזו, כי 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

  4. יוצרים בחשבון משתמש ייעודי להעברה. מידע נוסף זמין במאמר יצירת משתמש במסמכי התיעוד של Cloud SQL. חשוב לוודא ש:

    • אתם מאפשרים לחשבון המשתמש הייעודי להתחבר מכל מארח (host=%).
    • הסיסמה של החשבון לא ארוכה מ-32 תווים. מידע נוסף על מגבלות האורך של סיסמאות משתמשים ב-MySQL זמין במאמר MySQL Bug #43439.

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

    פלט מנוהל

    אם רוצים ש-Database Migration Service ייצור באופן אוטומטי את קובץ ה-dump המלא של מסד הנתונים במקור, צריך להקצות לחשבון המשתמש את ההרשאות הבאות:

    פלט ידני

    אם אתם מספקים קובצי dump משלכם שנוצרו באמצעות mysqldump, אתם צריכים לספק את ההרשאות הנדרשות לשלב ה-CDC:

הגדרת מקור MySQL באירוח עצמי

כדי להגדיר מופע מקור של MySQL באירוח עצמי לתהליך ההעברה:

  1. מוודאים שכל הטבלאות (חוץ מטבלאות במסדי נתונים של המערכת) משתמשות ב מנוע האחסון InnoDB. אם אתם משתמשים במנוע אחסון אחר, יכול להיות שתצטרכו להמיר את הטבלאות. מידע נוסף זמין במאמר Converting Tables from MyISAM to InnoDB.
  2. בודקים אם מסד הנתונים של המקור מכיל מטא-נתונים שהוגדרו על ידי משתמשים באמצעות פסקה DEFINER. מידע נוסף זמין במאמר בנושא אימות מטא-נתונים באמצעות סעיף DEFINER.

    ‫Database Migration Service להעברות MySQL הומוגניות לא מעביר חשבונות משתמשים ופרטי התחברות. מקורות שמכילים מטא-נתונים שהוגדרו על ידי חשבונות משתמשים עם סעיף DEFINER עשויים לחסום את ההעברה.

  3. אם מסד הנתונים של המקור מכיל אובייקטים שמפנים לטבלאות בסכימות המערכת mysql,‏ performance_schema,‏ information_schema,‏ ndbinfo או sys, ודאו שגם מסדי הנתונים של הרפליקה מכילים את הטבלאות האלה של סכימות המערכת.

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

  4. מגדירים את ההגדרה server-id לערך 1 או יותר. מידע נוסף זמין במאמר אפשרויות ומשתנים של שכפול ורישום בינארי.

  5. חשוב לוודא שהערך של GTID_MODE הוא ON או OFF. לא נתמכים ערכים אחרים.

    במקרים הבאים, השירות להעברת נתונים מחייב שהערך של GTID_MODE יהיה ON:

    מידע נוסף על GTID_MODE זמין במאמר בנושא משתנה מערכת גלובלי של מזהה עסקה.

  6. מפעילים ומגדירים יומנים בינאריים במסד הנתונים של המקור. מבצעים את הפעולות הבאות:

  7. יוצרים בחשבון משתמש ייעודי להעברה. הצהרות בנושא ניהול חשבונות חשוב לוודא ש:

    • אתם מאפשרים לחשבון המשתמש הייעודי להתחבר מכל מארח (host=%).
    • הסיסמה של החשבון לא ארוכה מ-32 תווים. מידע נוסף על מגבלות אורך הסיסמה של משתמש MySQL זמין במאמר MySQL Bug #43439.

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

    פלט מנוהל

    אם רוצים ש-Database Migration Service ייצור באופן אוטומטי את קובץ ה-dump המלא של מסד הנתונים במקור, צריך להקצות לחשבון המשתמש את ההרשאות הבאות:

    פלט ידני

    אם אתם מספקים קובצי dump משלכם שנוצרו באמצעות mysqldump, אתם צריכים לספק את ההרשאות הנדרשות לשלב ה-CDC:

הגדרת מקור Amazon RDS ל-MySQL

כדי להגדיר מכונה של Amazon RDS ל-MySQL כמקור לתהליך ההעברה:

  1. ב-Amazon RDS for MySQL נעשה שימוש ב מנוע האחסון InnoDB כברירת מחדל, אבל אפשר להשתמש במנועי אחסון אחרים. מוודאים שבכל הטבלאות (חוץ מטבלאות במסדי נתונים של המערכת) נעשה שימוש במנוע האחסון InnoDB. אם אתם משתמשים במנוע אחסון אחר, יכול להיות שתצטרכו להמיר את הטבלאות. מידע נוסף זמין במאמר Converting Tables from MyISAM to InnoDB.
  2. בודקים אם מסד הנתונים של המקור מכיל מטא-נתונים שהוגדרו על ידי משתמשים באמצעות הסעיף DEFINER. אימות מטא-נתונים באמצעות משפט DEFINER

    השירות להעברת נתונים של מסדי נתונים להעברות הומוגניות של MySQL לא מעביר חשבונות משתמשים והתחברויות. מקורות שמכילים מטא-נתונים שמוגדרים על ידי חשבונות משתמשים עם הסעיף DEFINER עלולים לחסום את ההעברה.

  3. אם מסד הנתונים של המקור מכיל אובייקטים שמפנים לטבלאות בסכימות המערכת mysql,‏ performance_schema,‏ information_schema,‏ ndbinfo או sys, ודאו שגם מסדי הנתונים של הרפליקה מכילים את הטבלאות האלה של סכימות המערכת.

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

  4. חשוב לוודא שהערך של GTID_MODE מוגדר כ-ON או כ-OFF. ערכים אחרים לא נתמכים. ‫Amazon RDS ל-MySQL משתמש ב-GTID_MODE = OFF כברירת מחדל.

    צריך להגדיר את GTID_MODE ל-ON ב-Database Migration Service בתרחישים הבאים:

    מידע נוסף על GTID_MODE זמין במאמר משתנה מערכת של מזהה עסקה גלובלי.

  5. מאמתים ומגדירים יומני בינארי במסד הנתונים של המקור. מבצעים את הפעולות הבאות:

    1. מוודאים שהמכונה משתמשת בגיבויים אוטומטיים. ‫Amazon RDS יוצר יומנים בינאריים רק כשמופעלים גיבויים אוטומטיים. מידע נוסף זמין במאמר הפעלת גיבויים אוטומטיים במסמכי התיעוד של Amazon RDS.

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

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

  6. יוצרים בחשבון משתמש ייעודי להעברה. ראו דוחות ניהול חשבון. חשוב לוודא את הפרטים הבאים:

    • אתם מאפשרים לחשבון המשתמש הייעודי להתחבר מכל מארח (host=%).
    • הסיסמה של החשבון לא ארוכה מ-32 תווים. מידע נוסף על מגבלות האורך של סיסמאות משתמשים ב-MySQL זמין במאמר MySQL Bug #43439.

  7. מקצים את ההרשאות הנדרשות לחשבון המשתמש הייעודי להעברה. בהעברות רציפות, רשימת ההרשאות הנדרשות תלויה בשאלה אם אתם מספקים קובצי dump משלכם או משתמשים בתכונה של Database Migration Service לניהול קובצי dump:

    פלט מנוהל

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

    פלט ידני

    ‫אם אתם מספקים קובצי dump משלכם שנוצרו באמצעות mysqldump, אתם צריכים לספק את ההרשאות הנדרשות לשלב ה-CDC:

הגדרת מקור Amazon Aurora ל-MySQL

כדי להגדיר מכונה של Amazon Aurora ל-MySQL כמקור לתהליך ההעברה:

  1. בודקים אם מסד הנתונים של המקור מכיל מטא-נתונים שהוגדרו על ידי משתמשים באמצעות פסקה DEFINER. מידע נוסף זמין במאמר בנושא אימות מטא-נתונים באמצעות סעיף DEFINER.

    ‫Database Migration Service להעברות הומוגניות של MySQL לא מעביר חשבונות משתמשים ופרטי התחברות. מקורות שמכילים מטא-נתונים שמוגדרים על ידי חשבונות משתמשים עם הסעיף DEFINER עלולים לחסום את ההעברה.

  2. אם מסד הנתונים של המקור מכיל אובייקטים שמפנים לטבלאות בסכימות המערכת mysql,‏ performance_schema,‏ information_schema,‏ ndbinfo או sys, ודאו שגם מסדי הנתונים של הרפליקה מכילים את הטבלאות האלה של סכימות המערכת.

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

  3. חשוב לוודא שהערך של GTID_MODE מוגדר כ-ON או כ-OFF. ערכים אחרים לא נתמכים. ‫Amazon Aurora ל-MySQL משתמש ב-GTID_MODE = OFF כברירת מחדל.

    צריך להגדיר את GTID_MODE ל-ON ב-Database Migration Service בתרחישים הבאים:

    מידע נוסף על GTID_MODE זמין במאמר משתנה מערכת של מזהה עסקה גלובלי.

  4. מפעילים ומגדירים יומני בינאריים במסד הנתונים של המקור. מבצעים את הפעולות הבאות:

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

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

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

  5. יוצרים בחשבון משתמש ייעודי להעברה. הצהרות בנושא ניהול חשבונות חשוב לוודא את הפרטים הבאים:

    • אתם מאפשרים לחשבון המשתמש הייעודי להתחבר מכל מארח (host=%).
    • הסיסמה לחשבון לא ארוכה מ-32 תווים. מידע נוסף על מגבלות האורך של סיסמאות משתמשים ב-MySQL זמין במאמר MySQL Bug #43439.

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

    פלט מנוהל

    אם רוצים ש-Database Migration Service ייצור באופן אוטומטי את קובץ ה-dump המלא של מסד הנתונים במקור, צריך להקצות לחשבון המשתמש את ההרשאות הבאות:

    פלט ידני

    ‫אם אתם מספקים קובצי dump משלכם שנוצרו באמצעות mysqldump, אתם צריכים לספק את ההרשאות הנדרשות לשלב ה-CDC:

הגדרה של מקור Microsoft Azure Database for MySQL

כדי להגדיר מכונה של Microsoft Azure Database for MySQL כמקור לתהליך ההעברה:

  1. בודקים אם מסד הנתונים של המקור מכיל מטא-נתונים שהוגדרו על ידי משתמשים באמצעות פסקה DEFINER. מידע נוסף זמין במאמר בנושא אימות מטא-נתונים באמצעות סעיף DEFINER.

    השירות להעברת נתונים של מסדי נתונים להעברות הומוגניות של MySQL לא מעביר חשבונות משתמשים והתחברויות. מקורות שמכילים מטא-נתונים שהוגדרו על ידי חשבונות משתמשים עם סעיף DEFINER עשויים לחסום את ההעברה.

  2. אם מסד הנתונים של המקור מכיל אובייקטים שמפנים לטבלאות בסכימות המערכת mysql,‏ performance_schema,‏ information_schema,‏ ndbinfo או sys, ודאו שגם מסדי הנתונים של הרפליקה מכילים את הטבלאות האלה של סכימות המערכת.

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

  3. חשוב לוודא שהערך של GTID_MODE הוא ON או OFF. לא נתמכים ערכים אחרים. ב-Microsoft Azure Database for MySQL נעשה שימוש ב-GTID_MODE = OFF כברירת מחדל.

    במקרים הבאים, השירות להעברת נתונים מחייב שהערך של GTID_MODE יהיה ON:

    מידע נוסף על GTID_MODE זמין במאמר בנושא משתנה מערכת גלובלי של מזהה עסקה.

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

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

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

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

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

  5. בודקים את הערך של ההגדרה require_secure_transport.

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

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

  6. יוצרים חשבון משתמש ייעודי להעברה במכונה שלכם. הצהרות בנושא ניהול חשבונות חשוב לוודא את הפרטים הבאים:

    • אתם מאפשרים לחשבון המשתמש הייעודי להתחבר מכל מארח (host=%).
    • הסיסמה של החשבון לא ארוכה מ-32 תווים. מידע נוסף על מגבלות האורך של סיסמאות משתמשים ב-MySQL זמין במאמר MySQL Bug #43439.

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

    פלט מנוהל

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

    פלט ידני

    ‫אם אתם מספקים קובצי dump משלכם שנוצרו באמצעות mysqldump, אתם צריכים לספק את ההרשאות הנדרשות לשלב ה-CDC:

המאמרים הבאים

במאמר תחילת העבודה עם העברות של Cloud SQL ל-MySQL מוסבר שלב אחרי שלב איך מבצעים העברות הומוגניות של Cloud SQL ל-MySQL.