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

בדף הזה מוסבר איך להגדיר מופע של 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. במכונה שמארחת את הרפליקה, יוצרים seed למכונת 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 and 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.

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