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

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

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

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

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

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

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

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

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

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

   במאמר הגדרת גישה לקישורים דרך IP מוסבר איך מפעילים גישה ל-IP.

3. שומרים את כתובת ה-IP הציבורית ואת כתובת ה-IP הציבורית לתעבורה יוצאת של המכונה הראשית, כדי להשתמש בהן בהמשך. אפשר למצוא את הערכים האלה בדף Overview של המכונה.
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 זמין במאמר אפשרויות רפליקציה ורישום ביומן בינארי.

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;
   

   אם מופיעה ההודעה "Waiting for master to send event", הרפליקציה פועלת.

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

אם יש לכם מכונה של 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 חדש באמצעות הגדרות הדגל הנכונות, ומגדירים את הרפליקה החיצונית באמצעות הקובץ הזה. מתחברים ללקוח MySQL באמצעות מכונה של Compute Engine. מריצים את mysqldump ומשתמשים בדגלים --master-data=1 ו---flush-privileges. חשוב: אל תכללו את הדגל --set-gtid-purged=OFF. מידע נוסף מוודאים שקובץ ה-dump שנוצר מכיל את השורה SET @@GLOBAL.GTID_PURGED='...'. מעלים את קובץ ה-dump לקטגוריה של Cloud Storage ומגדירים את הרפליקה באמצעות קובץ ה-dump.

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

• איך מנהלים רפליקות
• מידע נוסף על רפליקציה ב-Cloud SQL
• מידע נוסף על רפליקציה של MySQL
• מידע נוסף על אפשרויות הרפליקציה
• מידע נוסף על בדיקת סטטוס הרפליקציה
• מידע נוסף על שכפול משרת חיצוני