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

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

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

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

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

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

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

לקוח MySQL 

    UPDATE mysql.user
      SET Host='NEW_HOST'
      WHERE Host='OLD_HOST'
      AND User='USERNAME';
      GRANT REPLICATION SLAVE, EXECUTE
      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
      ON *.* TO 'gcp_user'@'gmail.com';
    FLUSH PRIVILEGES;
מאפיין (property) תיאור
NEW_HOST מציינים את כתובת ה-IP היוצאת של העותק המשוכפל של Cloud SQL.
OLD_HOST הערך הנוכחי שמוקצה למאפיין Host שרוצים לשנות.
USERNAME חשבון המשתמש של השכפול בשרת החיצוני.
GCP_USERNAME שם המשתמש בחשבון המשתמש ב Google Cloud פלטפורמה (GCP).
HOST שם המארח של חשבון המשתמש בפלטפורמה (GCP). Google Cloud

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

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

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

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

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

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"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE/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",
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/myreplica/verifyExternalSyncSettings
מאפיין (property) תיאור
SYNC_MODE ‫verifyExternalSyncSettings מוודא שאפשר לשמור את העותק המשוכפל של Cloud SQL ואת השרת החיצוני מסונכרנים אחרי שההעתקה מוגדרת. מצבי הסנכרון כוללים EXTERNAL_SYNC_MODE_UNSPECIFIED, ONLINE ו-OFFLINE.
SKIP_VERIFICATION האם לדלג על שלב האימות המובנה לפני סנכרון הנתונים. מומלץ רק אם כבר אימתתם את הגדרות השכפול.
PROJECT_ID המזהה של הפרויקט ב- Google Cloud.
REPLICA_INSTANCE המזהה של העותק המשוכפל ב-Cloud SQL.

ייצוא מסד הנתונים לקטגוריה של Cloud Storage

אפשר לאכלס רפליקה של Cloud SQL באמצעות קובץ mysqldump שנמצא בקטגוריה של Cloud Storage. התנאים האלה חלים:

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

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

  1. ב- Google Cloud, יוצרים קטגוריה של Cloud Storage.
  2. פותחים טרמינל באמצעות לקוח שמתחבר לשרת מסד הנתונים החיצוני ומריצים את הפקודה הבאה.

mysqldump 

    mysqldump \
        --host=EXTERNAL_HOST \
        --port=EXTERNAL_PORT \
        --user=USERNAME\
        --password=PASSWORD \
        --databases=DATABASE_LIST  \
        --hex-blob \
        SOURCE_DATA  \
        --no-autocommit \
        --default-character-set=utf8mb4 \
        --single-transaction \
        --set-gtid-purged=on \
        ADD_DROP_TABLE \
        ROUTINES \
        COMPRESS \
        GZIP \
        | gcloud storage cp - gs://BUCKET/DUMP_FILENAME

דוגמה 

    mysqldump \
        --host=192.0.2.1 \
        --port=3306 \
        --user=replicationUser \
        --password \
        --databases guestbook journal \
        --hex-blob \
        --master-data=1 \
        --no-autocommit \
        --default-character-set=utf8mb4 \
        --single-transaction \
        --compress \
        | gzip \
        | gcloud storage cp - gs://replica-bucket/external-database.sql.gz
מאפיין (property) תיאור
EXTERNAL_HOST כתובת ה-IPv4 או ה-DNS של השרת החיצוני.
EXTERNAL_PORT היציאה של השרת החיצוני. אם השרת החיצוני מתארח ב-Cloud SQL, הערך הוא 3306.
USERNAME השם של חשבון המשתמש לשכפול או של חשבון המשתמש בשרת החיצוני שיש לו הרשאות קריאה במסד הנתונים.
PASSWORD סיסמת משתמש השכפול.
DATABASE_LIST רשימה של כל מסדי הנתונים בשרת החיצוני, מופרדים ברווחים, למעט מסדי הנתונים של המערכת (sys, ‏ mysql, ‏ performance_schema ו-information_schema). אפשר להשתמש בפקודה SHOW DATABASES MySQL כדי להציג את מסדי הנתונים.
SOURCE_DATA אם אתם משתמשים בגרסה מוקדמת יותר מ-8.0.26 של MySQL, אז צריך להשתמש בערך --master-data לפרמטר הזה. בגרסאות של MySQL מגרסה 8.0.26 ואילך, מגדירים את הערך של הפרמטר הזה ל---source-data.
ADD_DROP_TABLE אם רוצים להוסיף הצהרת DROP TABLE לפני כל הצהרת CREATE TABLE, צריך לכלול את --add-drop-table.
ROUTINES אם רוצים להציג את התרחישים המאוחסנים, כמו פרוצדורות ופונקציות, בפלט של מסדי הנתונים שנוצרו, צריך לכלול את --routines.
COMPRESS אם רוצים לדחוס את כל המידע שנשלח בין העותק המשוכפל של Cloud SQL לבין השרת החיצוני, משתמשים ב---compress.
GZIP אם רוצים לדחוס עוד יותר את קובץ ה-dump, משתמשים ב-| gzip. אם מסד הנתונים שלכם מכיל נתונים שלא ניתן לדחוס, כמו נתונים בינאריים שלא ניתן לדחוס או תמונות JPG, אל תשתמשו באפשרות הזו.
BUCKET שם הקטגוריה שיצרתם בשלב 1 כדי שתכיל את קובץ ה-dump.
DUMP_FILENAME נוצר קובץ בשם הזה בקטגוריה. הקובץ הזה מכיל את התוכן של מסד הנתונים בשרת החיצוני שלכם.

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

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

