הגדרת Cloud SQL והשרת החיצוני לשכפול

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

חלופה לשלבים שמתוארים בדף הזה היא Database Migration Service, שמאפשר רפליקציה רציפה או העברה חד-פעמית של מסד נתונים משרת חיצוני ל-Cloud SQL.

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

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

הסברים על המונחים

• שרת חיצוני. שרת MySQL החיצוני ל-Cloud SQL שממנו רוצים לשכפל נתונים. הוא נקרא גם מסד הנתונים של המקור או שרת מסד הנתונים החיצוני. הוא יכול להיות מכונה אחרת של Cloud SQL או כל שרת אחר של מסד נתונים, כמו שרת מקומי או Amazon Relational Database Service (RDS).

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

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

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

• ייבוא מנוהל. תהליך הייבוא של נתונים ישירות מהשרת החיצוני לרפליקה של Cloud SQL. במצב כזה, Cloud SQL מתחבר לשרת החיצוני באמצעות חשבון המשתמש של הרפליקה, ומריץ את ה-dump של הנתונים ישירות בשרת החיצוני כדי לייבא נתונים לרפליקה של Cloud SQL.

הגדרת פרויקט ב- Cloud de Confiance

1. In the Cloud de Confiance console, on the project selector page, select or create a Cloud de Confiance project.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

   Go to project selector

2. Verify that billing is enabled for your Cloud de Confiance project.

3. Enable the Cloud SQL Admin API, if it is not already enabled.

   Roles required to enable APIs

   To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

   Enable the API

4. חשוב לוודא שבחשבון המשתמש שלכם מוגדרים התפקידים "אדמין של Cloud SQL", "אדמין של Storage" ו"צפייה ב-Compute".

   כניסה לדף IAM

התקנת ה-SDK של Cloud de Confiance

כדי להגדיר את הרפליקציה, מתקינים את ה-SDK של Cloud de Confiance בשרת החיצוני. אם ה-SDK לא מותקן במקום אחר, כדאי להתקין אותו בשרת החיצוני.

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

רשימת משימות לשרת חיצוני

• מוודאים שבשרת החיצוני מותקנת אחת מהגרסאות הבאות: MySQL 5.7,‏ MySQL 8.0,‏ MySQL 8.4 או MySQL 9.7. אפשר להשתמש ב-MySQL Community Edition, ב-Cloud SQL ל-MySQL, ב-Amazon Aurora, ב-MySQL ב-Amazon RDS וב-Microsoft Azure Database ל-MySQL Flexible Server.

  • גרסת ה-MySQL הראשית ברפליקה של Cloud SQL צריכה להיות זהה לגרסת ה-MySQL שפועלת בשרת החיצוני, או גרסה חדשה יותר.
  • אם בשרת החיצוני מותקנת גרסה 5.5 של MySQL, אין תמיכה ב-GTID.

• מוודאים שהיומנים הבינאריים מופעלים וגם:

  • רישום ביומן בינארי מבוסס-שורות.
  • היומנים הבינאריים נשמרים למשך תקופה ארוכה מספיק כדי לתמוך בהעברת מסד הנתונים. בדרך כלל מספיק לחכות שבוע.

• בודקים אם בשרת החיצוני מופעל GTID. זה משפיע על השלבים שצריך לבצע כדי להגדיר את הרפליקציה.

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

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

  חומת האש של שרת מסד הנתונים של המקור צריכה להיות מוגדרת כך שתאפשר את כל טווח כתובות ה-IP הפנימיות שהוקצה לחיבור לשירות הפרטי של רשת ה-VPC שבה משתמש מכון היעד של Cloud SQL, בתור השדה privateNetwork של הגדרות ה-ipConfiguration שלו.

  כדי למצוא את טווח כתובות ה-IP הפנימיות:

  1. במסוף Cloud de Confiance , נכנסים לדף רשתות VPC.

     כניסה לדף VPC networks

  2. בוחרים את רשת ה-VPC שבה רוצים להשתמש.

  3. לוחצים על הכרטיסייה Private service connection.

