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

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

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

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

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

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

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

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

עדכון ההרשאות של משתמש השכפול

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

הרשאות נדרשות

יש ארבעה סוגים של שילובים של העברות וגיבויים.

  • סוג 1: העברה רציפה וגיבוי מנוהל
  • סוג 2: העברה רציפה ופריקה ידנית
  • סוג 3: העברה חד-פעמית ופריקה מנוהלת
  • סוג 4: העברה חד-פעמית ופריקה ידנית

בהמשך מפורטות ההרשאות לכל שילוב של סוג העברה וסוג גיבוי.

סוג 1

לחשבון המשתמש צריכות להיות ההרשאות הבאות:

ב-MySQL מגרסה 8.0 ואילך, מומלץ לדלג על ההרשאה BACKUP ADMIN כדי לקבל ביצועים אופטימליים.

Type 2

לחשבון המשתמש צריכות להיות ההרשאות הבאות:

סוג 3

לחשבון המשתמש צריכות להיות ההרשאות הבאות:

ב-MySQL גרסה 8.0 ואילך, מומלץ לדלג על ההרשאה BACKUP ADMIN כדי לקבל ביצועים אופטימליים.

סוג 4

לא נדרשות הרשאות.

עדכון הרשאות

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

לקוח MySQL

ל-GTID:

    UPDATE mysql.user
      SET Host='NEW_HOST'
      WHERE Host='OLD_HOST'
      AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
    RELOAD ON . TO
    'USERNAME'@'HOST';
    FLUSH PRIVILEGES;

עבור binlog:

    UPDATE mysql.user
    SET Host='NEW_HOST'
    WHERE Host='OLD_HOST'
    AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
    RELOAD ON . TO 'GCP_USERNAME'@'HOST';
    FLUSH PRIVILEGES;

דוגמה

UPDATE mysql.user
  SET Host='192.0.2.0'
  WHERE Host='%'
  AND User='replicationUser';
GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
RELOAD ON *.* TO 'username'@'host.com';
FLUSH PRIVILEGES;
מאפיין (property) תיאור
NEW_HOST מציינים את כתובת ה-IP היוצאת של העותק המשוכפל של Cloud SQL.
OLD_HOST הערך הנוכחי שמוקצה ל-Host שרוצים לשנות.
USERNAME חשבון המשתמש של השכפול בשרת החיצוני.
GCP_USERNAME שם המשתמש של חשבון המשתמש.
HOST שם המארח של חשבון המשתמש.

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

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

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

  • קישוריות בין העותק המשוכפל של Cloud SQL לבין שרת חיצוני
  • הרשאות משתמש לשכפול
  • תאימות גרסאות
  • השכפול של העותק המשוכפל ב-Cloud SQL לא מתבצע כבר
  • הפעלת binlog בשרת חיצוני
  • אם אתם מנסים לבצע סנכרון חיצוני משרת חיצוני של RDS ומשתמשים בדלי Cloud de Confiance ,

כדי לוודא שההגדרות האלה נכונות, פותחים טרמינל ב-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",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -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

דוגמה עם סימוני סנכרון

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"}],
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/verifyExternalSyncSettings

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

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

  {
    "kind": "sql#externalSyncSettingErrorList"
  }
מאפיין (property) תיאור
SYNC_MODE מוודאים שאפשר לשמור על סנכרון בין הרפליקה של Cloud SQL לבין השרת החיצוני אחרי שמגדירים את השכפול. מצבי הסנכרון כוללים את EXTERNAL_SYNC_MODE_UNSPECIFIED,‏ ONLINE ו-OFFLINE.
SYNC_PARALLEL_LEVEL

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

  • min: שימוש בכמות הכי נמוכה של משאבי מחשוב במסד הנתונים. זו המהירות הכי איטית להעברת נתונים.
  • optimal: מספק ביצועים מאוזנים עם עומס אופטימלי על מסד הנתונים.
  • max: מספק את המהירות הגבוהה ביותר להעברת נתונים, אבל זה עלול לגרום לעומס מוגבר על מסד הנתונים.

הערה: ערך ברירת המחדל של הפרמטר הזה הוא optimal כי ההגדרה הזו מספקת מהירות טובה להעברת הנתונים, וההשפעה שלה על מסד הנתונים סבירה. מומלץ להשתמש בערך הזה.

SYNC_FLAGS רשימה של דגלים של סנכרון ראשוני לאימות. מומלץ רק אם אתם מתכננים להשתמש בדגלי סנכרון מותאמים אישית כשאתם משכפלים מהמקור. רשימה של הדגלים המותרים מופיעה במאמר דגלים של סנכרון ראשוני.
SELECTED_OBJECTS רשימה מופרדת בפסיקים של אובייקטים, שמציינת מסדי נתונים שאתם מעבירים ממופע ייצוג המקור למופע היעד של Cloud SQL. אם לא משתמשים בפרמטר הזה או שמספקים רשימה ריקה כערך של הפרמטר, כל מסדי הנתונים מועברים מהמקור ליעד.
PROJECT_ID המזהה של Cloud de Confiance הפרויקט.
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 גרסת מסד הנתונים שפועלת בשרת החיצוני. האפשרויות הן MYSQL_5_6,‏ MYSQL_5_7,‏ MYSQL_8_0 או MYSQL_8_4
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 המזהה של Cloud de Confiance הפרויקט.
SOURCE_NAME השם של מופע ייצוג המקור.

