הגדרת עותקים משוכפלים חיצוניים

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

מידע נוסף על רפליקציה זמין במאמר מידע על רפליקציה ב-Cloud SQL.

הגדרת התצורה של העותק החיצוני

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

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

הדרישות לגבי מופע של מקור

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

הגדרת המכונה הראשית

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

    מידע על הפעלת גישה לפי כתובת IP זמין במאמר הגדרת גישה לחיבורי IP.

  3. שומרים את כתובת ה-IP הציבורית ואת כתובת ה-IP הציבורית היוצאת של המכונה הראשית לשימוש בהמשך. הערכים האלה מופיעים בדף סקירה כללית של המופע.
  4. לוחצים על סמל Cloud Shell בפינה השמאלית העליונה.
  5. בשורת הפקודה של Cloud Shell, משתמשים בלקוח MySQL המובנה כדי להתחבר למכונה הראשית: 
       
gcloud sql connect PRIMARY_INSTANCE_NAME \
--user=root
  6. מזינים את סיסמת הבסיס. אחרי זה אמורה להופיע ההודעה של mysql.
  7. יוצרים משתמש מיוחד לשכפול ומעניקים לו הרשאות שכפול: 
    CREATE USER 'REPLICATION_USER'@'%' IDENTIFIED BY 'REPLICATION_USER_PASSWORD';
GRANT REPLICATION SLAVE ON *.* TO 'REPLICATION_USER'@'%';
  8. אם מתחילים עם מסד נתונים חדש, צריך ליצור את אותו מסד נתונים ואת אותן טבלאות גם במופע הראשי וגם במופע המשוכפל. לדוגמה: 
    CREATE DATABASE test;

USE test;

CREATE TABLE replica_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO replica_test (data) VALUES ('apple'), ('banana'), ('cherry');
  9. אם כבר יש לכם מסד נתונים במופע הראשי, אתם צריכים ליצור את אותו מסד נתונים בעותק המשוכפל. כדי לעשות את זה, מייצאים את מסד הנתונים מהמופע הראשי לקטגוריה של Cloud Storage ומייבאים אותו אל העותק המשוכפל. מידע נוסף על ייצוא נתונים מ-Cloud SQL לקובץ SQL מוכן לשימוש ב-Cloud Storage

הגדרת העותק החיצוני

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

    לדוגמה, הפקודה הבאה טוענת קובץ מיוצא בשם mydump.sql:

    mysql --user=root --password < mydump.sql
  2. קובעים את מזהה השרת של זוג העותק המשוכפל והשרת הראשי.

    מזהה השרת הוא ערך מספרי (לדוגמה, '3') שצריך להיות ייחודי בהגדרת העותק החיצוני (לכל עותק צריך להיות מזהה שרת ייחודי).

  3. מוסיפים את האפשרויות הבאות לקובץ האפשרויות my.cnf של העותק: 
        [mysqld]
    server-id=[SERVER_ID]
    gtid_mode=ON
    enforce_gtid_consistency=ON
    log_slave_updates=ON
    replicate-ignore-db=mysql
    binlog-format=ROW
    log_bin=mysql-bin
    expire_logs_days=1
    read_only=ON

    מידע נוסף על אפשרויות הרפליקציה של MySQL זמין במאמרים Replication ו-Binary Logging Options.

  4. מפעילים מחדש את התהליך mysqld כדי לקרוא את קובץ התצורה.
  5. בmysql לקוח של העותק המשוכפל, מזינים את הפקודה הבאה: 
    CHANGE MASTER TO MASTER_HOST='MASTER_IP_ADDRESS', MASTER_USER='REPLICATION_USER',
MASTER_PASSWORD='REPLICATION_PASSWORD', MASTER_AUTO_POSITION=1;
  6. מתחילים את השכפול בעותק המשוכפל: 
    START SLAVE;

  7. מאשרים את סטטוס הרפליקציה:

    SHOW SLAVE STATUS\G;

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

