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

בדף הזה מוסבר על השיטות המומלצות לייבוא וייצוא של נתונים באמצעות 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 או של API בארכיטקטורת REST במופע של העתקה לקריאה. מידע נוסף על יצירה וניהול של רפליקות לקריאה זמין במאמר יצירת רפליקות לקריאה.

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

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

    בטבלה הבאה מפורטות הפעולות שאפשר לחסום בזמן שמופעל ייצוא בלי שרת (serverless):
    הפעולה הנוכחית פעולה חדשה חסום?
    כל פעולה ייצוא ללא שרת כן
    ייצוא ללא שרת כל פעולה חוץ מייצוא בלי שרת (serverless) לא
    כל פעולה חוץ מייצוא בלי שרת (serverless) כל פעולה חוץ מייצוא בלי שרת (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 עם קבוצות קטנות יותר של נתונים.

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

טיפים נוספים זמינים במאמר אבחון בעיות במופעים של 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 מפעיל מכונה להפחתת עומס כדי לבצע את הייצוא. לייצוא offloading יש כמה יתרונות, כולל שיפור הביצועים במופע המקור וביטול החסימה של פעולות אדמיניסטרטיביות בזמן שהייצוא פועל. אם משתמשים בהעברת עומס לייצוא, זמן האחזור הכולל עשוי להתארך בפרק הזמן שנדרש להפעלת מופע העברת העומס. בדרך כלל, בייצוא בגודל סביר, זמן האחזור לא משמעותי. עם זאת, אם הייצוא קטן מספיק, יכול להיות שתבחינו בעלייה בחביון.
אתם רוצים שהייצוא יהיה אוטומטי. ב-Cloud SQL אין אפשרות לייצא באופן אוטומטי.

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

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