הרשאת נעילה גלובלית לקריאה

אם אין לכם הרשאה לגשת לנעילת הקריאה הגלובלית בשרת החיצוני, כמו במקרה של Amazon RDS ו-Amazon Aurora, צריך להשהות את פעולות הכתיבה לשרת לפי השלבים הבאים:

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

       DUMP_IMPORT(START): Start importing data, please pause any write to the
       external primary database.
    
  4. אם רואים את רשומת היומן הבאה בכלי Logs Explorer, צריך להפעיל מחדש את הכתיבה למסד הנתונים בשרת החיצוני.

       DUMP_IMPORT(SYNC): Consistent state on primary and replica. Writes to the
       external primary may resume.
    

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

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

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

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",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -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

דוגמה עם סימוני סנכרון

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"
         "skipVerification": false,
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -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 כי ההגדרה הזו מספקת מהירות טובה להעברת הנתונים, וההשפעה שלה על מסד הנתונים סבירה. מומלץ להשתמש בערך הזה.

SYNC_FLAGS רשימה של דגלים של סנכרון ראשוני לאימות. מומלץ רק אם אתם מתכננים להשתמש בדגלי סנכרון מותאמים אישית כשאתם משכפלים מהמקור. רשימה של הדגלים המותרים מופיעה במאמר דגלים של סנכרון ראשוני.
PROJECT_ID המזהה של Cloud de Confiance הפרויקט.
REPLICA_INSTANCE_ID המזהה של העותק המשוכפל ב-Cloud SQL.

התרעות לגבי סנכרון ראשוני

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

  • --add-drop-database
  • --add-drop-table
  • --add-drop-trigger
  • --add-locks
  • --allow-keywords
  • --all-tablespaces
  • --apply-slave-statements
  • --column-statistics
  • ‫--comments
  • ‫--compact
  • ‎--compatible
  • --complete-insert
  • ‫--compress
  • --compression-algorithms
  • --create-options
  • --default-character-set
  • --delayed-insert
  • --disable-keys
  • --dump-date
  • ‫--events
  • --extended-insert
  • --fields-enclosed-by
  • --fields-escaped-by
  • --fields-optionally-enclosed-by
  • --fields-terminated-by
  • --flush-logs
  • --flush-privileges
  • ‫‎--force
  • --get-server-public-key
  • --hex-blob
  • --ignore-error
  • --ignore-read-lock-error
  • --ignore-table
  • --insert-ignore
  • --lines-terminated-by
  • --lock-all-tables
  • --lock-tables
  • --max-allowed-packet
  • --net-buffer-length
  • --network-timeout
  • --no-autocommit
  • --no-create-db
  • --no-create-info
  • --no-data
  • --no-defaults
  • --no-set-names
  • --no-tablespaces
  • ‫--opt
  • --order-by-primary
  • ‫--pipe
  • --quote-names
  • ‫--quick
  • ‫--replace
  • ‫--routines
  • --secure-auth
  • --set-charset
  • --shared-memory-base-name
  • --show-create-skip-secondary-engine
  • --skip-opt
  • --ssl-cipher
  • --ssl-fips-mode
  • --ssl-verify-server-cert
  • --tls-ciphersuites
  • --tls-version
  • ‫--triggers
  • --tz-utc
  • ‫‎--verbose
  • ‎--xml
  • --zstd-compression-level

הערכים המותרים מפורטים במסמכי המידע הציבוריים של MySQL.

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

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

פתרון בעיות

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

שגיאה פתרון בעיות
השכפול של העותק לקריאה לא התחיל בזמן היצירה. כנראה שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.
אי אפשר ליצור עותק לקריאה – השגיאה invalidFlagValue. אחד מהדגלים בבקשה לא תקין. יכול להיות שזה דגל שציינתם באופן מפורש או דגל שהוגדר לו ערך ברירת מחדל.

קודם כול, בודקים שהערך של הדגל max_connections גדול מהערך בשרת הראשי או שווה לו.

אם הדגל max_connections מוגדר בצורה מתאימה, בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.

לא ניתן ליצור עותק לקריאה – שגיאה לא ידועה. כנראה שיש שגיאה ספציפית יותר בקובצי היומן. בודקים את היומנים ב-Cloud Logging כדי למצוא את השגיאה בפועל.

אם השגיאה היא: set Service Networking service account as servicenetworking.serviceAgent role on consumer project, צריך להשבית ואז להפעיל מחדש את Service Networking API. הפעולה הזו יוצרת את חשבון השירות שנדרש כדי להמשיך בתהליך.

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

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

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

עורכים את המופע כדי להפעיל את automatic storage increase.