• אם השרת החיצוני מכיל משפטי DEFINER (תצוגות, אירועים, טריגרים או פרוצדורות מאוחסנות), יכול להיות שהשכפול ייכשל, בהתאם לסדר שבו המשפטים האלה מופעלים. מידע נוסף על השימוש ב-DEFINER ועל פתרונות חלופיים אפשריים ב-Cloud SQL

• ‫InnoDB הוא מנוע האחסון היחיד שנתמך ב-Cloud SQL. העברה באמצעות MyISAM עלולה לגרום לחוסר עקביות בנתונים, וצריך לאמת את הנתונים. למידע נוסף, קראו את המאמר Converting tables from MyISAM to InnoDB במסמכי התיעוד של MySQL.

הגדרת שמירה של יומנים בינאריים

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

call mysql.rds_set_configuration('binlog retention ', HOURS);

יצירת חשבון משתמש לרפליקציה

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

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

      CREATE USER 'USERNAME'@'%' IDENTIFIED BY 'PASSWORD';
      GRANT SELECT, SHOW VIEW ON *.* TO 'USERNAME'@'HOST';
      FLUSH PRIVILEGES;

CREATE USER 'replicationUser'@'%' IDENTIFIED BY '8*&fwwd';
GRANT SELECT, SHOW VIEW ON *.* TO 'replicationUser'@'%';
FLUSH PRIVILEGES;

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

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

יצירת נתוני הבקשה

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

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

    {
      "name": "SOURCE_NAME",
      "region": "REGION",
      "databaseVersion": "DATABASE_VERSION",
      "onPremisesConfiguration": {
        "selectedObjects": "SELECTED_OBJECTS",
        "hostPort": "SOURCE_HOST",
        "username": "USERNAME",
        "password": "PASSWORD",
        "caCertificate": "SOURCE_CERT",
        "clientCertificate": "CLIENT_CERT",
        "clientKey": "CLIENT_KEY"
      }
    }

// example of source.json for external server that
// - initiates replication from a Cloud SQL managed import
// - doesn't use SSL/TLS

{
  "name": "cloudsql-source-instance",
  "region": "us-central1",
  "databaseVersion": "MYSQL_5_7",
  "onPremisesConfiguration": {
    "selectedObjects":[{"database":"db1"}, {"database":"db2"}],
    "hostPort": "192.0.2.0:3306",
    "username": "replicationUser",
    "password": "486#@%*@"
  }
}

// example of source.json for external server that
// - initiates replication from a file
// - uses SSL/TLS

{
  "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",
    "caCertificate": "content of your certificate",
    "clientCertificate": "content of your certificate",
    "clientKey": "content of your client key",
    "sslOption": "REQUIRE"
  }
}

// example of source.json for external server that
// - initiates replication from a Cloud SQL custom import
// - uses SSL/TLS

{
  "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#@%*@",
    "sslOption": "REQUIRE"
  }
}

יצירת מופע של ייצוג מקור

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

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

    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 POST \
         https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT-ID/instances

    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 POST \
         https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances

עדכון של מופע ייצוג של מקור

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

שינוי נתוני הבקשה

מעדכנים את נתוני הבקשה כך שיכללו את כל השדות שהשתנו. השדות האלה כוללים את hostPort,‏ username,‏ password,‏ caCertificate,‏ clientCertificate ו-clientKey. אחרי שמעדכנים את נתוני הבקשה, משתמשים בהם בפקודה curl כדי לעדכן את המכונה ב-Cloud SQL.

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

בדוגמה הבאה מוצג עדכון של השדות username ו-password עם שם משתמש וסיסמה שונים:

    {
      "name": "SOURCE_NAME",
      "region": "REGION",
      "databaseVersion": "DATABASE_VERSION",
      "onPremisesConfiguration": {
        "selectedObjects": "SELECTED_OBJECTS",
        "username": "NEW_USERNAME",
        "password": "NEW_PASSWORD"
      }
    }

// example of source.json for external server that
// - initiates replication from a Cloud SQL managed import
// - doesn't use SSL/TLS

{
  "name": "cloudsql-source-instance",
  "region": "us-central1",
  "databaseVersion": "MYSQL_5_7",
  "onPremisesConfiguration": {
    "selectedObjects":[{"database":"db1"}, {"database":"db3"}],
    "username": "newReplicationUser",
    "password": "525#@%*@"
  }
}