הקובץ source.json מכיל מידע על מופע הייצוג של המקור.

REST 

{
  "name": "PRIMARY_INSTANCE_NAME",
  "region": "REGION_NAME",
  "databaseVersion": "DB_NAME_AND_VERSION",
  "onPremisesConfiguration": {
    "hostPort": "IP_ADDRESS_AND_PORT",
    "selectedObjects": "SELECTED_OBJECTS",
    "username": "USERNAME",
    "password": "PASSWORD"
  },
  "dumpFilePath" :"DUMP_FILE_PATH"
}

דוגמה 

{
  "name": "cloudsql-source-instance",
  "region": "us-central1",
  "databaseVersion": "MYSQL_5_7",
  "onPremisesConfiguration": {
    "hostPort": "192.0.2.0:3306",
    "selectedObjects":[{"database":"db1"}, {"database":"db3"}],
    "username": "replicationUser",
    "password": "486#@%*@"
  },
  "dumpFilePath" :"gs://replica-bucket/source-database.sql.gz"
}
מאפיין (property) תיאור
PRIMARY_INSTANCE_NAME השם של מופע Cloud SQL שמשויך למופע של ייצוג המקור.
REGION_NAME השם של האזור שמוקצה למופע של ייצוג המקור.
DB_NAME_AND_VERSION השם ומספר הגרסה של מסד הנתונים שמשויך למופע של ייצוג המקור.
IP_ADDRESS_AND_PORT כתובת ה-IP ומספר היציאה ששמורים למופע של ייצוג המקור.
SELECTED_OBJECTS רשימה מעודכנת של אובייקטים מופרדים בפסיקים, שמציינת את מסדי הנתונים שאתם מעבירים ממופע הייצוג של המקור למופע היעד של Cloud SQL.
USERNAME שם המשתמש של מופע הייצוג של המקור.
PASSWORD הסיסמה של מופע ייצוג המקור.
DUMP_FILE_PATH הנתיב של קובץ ה-dump שמכיל את התוכן של מסד הנתונים בשרת החיצוני.

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

REST 

    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_REPRESENTATION_INSTANCE

דוגמה 

    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 שמאוחסן בקטגוריה של Cloud Storage. הקובץ הזה מכיל נתונים על מופע ייצוג המקור.
PROJECT_ID המזהה של הפרויקט ב- Google Cloud.
SOURCE_REPRESENTATION_INSTANCE השם של מופע ייצוג המקור.

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

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

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

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

REST 

  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"
         }' \
       -X POST \
       https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/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",
             "skipVerification": false
           }' \
         -X POST \
         https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync
מאפיין (property) תיאור
SYNC_MODE מוודאים שאפשר לשמור על סנכרון בין העותק המשוכפל של Cloud SQL לבין השרת החיצוני אחרי שמגדירים את השכפול.
SKIP_VERIFICATION האם לדלג על שלב האימות המובנה לפני סנכרון הנתונים. מומלץ רק אם כבר אימתתם את הגדרות השכפול.
PROJECT_ID המזהה של הפרויקט ב- Google Cloud.
REPLICA_INSTANCE המזהה של העותק המשוכפל ב-Cloud SQL.

פינוי מקום באחסון

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

להמשיך בשכפול

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

פתרון בעיות

שגיאה פתרון בעיות
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 במסוף Google Cloud .
  • השגיאות משרשור הקלט/פלט או משרשור ה-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 במסוף Google Cloud .

    כניסה לדף Logs Viewer

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

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

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

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