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

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

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

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

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

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

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

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

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

אל תשתמשו בקטגוריות של Cloud Storage עם התכונה "מגיש הבקשה משלם"

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

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

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

כדי למנוע תגובות איטיות במהלך הייצוא, אתם יכולים:

  1. מייצאים מרפליקה לקריאה בלבד. האפשרות הזו מתאימה אם אתם מייצאים נתונים לעיתים קרובות (מדי יום או יותר), אבל כמות הנתונים שאתם מייצאים קטנה. כדי לייצא מרפליקה לקריאה בלבד, משתמשים בפונקציות הייצוא של Cloud de Confiance by S3NS מסוף Cloud,‏ gcloud או API בארכיטקטורת REST במכונה של הרפליקה לקריאה בלבד. במאמר יצירת רפליקות לקריאה בלבד מוסבר איך יוצרים ומנהלים רפליקות לקריאה בלבד.

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

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

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

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

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

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

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

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

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

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

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

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

פתרון בעיות

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

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

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

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

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