שיטות מומלצות לייבוא וייצוא של נתונים

בדף הזה מפורטות שיטות מומלצות לייבוא וייצוא נתונים באמצעות Cloud SQL. הוראות מפורטות לייבוא נתונים ל-Cloud SQL מופיעות במאמר ייבוא נתונים.

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

שיטות מומלצות לייבוא ולייצוא

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

שימוש באותו מצב SQL לייבוא ולייצוא

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

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

כדי לוודא שהמצב הרצוי מוגדר במופע Cloud SQL, מריצים את הפקודה SELECT @@GLOBAL.sql_mode;.

לא להשתמש בקטגוריות של Cloud Storage שמוגדרות בהן בקשות בתשלום

אי אפשר להשתמש בקטגוריה של Cloud Storage שבה מופעלת התכונה מגיש הבקשה משלם לצורך ייבוא וייצוא מ-Cloud SQL.

צמצום ההשפעה של הייצוא על הביצועים

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

כדי למנוע תשובות איטיות במהלך ייצוא, אפשר:

  1. מבצעים את הייצוא מ-read replica. האפשרות הזו מתאימה אם אתם מייצאים נתונים לעיתים קרובות (פעם ביום או יותר), אבל כמות הנתונים שמיוצאת קטנה. כדי לבצע ייצוא ממופע של העתק לקריאה, משתמשים בפונקציות הייצוא של Google Cloud המסוףgcloud או של REST API במופע של העתק לקריאה. מידע נוסף על יצירה וניהול של רפליקות לקריאה זמין במאמר יצירת רפליקות לקריאה.

  2. משתמשים בייצוא ללא שרת. בייצוא ללא שרת, Cloud SQL יוצר מכונה נפרדת זמנית כדי להפחית את העומס על המכונה הראשית שפעולת הייצוא יוצרת. העברת פעולת הייצוא מאפשרת למסדי נתונים במופע הראשי להמשיך להציג שאילתות ולבצע פעולות בקצב הביצועים הרגיל. בסיום ייצוא הנתונים, המופע הזמני נמחק באופן אוטומטי. זו יכולה להיות אפשרות טובה אם אתם מייצאים מסד נתונים גדול באופן חד-פעמי. כדי לבצע פעולת ייצוא בלי שרת (serverless), משתמשים ב Google Cloud Console, ב-gcloud או ב-API בארכיטקטורת REST פונקציות ייצוא עם הדגל offload.

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

    בטבלה הבאה מפורטות הפעולות שאפשר לחסום בזמן שמופעל ייצוא בלי שרת (serverless):
    הפעולה הנוכחית פעולה חדשה חסום?
    כל פעולה ייצוא ללא שרת כן
    ייצוא ללא שרת כל פעולה חוץ מייצוא ללא שרת לא
    כל פעולה חוץ מייצוא ללא שרת כל פעולה חוץ מייצוא ללא שרת כן

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

שימוש בדגלים הנכונים כשיוצרים קובץ SQL מוכן לשימוש

אם לא משתמשים בדגלים הנכונים כשמייצאים את הנתונים לקובץ SQL dump, יכול להיות שהייבוא ייכשל. מידע על יצירת קובץ SQL מוכן לשימוש לייבוא ל-Cloud SQL זמין במאמר יצירת קובץ SQL מוכן לשימוש.

דחיסת נתונים כדי להפחית את העלות

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

כשמייצאים קובץ SQL dump או קובץ CSV, צריך להשתמש ב.gz סיומת קובץ כדי לדחוס את הנתונים. כשמייבאים קובץ עם סיומת של .gz, הוא נפרס באופן אוטומטי.

צמצום תהליכי ייבוא וייצוא ארוכים

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

  • אי אפשר לעצור פעולה של מופע Cloud SQL שפועלת במשך זמן רב.
  • אפשר לבצע רק פעולת ייבוא או ייצוא אחת בכל פעם לכל מופע, וייבוא או ייצוא לזמן רב חוסמים פעולות אחרות, כמו גיבויים יומיים אוטומטיים. ייצוא ללא שרת (serverless) מאפשר להפעיל פעולות אחרות, כולל עריכת מופעים, ייבוא, מעבר לגיבוי בעת כשל וביטול חסימה של גיבויים אוטומטיים יומיים.

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

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

טיפים נוספים זמינים במאמר אבחון בעיות במופעים של Cloud SQL.

שימוש ב-InnoDB

‫InnoDB הוא מנוע האחסון היחיד שנתמך במופעי MySQL.

