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

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

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

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

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

לפני שמתחילים, צריך להגדיר את השרת החיצוני, ליצור את המכונה שמייצגת את המקור ולהגדיר את הרפליקה של 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 שם המשתמש של חשבון המשתמש ב-GCP.
HOST שם המארח של חשבון המשתמש ב-GCP.

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

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

ביצוע ייצוא וייבוא בהתאמה אישית

בקטע הזה נסביר איך ליצור את קובץ ה-dump ולייבא אותו לרפליקה הסופית של Cloud SQL באמצעות כלי הלקוח mydumper או mysqldump.

כשמבצעים dump של הנתונים, יכול להיות שצריך להחריג מסדי נתונים גנריים של MySQL, כולל mysql ו-sys, אם הם קיימים במכונה של המקור. אחרת, ייבוא הנתונים ייכשל. איך מחריגים (או כוללים) מסדי נתונים?

שימוש ב-mydumper וב-myloader

כדי ליצור קובץ dump ולייבא אותו ל-Cloud SQL:

  1. יוצרים קובץ dump של מסד הנתונים של השרת החיצוני באמצעות mydumper.

       $ mydumper -u USERNAME -p PASSWORD \
              --threads=16 -o ./backup \
              -h HOST \
              --no-locks \
              --regex '^(?!(mysql\.|sys\.))'
    מאפיין (property) תיאור
    USERNAME השם של חשבון המשתמש של הרפליקציה או של חשבון המשתמש בשרת החיצוני שיש לו הרשאות קריאה במסד הנתונים.
    PASSWORD סיסמת המשתמש לשכפול.
    HOST כתובת ה-IPv4 או ה-DNS של השרת החיצוני.

  2. מייבאים את הנתונים למכונה של Cloud SQL באמצעות myloader.

     $ myloader -u REPLICA_USERNAME -p REPLICA_PASSWORD \
            --threads=16 \
            -d ./backup -h HOST -o
    מאפיין (property) תיאור
    REPLICA_USERNAME חשבון המשתמש במכונה של Cloud SQL.
    REPLICA_PASSWORD סיסמת המשתמש של מכונת Cloud SQL.
    HOST כתובת ה-IPv4 של מכונת Cloud SQL.

  3. רושמים את פרטי ה-GTID או ה-binlog של קובץ ה-dump של הנתונים. תצטרכו את המידע הזה כשתגדירו את הרפליקציה באמצעות הפרוצדורות המאוחסנות.

    כדי לקבל את פרטי ה-GTID או ה-binlog של קובץ ה-dump של הנתונים, מריצים את הפקודה הבאה:

      sudo cat ./backup/metadata

שימוש ב-mysqldump

  1. יוצרים קובץ dump באמצעות mysqldump:

    mysqldump 

    mysqldump \
    --host=EXTERNAL_HOST \
    --port=EXTERNAL_PORT \
    --user=USERNAME\
    --password=PASSWORD \
    --databases=DATABASE_LIST  \
    --hex-blob \
    --master-data=EXTERNAL_DATA  \
    --no-autocommit \
    --default-character-set=utf8mb4 \
    --single-transaction \
    GTID_PURGED \
    ADD_DROP_TABLE \
    ROUTINES \
    COMPRESS \
    GZIP
    מאפיין (property) תיאור
    EXTERNAL_HOST כתובת ה-IPv4 או ה-DNS של השרת החיצוני.
    EXTERNAL_PORT היציאה של השרת החיצוני. אם השרת החיצוני מתארח ב-Cloud SQL, הערך הוא 3306.
    USERNAME השם של חשבון המשתמש של הרפליקציה או של חשבון המשתמש בשרת החיצוני שיש לו הרשאות קריאה במסד הנתונים.
    USER_PASSWORD סיסמת המשתמש לשכפול.
    DATABASE_LIST רשימה של כל מסדי הנתונים בשרת החיצוני, מופרדים ברווחים, חוץ ממסדי הנתונים של המערכת (sys,‏ mysql,‏ performance_schema ו-information_schema). כדי להציג את רשימת מסדי הנתונים, משתמשים בפקודה SHOW DATABASES של MySQL.
    EXTERNAL_DATA אם השרת החיצוני לא תומך ב-GTID, ויש לכם הרשאה לגשת לנעילת הקריאה הגלובלית שלו, השתמשו ב---master-data=1. אחרת, אל תשתמשו במאפיין הזה.
    GTID_PURGED אם השרת החיצוני תומך ב-GTID, משתמשים ב---set-gtid-purged=on. אחרת, לא משתמשים במאפיין הזה.
    ADD_DROP_TABLE אם רוצים להוסיף הצהרת DROP TABLE לפני כל הצהרת CREATE TABLE, צריך לכלול את --add-drop-table.
    ROUTINES אם רוצים להציג רוטינות שמורות, כמו פרוצדורות ופונקציות, בפלט של מסדי נתונים שהועברו, צריך לכלול את --routines.
    COMPRESS אם רוצים לדחוס את כל המידע שנשלח בין הרפליקה של Cloud SQL לבין השרת החיצוני, משתמשים ב---compress.
    GZIP כדי לדחוס את קובץ ה-dump עוד יותר, משתמשים ב-| gzip. אם מסד הנתונים מכיל נתונים שלא נדחסים היטב, כמו נתונים בינאריים שלא ניתנים לדחיסה או תמונות JPG, אל תשתמשו באפשרות הזו.

    לדוגמה 

    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

  2. רושמים את פרטי ה-GTID או ה-binlog של קובץ ה-dump של הנתונים. אתם צריכים את המידע הזה כדי להגדיר את הרפליקציה באמצעות הפרוצדורות המאוחסנות של Cloud SQL.

    כדי למצוא את ה-GTID, מחפשים שורה שדומה לזו:

       SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496';

    לגבי ה-binlog, חפשו שורה שדומה לזו:

       CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;

  3. מסירים את השורות הבאות בקובץ ה-dump שדורשות הרשאות סופר-משתמש. למשתמשי Cloud SQL אין הרשאות-על, ולכן השורות האלה גורמות לייבוא להיכשל.

    לרפליקציה שמבוססת על GTID: מסירים את ההצהרה SET GTID_PURGED יחד עם ההצהרה של הגדרת משתנה הסשן בקובץ ה-dump. לדוגמה:

       ...
   SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
   SET @@SESSION.SQL_LOG_BIN= 0;
   ...
   SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496';
   ...
   SET @@SESSION.SQL_LOG_BIN=@MYSQLDUMP_TEMP_LOG_BIN;

    ברפליקציה שמבוססת על binlog, מסירים את ההצהרה CHANGE MASTER. לדוגמה:

       ...
   CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;
    ...

  4. מייבאים את הנתונים לרפליקה של Cloud SQL באמצעות ה-CLI של mysql:

    mysql 

    mysql -h REPLICA_HOST -u REPLICA_USER \
