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

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

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

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

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

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

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

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

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

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

   Roles required to enable APIs

   To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

   Enable the API

4. חשוב לוודא שיש לכם את התפקידים Cloud SQL Admin,‏ Storage Admin ו-Compute Viewer בחשבון המשתמש.

   כניסה לדף IAM

התקנה של Cloud de Confiance SDK

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

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

‫Cloud SQL תומך בהעברות רציפות ממסדי נתונים של מקור למסדי נתונים של יעד ב-Cloud SQL.

מסדי הנתונים הנתמכים כמקורות ל-PostgreSQL כוללים:

• ‫PostgreSQL בניהול עצמי (במקום או במכונה וירטואלית בענן שאתם שולטים בה באופן מלא) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17 ו-18
• ‫Amazon RDS 9.6.10+,‏ 10.5+,‏ 11.1+,‏ 12,‏ 13,‏ 14,‏ 15,‏ 16,‏ 17 ו-18.
• ‫Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14.6+, 15.2+, 16 ו-17.
• ‫Microsoft Azure Database for PostgreSQL Flexible Server 11 ואילך
• ‫Cloud SQL 9.6,‏ 10,‏ 11,‏ 12,‏ 13,‏ 14,‏ 15,‏ 16,‏ 17 ו-18

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

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

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

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

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

1. נכנסים לדף VPC networks במסוף Cloud de Confiance .

   לדף VPC networks

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

3. לוחצים על הכרטיסייה Private service connection (חיבור פרטי לשירות).

הגדרת מופע המקור

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

1. אם מופע המקור לא כולל את מסד הנתונים postgres, צריך ליצור אותו.
2. מתקינים את חבילת pglogical במופע המקור.

3. מגדירים את הפרמטרים הבאים לפי הצורך.

   1. אם מופע PostgreSQL של המקור הוא Amazon RDS, צריך לכלול את הפרמטרים האלה ב קבוצת פרמטרים חדשה ולצרף את קבוצת הפרמטרים למופע.

   • אם המקור הוא Cloud SQL, מגדירים את הדגלים cloudsql.logical_decoding ו-cloudsql.enable_pglogical לערך on.

     מידע על הפעלת דגלים ב-Cloud SQL זמין במאמר הגדרת דגלים של מסד נתונים.

   • מגדירים את shared_preload_libraries כך שיכלול את pglogical באמצעות הפקודה הבאה:

     ALTER SYSTEM SET shared_preload_libraries = 'pglogical';
           

   • מגדירים את wal_level ל-logical באמצעות הפקודה הבאה:

         ALTER SYSTEM SET wal_level = 'logical';
         

     אם מכונת PostgreSQL המקורית היא Amazon RDS, כדי להפעיל יומני WAL ברמה של logical, צריך להגדיר את הפרמטר rds.logical_replication לערך 1.

   • מגדירים את wal_sender_timeout ל-0 באמצעות הפקודה הבאה:

     ALTER SYSTEM SET wal_sender_timeout = 0;

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

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

     ALTER SYSTEM SET max_replication_slots = MAX_REPLICATION_SLOTS;

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

     לדוגמה, אם במופע המקור יש 5 מסדי נתונים ונוצרו 2 משימות העברה למקור, מספר משבצות השכפול צריך להיות לפחות 5 * 2 = 10, בנוסף למספר משבצות השכפול שבהן אתם כבר משתמשים.

   • מגדירים את max_wal_senders לערך שגדול לפחות כמו max_replication_slots, בנוסף למספר השולחים שכבר נמצאים בשימוש במופע. משתמשים בפקודה הבאה ומחליפים את MAX_WAL_SENDERS במספר הכולל של תהליכי WAL sender שפועלים בו-זמנית:

     ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;

     לדוגמה, אם הפרמטר max_replication_slots מוגדר לערך 10, ואתם כבר משתמשים ב-2 שולחים, מספר התהליכים של WAL sender שפועלים בו-זמנית יהיה 10 + 2 = 12.

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

     ALTER SYSTEM SET max_worker_processes = MAX_WORKER_PROCESSES;

   2. אם מכונת המקור של PostgreSQL היא Microsoft Azure Database for PostgreSQL Flexible Server, צריך לבצע את הפעולות הבאות כדי לתמוך בהעברת נתונים משרת חיצוני למכונת Cloud SQL:

      • מגדירים את shared_preload_libraries כך שיכלול את pglogical באמצעות הפקודה הבאה:

        ALTER SYSTEM SET shared_preload_libraries = 'pglogical';
              

      • מגדירים את wal_level להיות logical. מידע נוסף זמין במאמר שכפול לוגי ופענוח לוגי ב-Azure Database for PostgreSQL – Flexible Server.

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

        ALTER SYSTEM SET max_replication_slots = MAX_REPLICATION_SLOTS;

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

        לדוגמה, אם במופע המקור יש 5 מסדי נתונים ונוצרו 2 משימות העברה למקור, מספר משבצות השכפול צריך להיות לפחות 5 * 2 = 10, בנוסף למספר משבצות השכפול שבהן אתם כבר משתמשים.

      • מגדירים את max_wal_senders לערך שגדול לפחות כמו max_replication_slots, בנוסף למספר השולחים שכבר נמצאים בשימוש במופע. משתמשים בפקודה הבאה ומחליפים את MAX_WAL_SENDERS במספר הכולל של תהליכי WAL sender שפועלים בו-זמנית:

        ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;

        לדוגמה, אם הפרמטר max_replication_slots מוגדר לערך 10, ואתם כבר משתמשים ב-2 שולחים, מספר התהליכים של WAL sender שפועלים בו-זמנית יהיה 10 + 2 = 12.

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

        ALTER SYSTEM SET max_worker_processes = MAX_WORKER_PROCESSES;

      • מגדירים את azure.extensions כך שיכלול את pglogical. מידע נוסף זמין במאמר פרמטרים של שרת ב-Azure Database for PostgreSQL – Flexible Server.

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

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