// example of source.json for external server that
// - initiates replication from a file
// - uses SSL/TLS

{
  "name": "cloudsql-source-instance",
  "region": "us-central1",
  "databaseVersion": "MYSQL_5_7",
  "onPremisesConfiguration": {
    "selectedObjects":[{"database":"db1"}, {"database":"db3"}],
    "username": "newReplicationUser",
    "password": "486#@%*@"
  }
}

// example of source.json for external server that
// - initiates replication from a Cloud SQL custom import
// - doesn't use SSL/TLS

{
  "name": "cloudsql-source-instance",
  "region": "us-central1",
  "databaseVersion": "MYSQL_5_7",
  "onPremisesConfiguration": {
    "selectedObjects":[{"database":"db1"}, {"database":"db3"}],
    "username": "newReplicationUser",
    "password": "486#@%*@"
  }
}

שינוי מופע של ייצוג מקור

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

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

    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_NAME

    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

הגדרת רפליקה של Cloud SQL

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

יצירת נתוני הבקשה

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

    {
        "settings": {
            "tier": "TIER",
            "dataDiskSizeGb": "DISK_SIZE",
            "ipConfiguration": {
                "ipv4Enabled": "PUBLIC_IP_STATUS",
                "privateNetwork": "projects/PROJECT_ID/global/networks/NETWORK_NAME"
             },
             "availabilityType": "AVAILABILITY_TYPE"
        },
        "masterInstanceName": "SOURCE_REPRESENTATION_INSTANCE_NAME",
        "region": "SOURCE_REGION",
        "databaseVersion": "DATABASE_VERSION",
        "name": "REPLICA_NAME"
    }

    {
        "settings": {
            "tier": "db-custom-4-15360",
            "dataDiskSizeGb": "100"
        },
        "masterInstanceName": "source-instance",
        "region": "us-central1",
        "databaseVersion": "MYSQL_8_0",
        "name": "replica-instance"
    }

יצירת הרפליקה של Cloud SQL

לפני שמתחילים את השלב הזה, יוצרים קובץ JSON שמכיל את נתוני הבקשה לרפליקה. כדי ליצור רפליקה של Cloud SQL, פותחים טרמינל של Cloud Shell ומריצים את הפקודות הבאות:

    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 POST \
         https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT-ID/instances

    gcloud auth login
    ACCESS_TOKEN="$(gcloud auth print-access-token)"
    curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
         --header 'Content-Type: application/json' \
         --data @./replica.json \
         -X POST \
         https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances

אימות ההגדרה

כדי לוודא שהמכונות הוגדרו בצורה נכונה, נכנסים לדף Cloud SQL Instances.

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

חשוב גם לוודא שיש לכם את ההרשאה cloudsql.instances.migrate ברפליקה של Cloud SQL. ההרשאה הזו כלולה בתפקידי ה-IAM cloudsql.admin או cloudsql.editor.

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

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

כדי להגדיר את הסיסמה למשתמש ברירת המחדל, משתמשים בפקודה gcloud sql users set-password באופן הבא:

gcloud sql users set-password root \
--host=% \
--instance=INSTANCE_NAME \
--password=PASSWORD

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

איך מוצאים את כתובת ה-IP היוצאת של הרפליקה ב-Cloud SQL

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

gcloud sql instances describe REPLICA_NAME --format="default(ipAddresses)"

אישור חיבורים נכנסים בשרת החיצוני

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

• השרת החיצוני נמצא מאחורי חומת אש או מגבלת רשת אחרת.
• הרפליקה של Cloud SQL משתמשת בכתובת IP ציבורית.

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

עדכון המכונה שמייצגת את המקור כדי לאפשר רפליקציה לרפליקה של Cloud SQL

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

• המארח, היציאה או כתובת ה-IP של השרת החיצוני משתנים.
• אתם רוצים להשתמש במשתמש אחר לרפליקציה של MySQL.
• הסיסמה של משתמש הרפליקציה של MySQL משתנה.
• אישורי ה-SSL שמשמשים לחיבור מאובטח לשרת החיצוני משתנים.

הזנת נתונים לרפליקה של Cloud SQL

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