-p REPLICA_DATABASE_NAME RESULT_FILE
    מאפיין (property) תיאור
    REPLICA_HOST המארח שבו נמצא שרת MySQL.
    REPLICA_USER שם המשתמש ב-MySQL שמשמש להתחברות לשרת.
    REPLICA_DATABASE_NAME שם מסד הנתונים שבו נמצאים הנתונים.
    RESULT_FILE שם קובץ ה-dump לייבוא.

    לדוגמה 

      mysql -h 255.255.255.255 -u replica_username -p replica_db < result.sql

אפשר גם לייבא את קובץ ה-dump באמצעות קטגוריה ב- Cloud de Confiance . ייבוא נתונים מקובץ SQL מוכן לשימוש ל-Cloud SQL.

הורדה בדרגה של מכונת Cloud SQL

כדי להוריד את המכונה של Cloud SQL לרפליקה של Cloud SQL, משתמשים ב-method‏ demoteMaster במכונה.

  1. מכינים קובץ JSON של בקשה עם שם המכונה שרוצים להוריד בדרגה.

    קובץ JSON מקורי 

     {
    "demoteMasterContext": {
      "masterInstanceName": SOURCE_REPRESENTATION_INSTANCE_NAME,
      "skipReplicationSetup": true
      }
 }
    מאפיין (property) תיאור
    SOURCE_REPRESENTATION_INSTANCE_NAME השם של מופע הייצוג של המקור.

    לדוגמה 

       {
     "demoteMasterContext": {
       "masterInstanceName": "cloudsql-source-instance",
       "skipReplicationSetup": true
     }
   }

  2. פותחים טרמינל ומשתמשים בפקודות הבאות כדי להפעיל את demoteMaster:

    curl 

      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/INSTANCE-NAME/demoteMaster
    מאפיין (property) תיאור
    JSON_PATH הנתיב לקובץ JSON.
    PROJECT_ID מזהה הפרויקט ב- Cloud de Confiance.
    INSTANCE-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 POST \
   https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/cloudsql-replica-instance/demoteMaster

מה אמור להופיע בסיום התהליך

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

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

מזהה מופע סוג כתובת IP ציבורית
‫(-) source-representation-instance ‫MySQL חיצוני ראשי 10.68.48.3:3306
     replica-instance רפליקה לקריאה של MySQL 34.66.48.59