הפעלת מעקב אחר עיכוב בשכפול ב-PostgreSQL בגרסאות קודמות ל-9.6

אם אתם מבצעים מיגרציה מגרסת PostgreSQL נמוכה מ-9.6, מדד השהיית השכפול לא זמין כברירת מחדל. כדי לעקוב אחרי המדד הזה ולצמצם את זמן ההשבתה כשמעבירים את מסד הנתונים לסטטוס 'מוכן לייצור', אפשר להשתמש באחת משלוש חלופות:

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

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

     CREATE OR REPLACE FUNCTION pg_stat_replication_user()
     RETURNS TABLE (
     pid               integer                  ,
     usesysid          oid                      ,
     username          name                     ,
     application_name  text                     ,
     client_addr       inet                     ,
     client_hostname   text                     ,
     client_port       integer                  ,
     backend_start     timestamp with time zone ,
     backend_xmin      xid                      ,
     state             text                     ,
     sent_location     pg_lsn                   ,
     write_location    pg_lsn                   ,
     flush_location    pg_lsn                   ,
     replay_location   pg_lsn                   ,
     sync_priority     integer                  ,
     sync_state        text
     )
     LANGUAGE SQL
     SECURITY DEFINER
     AS $$
      SELECT *
      FROM pg_catalog.pg_stat_replication;
     $$;
     

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

     1. REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
     2. GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};

• אפשרות 2: הענקת ההרשאה SUPERUSER ישירות למשתמש שמשמש להתחברות למכונת המקור. כך השרת החיצוני יכול לקרוא את זמן ההשהיה של השכפול ישירות.

• אפשרות 3: מעקב אחרי השהיית השכפול בנפרד באמצעות השאילתה הבאה:

      SELECT current_timestamp, application_name,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.sent_location) AS sent_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.write_location) AS write_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.flush_location) AS flush_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.replay_location) AS replay_location_lag
      FROM pg_stat_replication
      WHERE application_name like 'cloudsql%';
    

  באפשרות הזו, מדד עיכוב השכפול לא מוצג ב-Cloud SQL בתרשימים או בתגובות של ה-API.

הגדרת מסדי הנתונים של המקור

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

• למקורות מקומיים: מסדי נתונים של תבניות template0 ו-template1
• למקורות Amazon RDS: template0,‏ template1 ו-rdsadmin
• למקורות Cloud SQL: מסדי נתונים של תבניות template0 ו-template1