• בייבוא מנוהל נעשה שימוש בשירות שמחלץ נתונים מהשרת החיצוני ומייבא אותם ישירות למכונה של Cloud SQL. אנחנו ממליצים על האפשרות הזו ב-Cloud SQL. אתם חייבים להשתמש באפשרות הזו אם השרת החיצוני שלכם לא משתמש ברפליקציה של מזהה עסקה גלובלי (GTID). מידע נוסף זמין במאמר שימוש בייבוא מנוהל כדי להגדיר שכפול ממסדי נתונים חיצוניים.
• כדי להשתמש בקובץ dump, צריך ליצור קובץ dump של השרת החיצוני, להעביר אותו לקטגוריה של Cloud Storage ולייבא אותו ל-Cloud SQL. אפשר להשתמש באפשרות הזו רק אם השרת החיצוני משתמש ברפליקציית GTID. מידע נוסף זמין במאמר שימוש בקובץ dump להגדרת שכפול ממסדי נתונים חיצוניים.
• כדי לייבא בהתאמה אישית, צריך ליצור מכונה ראשית של Cloud SQL, לייבא נתונים בהתאמה אישית באמצעות הכלים המועדפים עליכם, להוריד אותה בדרגה לרפליקה של Cloud SQL ואז להגדיר רפליקה של שרת חיצוני. השיטה הזו מתאימה במיוחד להעברת מסדי נתונים בגודל של כמה טרה-בייטים, אבל צריך להשתמש ברפליקציית GTID. מידע נוסף זמין במאמר שימוש בייבוא בהתאמה אישית כדי להגדיר שכפול ממסדי נתונים חיצוניים גדולים.

איזו אפשרות מתאימה לכם?

מעקב אחרי הרפליקציה

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

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

אם עיכוב השכפול לא מתקרב ל-0, צריך לטפל בבעיה.

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

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

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

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

ב-MySQL מגרסה 8.0.25 ומטה:

SHOW SLAVE STATUS;

ב-MySQL מגרסה 8.0.26 ואילך:

SHOW REPLICA STATUS;

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

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

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

  • ב-Microsoft Azure MySQL יש את ההצהרה FLUSH FIREWALL RULES.
  • בשרת MariaDB יש את ההצהרה FLUSH USER_STATISTICS.
  • ‫Percona ל-MySQL מאפשר ל-DDL להוסיף עמודת DATETIME עם ערך ברירת מחדל של אפס (לדוגמה, 1970-01-01 00:00:00), וזה לא תקין ב-MySQL.

מנגנון אחד לדילוג על שגיאות הוא להגדיר את דגל ההגדרות האישיות slave_skip_errors או replica_skip_errors כדי לדלג על קוד השגיאה האחרון שנתקלתם בו. כדי למצוא את קוד השגיאה האחרון, שולחים שאילתה לעמודה LAST_ERROR_NUMBER בטבלה performance_schema.replication_applier_status_by_worker. שינוי הדגל הזה מדלג על כל שגיאות השכפול עם קוד השגיאה או הקודים הרלוונטיים.

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

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

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

כדי ליצור רפליקה מדורגת, מריצים את הפקודות הבאות:

קידום הרפליקה

כדי לקדם את הרפליקה:

1. קידום הרפליקה למכונה ראשית. שימו לב שיומני GTID ויומנים בינאריים מופעלים, ושהגיבויים המתוזמנים מופעלים ברפליקה שקודמה.
2. הוספת רפליקות לקריאה למכונה.
3. אופציונלי: מגדירים את המכונה לזמינות גבוהה (HA). כדי למנוע זמן השבתה נוסף, אתם יכולים להפעיל זמינות גבוהה בזמן הגדרת רפליקה על ידי הגדרת AVAILABILITY_TYPE ל-REGIONAL.

מגבלות

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

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

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

• אי אפשר לציין להעברה מסדי נתונים נבחרים ששמות מסדי הנתונים שלהם מכילים את התווים המילוליים _ (קווים תחתונים (U+005F)), % (סימני אחוז (U+0025)) או , (פסיקים (U+002C)).

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

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

• איך משתמשים בייבוא מנוהל כדי להגדיר שכפול ממסדי נתונים חיצוניים