אפשר להמיר את הטבלאות מ-MyISAM ל-InnoDB על ידי העברת הפלט של mysqldump דרך סקריפט sed באופן הבא:

mysqldump --databases [DATABASE_NAME] \
-h [INSTANCE_IP] -u [USERNAME] -p [PASSWORD] \
--hex-blob --default-character-set=utf8mb4 | sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' > [DATABASE_FILE].sql

משימות ייבוא והעברה של MySQL שמכילות מטא נתונים עם סעיף DEFINER

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

כדי לזהות אילו ערכים של DEFINER קיימים במטא-נתונים, משתמשים בשאילתות הבאות (או מחפשים בקובץ ה-dump) ובודקים אם יש רשומות של root%localhost או של משתמשים שלא קיימים במופע היעד.

SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.EVENTS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.ROUTINES;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.TRIGGERS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.VIEWS;

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

  • צריך ליצור את המשתמשים במכונת היעד של Cloud SQL לפני שמתחילים את עבודת הייבוא או ההעברה.
  • לפני שמתחילים את משימת הייבוא או ההעברה, צריך לעדכן את הסעיף DEFINER ל-INVOKER במופע המקור של MySQL או בקובץ ה-dump.

אימות מסד הנתונים שיובא

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

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

רשימה של מגבלות מוכרות מופיעה במאמר בנושא בעיות בייבוא ובייצוא של נתונים.

אוטומציה של פעולות ייצוא

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

פתרון בעיות

בקטעים הבאים מוסבר איך לפתור בעיות שקשורות לפעולות ייבוא וייצוא.

פתרון בעיות בפעולות ייבוא

שגיאה פתרון בעיות
HTTP Error 409: Operation failed because another operation was already in progress. כבר יש פעולה בהמתנה למכונה. מותר לבצע רק פעולה אחת בכל פעם. כדאי לנסות לשלוח את הבקשה אחרי שהפעולה הנוכחית תסתיים.
פעולת הייבוא נמשכת יותר מדי זמן. יותר מדי חיבורים פעילים עלולים להפריע לפעולות ייבוא.

סוגרים פעולות שלא בשימוש. כדאי לבדוק את המעבד (CPU) ואת השימוש בזיכרון במכונת Cloud SQL כדי לוודא שיש מספיק משאבים זמינים. הדרך הטובה ביותר לוודא שמשימת הייבוא מקבלת את מרב המשאבים היא להפעיל מחדש את המכונה לפני התחלת הפעולה.

הפעלה מחדש:

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

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

פעולות שכדאי לנסות:

מוסיפים את השורה הבאה בתחילת קובץ ה-dump:

SET FOREIGN_KEY_CHECKS=0;

בנוסף, מוסיפים את השורה הבאה בסוף קובץ ה-dump:

SET FOREIGN_KEY_CHECKS=1;

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

פתרון בעיות בפעולות ייצוא

שגיאה פתרון בעיות
HTTP Error 409: Operation failed because another operation was already in progress. כבר יש פעולה בהמתנה למכונה. מותר לבצע רק פעולה אחת בכל פעם. כדאי לנסות לשלוח את הבקשה אחרי שהפעולה הנוכחית תסתיים.
HTTP Error 403: The service account does not have the required permissions for the bucket. מוודאים שהקטגוריה קיימת ושלחשבון השירות של מכונת Cloud SQL (שמבצעת את הייצוא) הוקצה התפקיד Storage Object Creator (roles/storage.objectCreator) כדי לאפשר ייצוא לקטגוריה. תפקידי IAM ל-Cloud Storage
ייצוא ה-CSV פעל אבל ייצוא ה-SQL נכשל. פורמטים של CSV ו-SQL מיוצאים באופן שונה. בפורמט SQL מיוצא כל מסד הנתונים, ולכן סביר להניח שהייצוא יימשך זמן רב יותר. בפורמט CSV אפשר להגדיר אילו רכיבים במסד הנתונים ייכללו בייצוא.

שימוש בייצוא ל-CSV כדי לייצא רק את מה שצריך.
הייצוא נמשך יותר מדי זמן. ‫Cloud SQL לא תומך בפעולות סינכרוניות מקבילות.

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

אפשר ליצור מערכת ייצוא אוטומטית משלכם באמצעות Google Cloudמוצרים כמו Cloud Scheduler,‏ Pub/Sub ופונקציות Cloud Run, בדומה למאמר הזה בנושא גיבוי אוטומטי.

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