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

‫MySQL   |  PostgreSQL   |  SQL Server

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

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

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

שכפול GTID לא נתמך בגרסאות מסוימות של Amazon RDS, ב-Amazon Aurora 5.6 ובגרסאות מוקדמות של Amazon Aurora 5.7.

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

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

     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 באמצעות mysql CLI:

   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 באמצעות Google Cloud מאגר. ייבוא נתונים מקובץ SQL מוכן לשימוש אל Cloud SQL

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

כדי להפוך את המכונה של Cloud SQL למכונת רפליקה של Cloud SQL, משתמשים בשיטה 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	המזהה של הפרויקט ב- Google Cloud.
   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 external primary	10.68.48.3:3306
replica-instance	עותק לקריאה ב-MySQL	34.66.48.59

הפעלת שכפול במכונה של Cloud SQL

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

בשלב הזה נעשה שימוש בפרוצדורות מאוחסנות של 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 set שרוצים להגדיר.

   לדוגמה:

       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	נקודת קצה של המקור.
   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	נקודת קצה של המקור.
   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 להעברת ייבוא מנוהל זמין במאמר דגלים מותרים ודגלי ברירת מחדל לסנכרון ראשוני
המיגרציה הראשונית של הנתונים הושלמה, אבל לא מתבצעת שכפול של הנתונים.	אחת הסיבות האפשריות לבעיה היא שבמסד הנתונים של המקור הוגדרו דגלי שכפול שגורמים לכך שחלק מהשינויים במסד הנתונים או כולם לא משוכפלים. מוודאים שדגלי השכפול, כמו binlog-do-db,‏ binlog-ignore-db,‏ replicate-do-db או replicate-ignore-db, לא מוגדרים בצורה שיוצרת התנגשות. מריצים את הפקודה show master status במופע הראשי כדי לראות את ההגדרות הנוכחיות.
המיגרציה הראשונית של הנתונים הושלמה בהצלחה, אבל שכפול הנתונים מפסיק לפעול אחרי זמן מה.	פעולות שכדאי לנסות: בודקים את מדדי השכפול של מופע הרפליקה בקטע Cloud Monitoring במסוף Google Cloud . אפשר למצוא את השגיאות משרשור הקלט/פלט או משרשור ה-SQL של MySQL בקבצים mysql.err log ב-Cloud Logging. השגיאה יכולה להופיע גם כשמתחברים למופע המשוכפל. מריצים את הפקודה SHOW SLAVE STATUS ובודקים אם השדות הבאים מופיעים בפלט: Slave_IO_Running Slave_SQL_Running Last_IO_Error Last_SQL_Error
mysqld check failed: data disk is full.	דיסק הנתונים של מופע הרפליקה מלא. מגדילים את גודל הדיסק של מכונת הרפליקה. אפשר להגדיל את גודל הדיסק באופן ידני או להפעיל הגדלה אוטומטית של נפח האחסון.

בדיקת יומני השכפול

כשמאמתים את הגדרות השכפול, נוצרים יומנים.

כדי לראות את היומנים האלה:

1. נכנסים אל Logs Viewer במסוף Google Cloud .

   כניסה לדף Logs Viewer

2. בתפריט הנפתח Instance (מופע), בוחרים את הרפליקה של Cloud SQL.
3. בוחרים את קובץ היומן replication-setup.log.

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

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

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

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