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

‫MySQL | PostgreSQL | SQL Server

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פתרון בעיות

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

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

שגיאה	פתרון בעיות
הודעת שגיאה: `permission denied for schema public`	ב-PostgreSQL בגרסה 15 ואילך, אם מסד הנתונים של היעד נוצר מ-`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`. כדי לפתור את הבעיה, מבצעים את השלבים הבאים: יוצרים את התפקיד `ROLE_NAME` במסד הנתונים של היעד שאליו מייבאים את קובץ SQL מוכן לשימוש. אל תשתמשו במשתמש `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 מפעיל מכונה להפחתת עומס כדי לבצע את הייצוא. לייצוא offloading יש כמה יתרונות, כולל שיפור הביצועים במופע המקור וביטול החסימה של פעולות אדמיניסטרטיביות בזמן שהייצוא פועל. אם משתמשים בהעברת עומס לייצוא, זמן האחזור הכולל עשוי להתארך בפרק הזמן שנדרש להפעלת מופע העברת העומס. בדרך כלל, בייצוא בגודל סביר, זמן האחזור לא משמעותי. עם זאת, אם הייצוא קטן מספיק, יכול להיות שתבחינו בעלייה בחביון.
שגיאה ביצירת התוסף.	קובץ ה-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 אין אפשרות לייצא באופן אוטומטי. אפשר לבנות מערכת ייצוא אוטומטית משלכם באמצעות מוצרים כמו Cloud Scheduler,‏ Pub/Sub ופונקציות Cloud Run, בדומה למאמר הזה בנושא גיבויים אוטומטיים. Google Cloud