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

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

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

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

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

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

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

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

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

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

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

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

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

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

שימוש בדגלים הנכונים כשיוצרים קובץ 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.

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

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

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

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

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

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

פתרון בעיות

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

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

שגיאה פתרון בעיות
הודעת שגיאה: permission denied for schema public בגרסאות 15 ואילך של PostgreSQL, אם מסד הנתונים של היעד נוצר מ-template0, יכול להיות שייבוא הנתונים ייכשל. כדי לפתור את הבעיה, צריך להריץ את פקודת ה-SQL‏ GRANT ALL ON SCHEMA public TO cloudsqlsuperuser כדי לתת למשתמש cloudsqlsuperuser הרשאות לסכימה ציבורית.
HTTP Error 409: Operation failed because another operation was already in progress. כבר יש פעולה בהמתנה במכונה. מותר לבצע פעולה אחת בלבד בכל פעם. כדאי לנסות לשלוח את הבקשה אחרי שהפעולה הנוכחית תסתיים.
פעולת הייבוא נמשכת יותר מדי זמן. יותר מדי חיבורים פעילים יכולים להפריע לפעולות הייבוא.

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

הפעלה מחדש:

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

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

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

כדי לפתור את הבעיה, אחרי שמייבאים נתונים, משביתים את האפשרות "שחזור מערכת מנקודה מסוימת בזמן (PITR)" אם רוצים למחוק יומנים ולפנות נפח אחסון. חשוב לזכור שהקטנת נפח האחסון שבשימוש לא מקטינה את נפח האחסון שהוקצה למכונה.
הודעת שגיאה: GRANT stderr: ERROR: must be member of role ROLE_NAME

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

‫ROLE_NAME הוא תפקיד מותאם אישית במסד הנתונים שמוגדר במסד הנתונים של PostgreSQL במקור. משתמש ברירת המחדל cloudsqlsuperuser מייבא את קובץ ה-SQL המוכן לשימוש. עם זאת, יכול להיות שהמשתמש הזה לא שייך לתפקיד ROLE_NAME.

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

  1. יוצרים את התפקיד ROLE_NAME במסד הנתונים של היעד שאליו מייבאים את קובץ ה-SQL המוכן לשימוש.

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

    gcloud sql import sql INSTANCE URI [--async]
    [--database=DATABASE, -d DATABASE] [--user=USER] [GCLOUD_WIDE_FLAG …]

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

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

עורכים את קובץ ה-dump כדי להסיר את ההפניות.
שגיאה בשימוש ב-pg_dumpall. כדי להשתמש בכלי pg_dumpall עם הדגל --global צריך את התפקיד "משתמש-על", אבל התפקיד הזה לא נתמך ב-Cloud SQL ל-PostgreSQL. כדי למנוע שגיאות במהלך פעולות ייצוא שכוללות שמות משתמשים, צריך להשתמש גם בדגל --no-role-passwords.
פעולת הייצוא מסתיימת לפני שמתבצע ייצוא, ומופיעה הודעת השגיאה Could not receive data from client: Connection reset by peer. אם Cloud Storage לא מקבל נתונים בפרק זמן מסוים, בדרך כלל כ-7 דקות, החיבור מתאפס. יכול להיות שהרצת השאילתה הראשונית של הייצוא נמשכת יותר מדי זמן.

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

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

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