ההשהיה בשכפול גבוהה באופן עקבי. עומס הכתיבה גבוה מדי בשביל העותק. השהיית שכפול מתרחשת כשה-SQL thread בעותק לא מצליח לעמוד בקצב של ה-IO thread. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום לעיכובים זמניים או קבועים בשכפול של סכימה נתונה. חלק מהסיבות האופייניות לעיכוב בשכפול:
  • שאילתות איטיות בעותק המשוכפל. צריך לאתר את הבעיות ולתקן אותן.
  • לכל הטבלאות צריך להיות מפתח ייחודי או מפתח ראשי. כל עדכון בטבלה כזו ללא מפתח ייחודי או ראשי גורם לסריקות מלאות של הטבלה ברפליקה.
  • שאילתות כמו DELETE ... WHERE field < 50000000 גורמות לפיגור בשכפול בשכפול מבוסס-שורות, כי מספר עצום של עדכונים מצטבר בעותק המשוכפל.

הנה כמה פתרונות אפשריים:

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

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

  • פיצול העסקה לכמה עסקאות קטנות
  • פיצול שאילתת כתיבה גדולה אחת לקבוצות קטנות יותר
  • כדאי להפריד שאילתות SELECT ארוכות מטרנזקציה שכוללת גם פקודות DML
שינוי של דגלים של שכפול מקביל גורם לשגיאה. הוגדר ערך שגוי לאחד או יותר מהסימונים האלה.

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

  1. משנים את הדגלים binlog_transaction_dependency_tracking ו-transaction_write_set_extraction:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. מוסיפים את הדגל slave_pending_jobs_size_max:

    slave_pending_jobs_size_max=33554432

  3. משנים את הדגל transaction_write_set_extraction:

    transaction_write_set_extraction=XXHASH64

  4. משנים את הדגל binlog_transaction_dependency_tracking:

    binlog_transaction_dependency_tracking=WRITESET

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

יוצרים מחדש את העותק אחרי שמפסיקים את כל השאילתות הפעילות.

בנוסף, אם אתם משתמשים ב-MySQL, כדאי לשקול גם את האפשרויות הבאות:

שגיאה פתרון בעיות
Lost connection to MySQL server during query when dumping table. יכול להיות שהמקור הפך ללא זמין, או שה-dump הכיל מנות גדולות מדי.

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

מידע נוסף על שימוש בדגלים mysqldump להעברת ייבוא מנוהל זמין במאמר דגלים מותרים ודגלי ברירת מחדל לסנכרון ראשוני

הגיבוי הראשוני נכשל בגלל שגיאות שקשורות לזמן קצוב לתפוגה או לחיבור שאבד (לדוגמה, Dump timeout או Lost connection to MySQL server). השגיאה הזו יכולה להתרחש אם הצהרת DDL אחת או יותר מבצעת אינטראקציה עם תהליך ה-dump המקביל, וגורמת לתהליך להמתין ללא הגבלת זמן.

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

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

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

מוודאים שדגלי השכפול, כמו binlog-do-db,‏ binlog-ignore-db,‏ replicate-do-db או replicate-ignore-db, לא מוגדרים בצורה שיוצרת התנגשות.

מריצים את הפקודה show master status במופע הראשי כדי לראות את ההגדרות הנוכחיות.

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

פעולות שכדאי לנסות:

  • בודקים את מדדי השכפול של מופע הרפליקה בקטע Cloud Monitoring במסוף Cloud de Confiance .
  • השגיאות משרשור הקלט/פלט או משרשור ה-SQL של MySQL מופיעות בCloud Logging בקובצי היומן mysql.err.
  • השגיאה יכולה להופיע גם כשמתחברים למופע המשוכפל. מריצים את הפקודה SHOW REPLICA STATUS ובודקים את השדות הבאים בפלט:
    • Replica_IO_Running
    • Replica_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error

אם מופיעה השגיאה Unknown database DATABASE_NAME on query. Error_code: MY-001049, המשמעות היא שהשכפול נכשל כי הצהרת SQL משוכפלת ניסתה להפנות למסד נתונים שלא נבחר להעברה. כדי לשחזר את השכפול, צריך לקבוע אם השגיאה מבוססת על הודעה שנובעת מ-DDL באחד מהאובייקטים הבאים:

  • אירוע או פעולה שגרתית. אפשר להריץ את הפקודה CALL mysql.skipReplicationError() ברפליקה, וכך למנוע את השכפול של האירוע או השגרה ולהמשיך את השכפול.
  • אילוץ או תצוגה של מפתח זר. אחרי שקובעים באיזה מסד נתונים נמצא האובייקט ששונה על ידי ההצהרה, יש שתי אפשרויות לשחזור. אפשר להסיר את מסד הנתונים ממסדי הנתונים שנבחרו להעברה, או להריץ את הפקודה CALL mysql.skipReplicationError() על העותק המשוכפל כדי להמשיך את השכפול תוך דילוג על האילוץ או על ההפצה של התצוגה לעותק המשוכפל.
mysqld check failed: data disk is full. דיסק הנתונים של מופע הרפליקה מלא.

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

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

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

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

  1. נכנסים אל Logs Viewer במסוף Cloud de Confiance .

    כניסה לדף Logs Viewer

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

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

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

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