כדי לשפר את הביצועים, להוזיל את עלויות האחסון ולמנוע שיבושים תפעוליים כשמעבירים נתונים אל AlloyDB ל-PostgreSQL או ממנו, כדאי לפעול לפי השיטות המומלצות הבאות:
- אל תשתמשו בקטגוריות של Cloud Storage שמופעלת בהן התכונה מגיש הבקשה משלם לצורך ייבוא או ייצוא.
- כשיוצרים קובץ SQL מוכן לשימוש, צריך להשתמש בדגלים הנכונים.
- דחיסת נתונים כדי להפחית את העלות.
- כדי לקצר תהליכי ייבוא וייצוא ארוכים, כדאי לעבד את הנתונים באצוות.
- מאמתים את מסד הנתונים המיובא אחרי הייבוא.
לא להשתמש בקטגוריות של Cloud Storage שמוגדרות עם "מגיש הבקשה משלם"
אי אפשר להשתמש בקטגוריה של Cloud Storage שבה מופעלת התכונה "מגיש הבקשה משלם" לצורך ייבוא וייצוא מ-AlloyDB. כדי לייבא ולייצא, ב-AlloyDB נעשה שימוש בחשבון שירות שמנוהל על ידי Google, שנקרא סוכן שירות. לסוכן הזה בדרך כלל אין את ההקשר או ההגדרות האישיות כדי לחייב את הפרויקט של מגיש הבקשה על גישה לנתונים, ולכן פעולות שכוללות קטגוריות מסוג "המשתמש משלם" נכשלות.
שימוש בדגלים הנכונים כשיוצרים קובץ SQL מוכן לשימוש
אם לא תשתמשו בדגלים ובאפשרויות הנכונים כשאתם מייצאים נתונים לקובץ SQL מוכן לשימוש, יכול להיות שהייבוא ייכשל. למידע על ייצוא נתונים לייבוא ל-AlloyDB, ראו ייצוא קובץ DMP וייצוא קובץ SQL.
דחיסת נתונים כדי להפחית את העלות
ב-AlloyDB אפשר לייבא ולייצא קובצי .gz דחוסים מ-Cloud Storage. דחיסה יכולה לחסוך הרבה מקום אחסון ב-Cloud Storage ולהפחית את עלויות האחסון, במיוחד כשמייצאים כמויות גדולות של נתונים. כשמייצאים קובץ dump של SQL או קובץ CSV באמצעות AlloyDB API, צריך להשתמש בסיומת הקובץ .gz ב-URI של היעד כדי לדחוס את הנתונים. כשמייבאים קובץ עם הסיומת .gz, הקובץ נפתח באופן אוטומטי.
צמצום תהליכי ייבוא וייצוא ארוכים
בהתאם לגודל הנתונים, יכול להיות שייקח הרבה זמן לייבא נתונים ל-AlloyDB ולייצא נתונים ממנו. אם פעולה נמשכת יותר מדי זמן, היא עלולה לחסום פעולות אחרות.
כדי לקצר את הזמן שנדרש להשלמת כל פעולה, כדאי להשתמש בקבוצות קטנות יותר של נתונים. אפשר גם להשתמש בכלי pg_dump כדי לבצע ייצוא ידני מלקוח שמחובר למכונה של מאגר לקריאה בלבד.
אימות מסד הנתונים המיובא
אחרי שפעולת הייבוא מסתיימת, מתחברים למסד הנתונים באמצעות psql או לקוח אחר, ומריצים פקודות מתאימות כדי לוודא שהתוכן נכון, כמו הצגת טבלאות או שליחת שאילתות על מספר השורות.
אוטומציה של פעולות ייצוא
ב-AlloyDB אין שיטה מובנית לאוטומציה של ייצוא, אבל אתם יכולים ליצור כלי אוטומציה באמצעות רכיבים אחרים שלGoogle Cloud , כמו Cloud Scheduler, Pub/Sub ופונקציות Cloud Run.
פתרון בעיות
בקטע הזה מפורטים תיקונים מוצעים לבעיות שאתם עשויים להיתקל בהן בפעולות ייבוא וייצוא.
פעולות ייבוא
| שגיאה | תיאור | תיקון מומלץ |
|---|---|---|
ERROR: permission denied for schema public |
ב-PostgreSQL מגרסה 15 ואילך, יכול להיות שהייבוא של הנתונים ייכשל בגלל הרשאות סכימה אם יוצרים את מסד הנתונים של היעד מ-template0. |
כדי לפתור את הבעיה, משתמשים בפקודה הבאה כדי לתת הרשאות בסכימה
GRANT ALL ON SCHEMA public TO IMPORT_USER;
|
| פעולת הייבוא נמשכת יותר מדי זמן. | יותר מדי חיבורים פעילים יכולים להפריע לפעולות הייבוא. |
נסו:
|
| פעולת ייבוא נכשלת כי משתמש אחד או יותר שמצוינים בקובץ ה-dump לא קיימים. | לפני שמייבאים קובץ dump, כל המשתמשים במסד הנתונים שיש בבעלותם אובייקטים או שקיבלו הרשאות לאובייקטים במסד הנתונים שהושלך חייבים להיות קיימים במסד הנתונים של היעד. אם הם לא קיימים, פעולת הייבוא לא תצליח ליצור מחדש את האובייקטים עם הבעלות או ההרשאות המקוריות. | לפני הייבוא, צריך ליצור את משתמשי מסד הנתונים הנדרשים. |
GRANT stderr: ERROR: must be member of role ROLE_NAME
|
השגיאה הזו יכולה להתרחש אם מייבאים קובץ SQL מוכן לשימוש שמכיל אובייקטים בבעלות ROLE_NAME, או הרשאות שניתנו ל-ROLE_NAME, אבל משתמש מסד הנתונים שמבצע את הייבוא לא חבר ב-ROLE_NAME. |
כדי לפתור את הבעיה, צריך לוודא שהתפקיד ROLE_NAME קיים במסד הנתונים של היעד, ולהעניק חברות ב-ROLE_NAME למשתמש שמבצע את הייבוא לפני שמפעילים את הייבוא. |
פעולות ייצוא
| שגיאה | תיאור | תיקון מומלץ |
|---|---|---|
HTTP Error 403: The service account does not have the required
permissions for the bucket. |
לחשבון השירות של AlloyDB אין את ההרשאות הנדרשות לקטגוריית היעד. | מוודאים שקטגוריית היעד של Cloud Storage קיימת, ושלחשבון השירות של AlloyDB הוקצו התפקידים roles/storage.objectAdmin או roles/storage.objectCreator. התפקידים האלה מאפשרים לכתוב בקטגוריה. למידע נוסף, קראו את המאמר תפקידים בניהול זהויות והרשאות גישה (IAM) ל-Cloud Storage.
|
| הייצוא ל-CSV הצליח, אבל הייצוא ל-SQL נכשל. | יש הבדל בין ייצוא בפורמט CSV לבין ייצוא בפורמט SQL. בפורמט SQL, המערכת מייצאת את הסכימה ואת הנתונים של מסד הנתונים, ובדרך כלל התהליך נמשך יותר זמן. בפורמט CSV, מיוצאים רק הנתונים שמתקבלים משאילתת SELECT שאתם מספקים. |
אם הייצוא של SQL נכשל או איטי מדי, אפשר לייצא טבלאות נפרדות באמצעות CSV. |
| הייצוא נמשך יותר מדי זמן. | אם הייצוא נמשך יותר מדי זמן במכונה הראשית, יכול להיות שהייצוא גדול מדי. | כדאי לייצא את הנתונים בקבוצות קטנות יותר. לדוגמה, לייצא טבלאות בנפרד במקום לייצא מסד נתונים שלם בפעולה אחת. אפשר גם להשתמש בכלי pg_dump כדי לבצע ייצוא ידני מלקוח שמחובר למכונה של מאגר קריאה.
|
שגיאת Create Extension ביומן של pg_restore או שהייבוא נכשל. |
קובץ ה-dump מכיל הפניות לתוסף PostgreSQL שלא נתמך ב-AlloyDB, או שלא מותקן באשכול. | כדי להסיר את ההפניות, עורכים את קובץ ה-dump או מתקינים את התוסף באשכול, אם AlloyDB תומך בו. |
שגיאה בשימוש ב-pg_dumpall. |
יכול להיות שהכלי pg_dumpall עם דגלים כמו --globals-only ידרוש הרשאות שלא זמינות ב-AlloyDB. |
כדי לייצא אובייקטים גלובליים כמו משתמשים ותפקידים בלי סיסמאות, משתמשים בפקודה הבאה כדי לכלול את הדגל
pg_dumpall --globals-only --no-role-passwords
|
הזמן הקצוב לתפוגה של פעולת הייצוא מסתיים או שמופיעה השגיאה Connection reset by peer. |
אם Cloud Storage לא מקבל נתונים בפרק זמן מסוים, החיבור יכול להתאפס. זה יכול לקרות אם השאילתות הראשוניות במסד הנתונים שנדרשות לייצוא נמשכות יותר מדי זמן. | במקרה כזה, נסו לבצע ייצוא ידני באמצעות הכלי pg_dump מלקוח שמחובר למכונה של מאגר קריאה. |
בעיות נפוצות
| שגיאה | תיאור | תיקון מומלץ |
|---|---|---|
HTTP Error 409: Operation failed because another operation was
already in progress. |
המערכת מאפשרת רק פעולת ייבוא או ייצוא אחת מבוססת-API בכל פעם. | כדאי לנסות לשלוח את הבקשה אחרי שהפעולה הנוכחית תסתיים. |
המאמרים הבאים
- ייבוא נתונים באמצעות קובצי dump.
- ייצוא נתונים באמצעות קובצי dump.
- ייבוא נתונים באמצעות קובצי CSV
- ייצוא נתונים באמצעות קובצי CSV.
- ייבוא נתונים באמצעות קובצי SQL.
- ייצוא נתונים באמצעות קובצי SQL.
- הפעלת גיבויים אוטומטיים.
- שחזור מהגיבוי.