הורדת הרמה של המופע הראשי של העתק חיצוני

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

  • העותק החיצוני הופך למופע הראשי החדש.
  • מכונת Cloud SQL הופכת לרפליקה לקריאה, שמשוכפלת מהשרת שהיה בעבר הרפליקה החיצונית (שנקרא עכשיו שרת מסד הנתונים של המקור).

כדי להפוך את ההגדרה של העותק המשוכפל החיצוני:

  1. יוצרים מופע של ייצוג מקור.

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

    gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "name": "SOURCE_REPRESENTATION_NAME",
         "region": "REGION",
         "databaseVersion": "EXTERNAL_SERVER_DATABASE_VERSION",
         "onPremisesConfiguration": {
             "hostPort": "EXTERNAL_SERVER_IP:EXTERNAL_SERVER_PORT"
         }
     }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT-ID/instances

    משתמשים באזור שבו רוצים שהרפליקה של Cloud SQL תהיה ממוקמת.

  2. מתחילים בתהליך ההורדה בדרגה.

    מכיוון שהקריאה הזו ל-API מחייבת לספק מידע רגיש, מומלץ להשתמש בקובץ JSON כדי לספק את הנתונים ל-cURL, במקום לספק אותם בשורת הפקודה.

    יוצרים את קובץ הנתונים:

    {
    "demoteMasterContext": {
        "replicaConfiguration": {
            "mysqlReplicaConfiguration": {
                "username": "REPLICATION_USERNAME",
                "password": "PASSWORD",
                "caCertificate": "EXTERNAL_SERVER_CA",
                "clientCertificate": "CLIENT_CERT",
                "clientKey": "PRIVATE_KEY"
            }
        },
        "masterInstanceName": "SOURCE_REPRESENTATION_NAME",
    },
}

    לאחר מכן, שולחים קריאה ל-API.

    curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data @PATH_TO_DATA_FILE \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT-ID/instances/INSTANCE_NAME/demoteMaster

    מידע נוסף על האפשרויות של SSL/TLS זמין במאמר בנושא אפשרויות של SSL/TLS. מידע נוסף על המאפיינים שבהם נעשה שימוש באובייקט replicaConfiguration זמין במאמר שכפול משרת חיצוני.

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

    כשהרפליקה תתעדכן, הפקודה SHOW SLAVE STATUS תציג את הערך Seconds Behind Master כ-0, והערך Executed_Gtid_Set יהיה זהה בין הרפליקה החיצונית לבין השרת הראשי של Cloud SQL.

  4. משתמשים בלקוח mysql כדי להפסיק את השכפול בעותק החיצוני: 

    STOP SLAVE
RESET SLAVE ALL

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

    הפעלת הפקודה SHOW SLAVE STATUS במכונה של Cloud SQL מספקת את סטטוס השכפול.

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

פתרון בעיות

שגיאה פתרון בעיות
הודעת שגיאה: The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires. במופע הראשי של Cloud SQL יש גיבויים אוטומטיים ויומנים בינאריים, והופעלה האפשרות לשחזור מערכת מנקודה מסוימת בזמן (PITR), כך שצריכים להיות בו מספיק יומנים כדי שהרפליקה תוכל להתעדכן. עם זאת, במקרה הזה, למרות שקיימים יומני בינאריים, העותק לא יודע מאיזו שורה להתחיל לקרוא.

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

  1. מתחברים ללקוח mysql דרך מכונה של Compute Engine.
  2. מריצים את הפקודה mysqldump ומשתמשים בדגלים --master-data=1 ו---flush-privileges.

    חשוב: אל תכללו את הדגל --set-gtid-purged=OFF.

    מידע נוסף

  3. מוודאים שקובץ ה-dump שנוצר מכיל את השורה SET @@GLOBAL.GTID_PURGED='...'.
  4. מעלים את קובץ ה-dump לקטגוריה של Cloud Storage ו מגדירים את הרפליקה באמצעות קובץ ה-dump.

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