התחלת הרפליקציה במכונה של Cloud SQL

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

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

  2. משתמשים בפרוצדורה המאוחסנת mysql.resetMaster כדי לאפס את הגדרות הרפליקציה.

     mysql> call mysql.resetMaster();

  3. מגדירים את הרפליקציה. בשלב הזה צריך את פרטי ה-GTID או ה-binlog שרשמתם קודם.

    GTID

    1. מגדירים את השדה gtid_purged באמצעות התהליך המאוחסן mysql.skipTransactionWithGtid(GTID_TO_SKIP).
    מאפיין (property) תיאור
    GTID_TO_SKIP ערך קבוצת ה-GTID שצריך להגדיר.

    לדוגמה: 

        mysql> call mysql.skipTransactionWithGtid('32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496');

    1. מריצים את התהליך המאוחסן mysql.setupExternalSourceAutoPosition(HOST, PORT, USER_NAME, USER_PASSWORD, MASTER_AUTO_POSITION, USE_SSL, USE_SSL_CLIENT_AUTH).
    מאפיין (property) תיאור
    HOST נקודת הקצה (endpoint) של המקור.
    PORT יציאת המקור.
    USER_NAME משתמש המקור.
    USER_PASSWORD סיסמת המשתמש במקור.
    MASTER_AUTO_POSITION הערך של הפרמטר master_auto_position. הערכים האפשריים הם 0 ו-1.
    USE_SSL אם להשתמש ברפליקציה מבוססת-SSL. הערכים האפשריים הם true ו-false. אם true, צריך להגדיר את השדה caCertificate בבקשה DemoteMaster.
    USE_SSL_CLIENT_AUTH אם להשתמש באימות לקוח SSL. הערכים האפשריים הם true ו-false. אם true, צריך להגדיר את השדות clientKey ו-clientCertificates בבקשה demoteMaster. 
        mysql> call mysql.setupExternalSourceAutoPosition('1.1.1.1', 3306, \
    'USERNAME', 'PASSWORD', \
    /* master_auto_position= */ 1,false, false); \

    binlog

    מריצים את התהליך המאוחסן mysql.setupExternalSource(HOST, PORT, USER_NAME, USER_PASSWORD, SOURCE_LOG_NAME, SOURCE_LOG_POS, USE_SSL, USE_SSL_CLIENT_AUTH).

    מאפיין (property) תיאור
    HOST נקודת הקצה (endpoint) של המקור.
    PORT יציאת המקור.
    USER_NAME משתמש המקור.
    USER_PASSWORD סיסמת המשתמש במקור.
    SOURCE_LOG_NAME השם של היומן הבינארי במכונה של מסד הנתונים במקור, שמכיל את פרטי הרפליקציה.
    SOURCE_LOG_POS המיקום ביומן הבינארי של mysql_binary_log_file_name שבו הרפליקציה מתחילה לקרוא את פרטי הרפליקציה.
    USE_SSL אם להשתמש ברפליקציה מבוססת-SSL. הערכים האפשריים הם true ו-false. אם true, צריך להגדיר את השדה caCertificate בבקשה DemoteMaster.
    USE_SSL_CLIENT_AUTH אם להשתמש באימות לקוח SSL. הערכים האפשריים הם true ו-false. אם true, צריך להגדיר את השדות clientKey ו-clientCertificates בבקשה demoteMaster. 
        mysql> call mysql.setupExternalSource('1.1.1.1', 3306, \
    'user_name', 'password', 'mysql-bin-changelog.033877', 360, \
    false, false);

  4. משתמשים בפרוצדורה המאוחסנת mysql.startReplication() כדי להתחיל את הרפליקציה ממסד הנתונים החיצוני.

       mysql> call mysql.startReplication();

  5. מאמתים את סטטוס הרפליקציה. מוודאים שבשדות Slave_IO_Running ו-Slave_SQL_Running כתוב YES.

       mysql> show slave status\G

    הפלט מהפקודה הזו אמור להיראות כך:

       *************************** 1. row ***************************
                   Slave_IO_State: Waiting for master to send event
                      Master_Host: 1.1.1.1
                      Master_User: user_name
                      Master_Port: 3306
                    Connect_Retry: 60
                  Master_Log_File: mysql-bin-changelog.000001
              Read_Master_Log_Pos: 1
                   Relay_Log_File: relay-log.000002
                    Relay_Log_Pos: 1
            Relay_Master_Log_File: mysql-bin-changelog.000001
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
                  Replicate_Do_DB:
              Replicate_Ignore_DB:
               Replicate_Do_Table:
           Replicate_Ignore_Table:
          Replicate_Wild_Do_Table:
      Replicate_Wild_Ignore_Table: mysql.%
                       Last_Errno: 0
                       Last_Error:
                     Skip_Counter: 0
              Exec_Master_Log_Pos: 412
                  Relay_Log_Space: 752
                  Until_Condition: None
                   Until_Log_File:
                    Until_Log_Pos: 0
               Master_SSL_Allowed: No
               Master_SSL_CA_File:
               Master_SSL_CA_Path:
                  Master_SSL_Cert:
                Master_SSL_Cipher:
                   Master_SSL_Key:
            Seconds_Behind_Master: 0
    Master_SSL_Verify_Server_Cert: No
                    Last_IO_Errno: 0
                    Last_IO_Error:
                   Last_SQL_Errno: 0
                   Last_SQL_Error:
      Replicate_Ignore_Server_Ids:
                 Master_Server_Id: 1509941531
                      Master_UUID: 1cb2c80e-90f0-11eb-9ea3-02389b1c2e6f
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all r
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set: 478af53c-bd24-11eb-be72-42010a80002a:1-226
                Auto_Position: 0
   1 row in set (0.00 sec)

המשך בתהליך הרפליקציה

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

פתרון בעיות

שגיאה פתרון בעיות
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 נכונה.
  • שם המשתמש, המארח והסיסמה של הרפליקציה נכונים.

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