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

‫MySQL   |  PostgreSQL   |  SQL Server

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

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

לפני שמתחילים

לפני שמתחילים, צריך לבצע את השלבים הבאים:

1. מגדירים את השרת החיצוני.

2. יוצרים את מופע הייצוג של המקור.

3. מגדירים את העותק המשוכפל של Cloud SQL.

אימות הגדרות השכפול

אחרי שתסיימו את ההגדרה, תוודאו שהרפליקה של Cloud SQL יכולה לשכפל מהשרת החיצוני.

ההגדרות הבאות של סנכרון חיצוני צריכות להיות נכונות.

• קישוריות בין העותק המשוכפל של Cloud SQL לבין שרת חיצוני
• הרשאות משתמש לשכפול
• תאימות גרסאות
• השכפול של העותק המשוכפל ב-Cloud SQL לא מתבצע כבר

כדי לוודא שההגדרות האלה נכונות, פותחים טרמינל של Cloud Shell ומזינים את הפקודות הבאות:

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "selectedObjects": "SELECTED_OBJECTS"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/verifyExternalSyncSettings

דוגמה

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal",
         "selectedObjects":[{"database":"db1"}, {"database":"db2"}]
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/myreplica/verifyExternalSyncSettings

הקריאות האלה מחזירות רשימה מהסוג sql#externalSyncSettingErrorList.

אם הרשימה ריקה, אין שגיאות. תגובה ללא שגיאות נראית כך:

  {
    "kind": "sql#externalSyncSettingErrorList"
  }

מאפיין (property)	תיאור
SYNC_MODE	חשוב לוודא שאפשר לשמור על סנכרון בין העותק המשוכפל של Cloud SQL לבין השרת החיצוני אחרי שמגדירים את השכפול. מצבי הסנכרון כוללים את EXTERNAL_SYNC_MODE_UNSPECIFIED,‏ ONLINE ו-OFFLINE.
SYNC_PARALLEL_LEVEL	בודקים את ההגדרה שקובעת את המהירות שבה מועברים נתונים מטבלאות של מסד נתונים. הערכים הבאים זמינים: ‫min: משתמש בכמות הכי נמוכה של משאבי מחשוב במסד הנתונים. זו המהירות הכי איטית להעברת נתונים. optimal: מספק ביצועים מאוזנים עם עומס אופטימלי על מסד הנתונים. max: מספק את המהירות הגבוהה ביותר להעברת נתונים, אבל זה עלול לגרום לעומס מוגבר על מסד הנתונים. הערה: ערך ברירת המחדל של הפרמטר הזה הוא optimal, כי ההגדרה הזו מספקת מהירות טובה להעברת הנתונים וההשפעה שלה על מסד הנתונים סבירה. מומלץ להשתמש בערך הזה.
SELECTED_OBJECTS	רשימה מופרדת בפסיקים של אובייקטים, שמציינת מסדי נתונים שאתם מעבירים ממופע ייצוג המקור למופע היעד של Cloud SQL. אם לא משתמשים בפרמטר הזה או שמספקים רשימה ריקה כערך של הפרמטר, כל מסדי הנתונים מועברים מהמקור ליעד.
PROJECT_ID	המזהה של Google Cloud הפרויקט.
REPLICA_INSTANCE_ID	המזהה של העותק המשוכפל ב-Cloud SQL.

עדכון של מופע ייצוג מקור

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

source.json

    {
      "name": "SOURCE_NAME",
      "region": "REGION",
      "databaseVersion": "DATABASE_VERSION",
      "onPremisesConfiguration": {
        "selectedObjects": "SELECTED_OBJECTS",
        "username": "USERNAME",
        "password": "PASSWORD"
      }
    }

דוגמה

// example of source.json for external server that
// - initiates replication from a Cloud SQL managed import
// - doesn't use SSL/TLS

{
  "name": "cloudsql-source-instance",
  "region": "us-central1",
  "databaseVersion": "POSTGRES_9_6",
  "onPremisesConfiguration": {
    "selectedObjects":[{"database":"db1"}, {"database":"db3"}],
    "username": "newReplicationUser",
    "password": "525#@%*@"
  }
}

מאפיין (property)	תיאור
SOURCE_NAME	השם של מופע ייצוג המקור.
REGION	האזור שבו נמצא מופע הייצוג של המקור.
DATABASE_VERSION	גרסת מסד הנתונים שפועלת בשרת החיצוני. האפשרויות הן POSTGRES_9_6,‏ POSTGRES_10,‏ POSTGRES_11,‏ POSTGRES_12,‏ POSTGRES_13,‏ POSTGRES_14,‏ POSTGRES_15,‏ POSTGRES_16 או POSTGRES_17.
SELECTED_OBJECTS	רשימה מעודכנת של אובייקטים מופרדים בפסיקים, שמציינת את מסדי הנתונים שאתם מעבירים ממופע הייצוג של המקור למופע היעד של Cloud SQL.
USERNAME	חשבון המשתמש של השכפול בשרת החיצוני.
PASSWORD	הסיסמה לחשבון.