מבצעים את הפעולות הבאות בכל מסד נתונים במופע המקור שלא נכלל ברשימה הקודמת:

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

   CREATE EXTENSION IF NOT EXISTS pglogical

   בטבלאות שאין להן מפתחות ראשיים, Cloud SQL תומך בהעברה של התמונה הראשונית ובמשפטי INSERT במהלך השלב של סימון נתונים שהשתנו (CDC). העברה ידנית של דוחות UPDATE וDELETE.

   .

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

   המשתמש שבו אתם משתמשים כדי להתחבר למופע המקור מוגדר כמשתמש בדף Connection Profiles (פרופילי חיבור). אתם יכולים ליצור משתמש חדש או להשתמש במשתמש קיים.

   • בכל הסכמות בכל מסד נתונים להעברה, למעט סכמת המידע וסכמות שמתחילות ב-pg_, מריצים את הפקודה הבאה:

     GRANT USAGE on SCHEMA schema to username;
     GRANT SELECT on ALL SEQUENCES in SCHEMA schema to username;
     GRANT SELECT on ALL TABLES in SCHEMA schema to username;

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

     GRANT USAGE on SCHEMA pglogical to PUBLIC;

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

     GRANT SELECT on ALL TABLES in SCHEMA pglogical to username;

   • אם המקור הוא Amazon RDS, מריצים את הפקודה הבאה:

     GRANT rds_replication to username;

     אם המקור שלכם הוא Microsoft Azure Database for PostgreSQL בגרסה מוקדמת יותר מ-14, מריצים את הפקודה הבאה:

     GRANT SELECT on ALL TABLES in SCHEMA pglogical to username;

     אפשר להתעלם משגיאה שמופיעה בממשק pglogical.node.

     אם המקור שלכם הוא Microsoft Azure Database for PostgreSQL בגרסה 14 ואילך, מריצים את הפקודה הבאה:

     GRANT pg_read_all_data to username;

     אחרת, מריצים את הפקודה הבאה:

     ALTER USER username with REPLICATION;

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

מופע הייצוג של המקור מפנה לשרת החיצוני. הוא מכיל רק את נתוני הבקשה מהשרת החיצוני. יוצרים את נתוני הבקשה ומשתמשים בהם בפקודה 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": "POSTGRES_9_6",
  "onPremisesConfiguration": {
    "selectedObjects":[{"database":"db1"}, {"database":"db2"}],
    "hostPort": "192.0.2.0:5423",
    "username": "replicationUser",
    "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 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": "POSTGRES_9_6",
  "onPremisesConfiguration": {
    "selectedObjects":[{"database":"db1"}, {"database":"db3"}],
    "username": "newReplicationUser",
    "password": "525#@%*@"
  }
}

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

לפני שמתחילים את השלב הזה, יוצרים קובץ 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": "POSTGRES_16",
        "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 postgres \
--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 של השרת החיצוני.
• רוצים להשתמש במשתמש אחר לשכפול PostgreSQL.
• הסיסמה של משתמש השכפול של PostgreSQL משתנה.
• אישורי ה-SSL שמשמשים לחיבור מאובטח לשרת החיצוני משתנים.

הוספת נתונים לרפליקה ב-Cloud SQL

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

מעקב אחר השכפול

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

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

אם מגמת ההשהיה בשכפול לא מתקרבת ל-0, צריך לנקוט צעדים כדי לטפל בבעיה. כדאי לבדוק את המדדים הבאים: /postgresql/external_sync/initial_sync_complete,‏ postgresql/external_sync/max_replica_byte_lag ו-database/replication/state. אפשר לעיין ברשימת המדדים של Cloud SQL.

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

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

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

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

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

קידום העותק

כדי לקדם את העותק המשוכפל, פועלים לפי השלבים הבאים:

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

מגבלות

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

  מידע נוסף על התוספים שנתמכים ב-Cloud SQL זמין במאמר הגדרת תוספים ל-PostgreSQL.

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

• אי אפשר להעביר נתונים מגרסה 11 של שרת Microsoft Azure כמקור לגרסה 11 של מופע Cloud SQL ל-PostgreSQL כיעד. כדי לפתור את הבעיה, צריך להעביר את הנתונים למכונת Cloud SQL עם גרסה 12 או גרסה מתקדמת יותר.

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

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