שימוש בקובץ 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 שם המשתמש של חשבון המשתמש ב- Cloud de Confiance by S3NS .
HOST שם המארח של חשבון המשתמש ב- Cloud de Confiance by S3NS .

אימות הגדרות הרפליקציה

אחרי שמסיימים את ההגדרה, צריך לוודא שהרפליקה של 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 מזהה הפרויקט ב- Cloud de Confiance.
REPLICA_INSTANCE המזהה של הרפליקה ב-Cloud SQL.

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

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

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

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

  1. יוצרים קטגוריה של Cloud Storage ב- Cloud de Confiance.
  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 אם אתם משתמשים בגרסה של MySQL שקודמת ל-8.0.26, השתמשו ב---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. הוא מופיע במסוף Cloud de Confiance by S3NS ונראה כמו מכונה רגילה של 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 מזהה הפרויקט ב- Cloud de Confiance.
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 מזהה הפרויקט ב- Cloud de Confiance.
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 הראשוני נכשל בגלל שגיאות של זמן קצוב לתפוגה או של חיבור שאבד (לדוגמה, Dump timeout או Lost connection to MySQL server). השגיאה הזו יכולה להתרחש אם הצהרת DDL אחת או יותר יוצרת אינטראקציה עם תהליך ה-dump המקביל, וגורמת לתהליך להמתין ללא הגבלת זמן.

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

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

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

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

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

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

דברים שכדאי לנסות:

  • בודקים את מדדי הרפליקציה של מכונת הרפליקה בקטע Cloud Monitoring במסוף Cloud de Confiance .
  • השגיאות מהשרשור של MySQL IO או מהשרשור של SQL מופיעות ב-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. נכנסים למציג היומנים במסוף Cloud de Confiance .

    כניסה לדף Logs Viewer

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

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

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

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