כדי לשנות את מכונת הייצוג של המקור ב-Cloud SQL, פותחים טרמינל ב-Cloud Shell ומזינים את הפקודות הבאות:

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data @JSON_PATH \
     -X PATCH \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/SOURCE_NAME

דוגמה

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data @./source.json \
     -X PATCH \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/cloudsql-source-instance

מאפיין (property)	תיאור
JSON_PATH	הנתיב לקובץ JSON שמכיל את נתוני הבקשה לשרת החיצוני.
PROJECT_ID	המזהה של Google Cloud הפרויקט.
SOURCE_NAME	השם של מופע ייצוג המקור.

התחלת השכפול בשרת החיצוני

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

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "skipVerification": "SKIP_VERIFICATION",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/startExternalSync

דוגמה

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync

מאפיין (property)	תיאור
SYNC_MODE	מוודאים שאפשר לשמור על סנכרון בין הרפליקה של Cloud SQL לבין השרת החיצוני אחרי שהרפליקציה מוגדרת.
SKIP_VERIFICATION	האם לדלג על שלב האימות המובנה לפני סנכרון הנתונים. מומלץ להשתמש בפרמטר הזה רק אם כבר אימתתם את הגדרות השכפול.
SYNC_PARALLEL_LEVEL	הוספת הגדרה שקובעת את מהירות ההעברה של נתונים מטבלאות במסד נתונים. הערכים הבאים זמינים: ‫min: משתמש בכמות הכי נמוכה של משאבי מחשוב במסד הנתונים. זו המהירות הכי איטית להעברת נתונים. optimal: מספק ביצועים מאוזנים עם עומס אופטימלי על מסד הנתונים. max: מספק את המהירות הגבוהה ביותר להעברת נתונים, אבל זה עלול לגרום לעומס מוגבר על מסד הנתונים. הערה: ערך ברירת המחדל של הפרמטר הזה הוא optimal, כי ההגדרה הזו מספקת מהירות טובה להעברת הנתונים וההשפעה שלה על מסד הנתונים סבירה. מומלץ להשתמש בערך הזה.
PROJECT_ID	המזהה של Google Cloud הפרויקט.
REPLICA_INSTANCE_ID	המזהה של העותק המשוכפל ב-Cloud SQL.

מעקב אחרי ההעברה

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

פתרון בעיות

כדאי לנסות את האפשרויות הבאות לפתרון בעיות:

שגיאה	פתרון בעיות
השכפול של העותק לקריאה לא התחיל בזמן היצירה.	סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
אי אפשר ליצור עותק לקריאה – השגיאה invalidFlagValue.	אחד מהדגלים בבקשה לא תקין. יכול להיות שזה דגל שציינתם באופן מפורש או דגל שהוגדר לו ערך ברירת מחדל. קודם כול, בודקים שהערך של הדגל max_connections גדול מהערך בשרת הראשי או שווה לו. אם הדגל max_connections מוגדר בצורה מתאימה, בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
לא ניתן ליצור עותק לקריאה – שגיאה לא ידועה.	סביר להניח שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל. אם השגיאה היא set Service Networking service account as servicenetworking.serviceAgent role on consumer project, אפשר ליצור באופן ידני את חשבון השירות הנדרש על ידי ביצוע ההוראות במאמר יצירה והקצאה של תפקידים לסוכני שירות.
הדיסק מלא.	יכול להיות שהנפח של הדיסק של המופע הראשי יתמלא במהלך יצירת העותק. עורכים את המופע הראשי כדי לשדרג אותו לגודל דיסק גדול יותר.
נפח האחסון בדיסק גדל באופן משמעותי.	אם משתמשים במשבצת שלא משמשת באופן פעיל למעקב אחרי נתונים, מערכת PostgreSQL שומרת על פלחי WAL ללא הגבלת זמן, וכך גודל נפח האחסון גדל ללא הגבלה. אם משתמשים בתכונות logical replication and decoding ב-Cloud SQL, משבצות השכפול נוצרות ומוסרות באופן אוטומטי. אפשר לזהות משבצות שכפול שלא נעשה בהן שימוש על ידי שליחת שאילתה לתצוגת המערכת pg_replication_slots וסינון לפי העמודה active. אפשר להשתמש בפקודה pg_drop_replication_slot כדי להסיר פלחים של WAL.
מופע הרפליקה משתמש ביותר מדי זיכרון.	הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמבוקשות לעיתים קרובות, מה שיכול לגרום לה להשתמש ביותר זיכרון מהמופע הראשי. מפעילים מחדש את מופע הרפליקה כדי לפנות את המקום הזמני בזיכרון.
השכפול הופסק.	הגעתם למגבלת האחסון המקסימלית, ולא הפעלתם את האפשרות להגדלת נפח האחסון באופן אוטומטי. עורכים את המופע כדי להפעיל את automatic storage increase.
ההשהיה בשכפול גבוהה באופן עקבי.	עומס הכתיבה גבוה מדי בשביל העותק. השהיית שכפול מתרחשת כשהשרשור של SQL בעותק לא מצליח לעמוד בקצב של שרשור הקלט/פלט. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום להשהיה גבוהה זמנית או קבועה בשכפול של סכימה נתונה. חלק מהסיבות האופייניות לעיכוב בשכפול: שאילתות איטיות בעותק המשוכפל. צריך לאתר את הבעיות ולתקן אותן. לכל הטבלאות צריך להיות מפתח ייחודי או מפתח ראשי. כל עדכון בטבלה כזו בלי מפתח ייחודי או ראשי גורם לסריקות מלאות של הטבלה ברפליקה. שאילתות כמו DELETE ... WHERE field < 50000000 גורמות לפיגור בשכפול עם שכפול מבוסס-שורות, כי מספר עצום של עדכונים מצטבר בעותק המשוכפל. הנה כמה פתרונות אפשריים: עורכים את המופע כדי להגדיל את הגודל של העותק המשוכפל. הפחתת העומס על מסד הנתונים. הפניית תנועת קריאה אל העותק לקריאה בלבד. יוצרים אינדקס לטבלאות. זיהוי ותיקון של שאילתות כתיבה איטיות. יוצרים את העותק המשוכפל מחדש.
שגיאות כשמבצעים בנייה מחדש של אינדקסים ב-PostgreSQL 9.6.	קיבלתם שגיאה מ-PostgreSQL שמציינת שצריך לבנות מחדש אינדקס מסוים. אפשר לעשות את זה רק במופע הראשי. אם תיצרו מכונת רפליקה חדשה, תקבלו שוב את אותה השגיאה תוך זמן קצר. אינדקסים של Hash לא מועברים לרפליקות בגרסאות PostgreSQL מתחת ל-10. אם אתם חייבים להשתמש באינדקסים של hash, אתם צריכים לשדרג ל-PostgreSQL 10 ומעלה. אחרת, אם אתם רוצים להשתמש גם בעותקים משוכפלים, אל תשתמשו באינדקסים של hash ב-PostgreSQL 9.6.
השאילתה במופע הראשי תמיד פועלת.	אחרי שיוצרים העתק, השאילתה SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' אמורה לפעול באופן רציף במופע הראשי.
יצירת העותק נכשלה בגלל פסק זמן.	עסקאות ארוכות טווח שלא בוצעו במופע הראשי עלולות לגרום לכשל ביצירת רפליקה לקריאה. אחרי שמפסיקים את כל השאילתות הפעילות, יוצרים מחדש את העותק.
אם למופע הראשי ולרפליקה יש גדלים שונים של vCPU, יכול להיות שיהיו בעיות בביצועי השאילתות, כי כלי האופטימיזציה של השאילתות לוקח בחשבון את הגדלים של vCPU.	כדי לפתור את הבעיה, מבצעים את השלבים הבאים: מפעילים את הדגל log_duration ומגדירים את הפרמטר log_statement לערך ddl. כך תוכלו לראות את השאילתות ואת זמן הריצה במסד הנתונים. עם זאת, בהתאם לעומס העבודה, יכול להיות שהפעולה הזו תגרום לבעיות בביצועים. גם במופע הראשי וגם בעותק לקריאה, מריצים את הפקודה explain analyze עבור השאילתות. משווים את תוכנית לביצוע שאילתה ומחפשים הבדלים. אם זו שאילתה ספציפית, צריך לשנות אותה. לדוגמה, אפשר לשנות את הסדר של פעולות ה-join כדי לראות אם הביצועים משתפרים.

בדיקת יומני השכפול

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

כדי לראות את היומנים האלה:

1. נכנסים לכלי Logs Viewer במסוף Google Cloud .

   כניסה לדף Logs Viewer

2. בתפריט הנפתח Instance (מופע), בוחרים את העותק המשוכפל של Cloud SQL.
3. בוחרים את קובץ היומן replication-setup.log.

אם העותק המשוכפל של Cloud SQL לא מצליח להתחבר לשרת החיצוני, צריך לוודא את הדברים הבאים:

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

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

• מידע נוסף על עדכון של מופע
• מידע נוסף על ניהול עותקים משוכפלים
• מידע נוסף על מעקב אחרי מופעים
• מידע נוסף על קידום הרפליקה של Cloud SQL