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

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

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

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

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

  1. נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud 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

  3. Verify that billing is enabled for your Google Cloud project.

  4. 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

  5. In the Google Cloud console, on the project selector page, select or create a Google Cloud 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

  6. Verify that billing is enabled for your Google Cloud project.

  7. 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

    8.

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

    כניסה לדף IAM

התקנת ה-SDK של Google Cloud

כדי להגדיר את הרפליקציה, התקינו את Google Cloud 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. במסוף Google Cloud , נכנסים לדף רשתות VPC.

    לדף 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 שפועלים בו-זמנית:

        ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;

        לדוגמה, אם הפרמטר max_replication_slots מוגדר ל-10 ואתם כבר משתמשים ב-2 שולחים, מספר תהליכי השליחה של WAL שפועלים בו-זמנית יהיה 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. מידע נוסף זמין במאמר Logical replication and logical decoding in 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 שפועלים בו-זמנית:

        ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;

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

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

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

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

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

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

source.json 

    {
      "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#@%*@"
  }
}
מאפיין (property) תיאור
SOURCE_NAME השם של מופע ייצוג המקור שרוצים ליצור.
REGION האזור שבו רוצים למקם את המכונה של ייצוג המקור.
DATABASE_VERSION גרסת מסד הנתונים שפועלת בשרת החיצוני. האפשרויות הן POSTGRES_9_6,‏ POSTGRES_10,‏ POSTGRES_11,‏ POSTGRES_12,‏ POSTGRES_13,‏ POSTGRES_14,‏ POSTGRES_15,‏ POSTGRES_16 או POSTGRES_17.
SELECTED_OBJECTS רשימה מופרדת בפסיקים של אובייקטים, שמכילה את מסדי הנתונים שאתם מעבירים ממכונת הייצוג של המקור למכונת Cloud SQL של היעד.
SOURCE HOST כתובת ה-IPv4 והיציאה של השרת החיצוני, או כתובת ה-DNS של השרת החיצוני. אם השרת החיצוני מתארח ב-Cloud SQL, היציאה היא 5432.
USERNAME חשבון המשתמש של הרפליקציה בשרת החיצוני.
PASSWORD הסיסמה לחשבון המשתמש של הרפליקציה.
BUCKET שם הקטגוריה שמכילה את קובץ ה-dump. צריך לכלול את השדה הזה רק אם מגדירים רפליקציה עם קובץ dump שקיים בקטגוריה של Cloud Storage.
DUMP_FILE קובץ בקטגוריה שמכיל את הנתונים מהשרת החיצוני.
CLIENT_CA_CERT אישור ה-CA בשרת החיצוני. צריך לכלול את ההגדרה רק אם נעשה שימוש ב-SSL/TLS בשרת החיצוני.
CLIENT_CERT אישור הלקוח בשרת החיצוני. נדרש רק עבור אימות שרת-לקוח. צריך לכלול את זה רק אם משתמשים ב-SSL או ב-TLS בשרת החיצוני.
CLIENT_KEY קובץ המפתח הפרטי של אישור הלקוח בשרת החיצוני. נדרש רק לאימות שרת-לקוח. ההגדרה הזו רלוונטית רק אם נעשה שימוש ב-SSL/TLS בשרת החיצוני.
SSL_OPTION

אם נעשה שימוש בהצפנת SSL/TLS כדי ליצור חיבור בין מסד הנתונים של Microsoft Azure במקור לבין מסד הנתונים של Cloud SQL ביעד. אפשר לציין את הערכים הבאים בפרמטר הזה:

  • ‫SSL_OPTION_UNSPECIFIED: מסד הנתונים של היעד מתחבר למסד הנתונים של המקור בלי הצפנה.
  • ‫DISABLED: פרוטוקול SSL מושבת כשהרפליקה מתחברת למסד הנתונים של המקור.
  • REQUIRE: נדרש SSL כדי שהרפליקה תתחבר למסד הנתונים המקורי.

  • ‫VERIFY_CA: משתמשים בפרמטר הזה כדי לציין אם נעשה שימוש באימות של השרת בלבד או באימות של השרת והלקוח כחלק מההצפנה של SSL/TLS כדי להתחבר בין מסדי הנתונים של המקור והיעד.

    כדי להשתמש באימות בצד השרת בלבד, במשתנה SOURCE_CERT צריך לספק את האישור בקידוד PEM של x509 של רשות האישורים (CA) שחתמה על האישור של השרת החיצוני.

    כדי להשתמש באימות בין שרת ללקוח, צריך להחליף את הערכים הבאים:

    • ‫SOURCE_CERT: מספקים את האישור של רשות האישורים שחתמה על האישור של שרת מסד הנתונים של המקור
    • ‫CLIENT_CERT: מספקים את האישור שבו מסד הנתונים של היעד משתמש כדי לאמת את שרת מסד הנתונים של המקור.
    • ‫CLIENT_KEY: מספקים את המפתח הפרטי שמשויך לאישור הלקוח

ערך ברירת המחדל של הפרמטר הזה הוא SSL_OPTION_UNSPECIFIED.

יצירת מכונה של ייצוג המקור

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

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

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

לדוגמה 

    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
מאפיין (property) תיאור
PROJECT_ID המזהה של הפרויקט ב- Google Cloud.
JSON_PATH הנתיב לקובץ JSON שמכיל את נתוני הבקשה לשרת החיצוני.

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

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

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

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

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

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

source.json 

    {
      "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#@%*@"
  }
}
מאפיין (property) תיאור
SOURCE_NAME השם של מופע ייצוג המקור.
REGION האזור שבו נמצא המופע של ייצוג המקור.
DATABASE_VERSION גרסת מסד הנתונים שפועלת בשרת החיצוני. האפשרויות הן POSTGRES_9_6,‏ POSTGRES_10,‏ POSTGRES_11,‏ POSTGRES_12,‏ POSTGRES_13,‏ POSTGRES_14,‏ POSTGRES_15,‏ POSTGRES_16 או POSTGRES_17.
SELECTED_OBJECTS רשימה מעודכנת של אובייקטים מופרדים בפסיקים, שמכילה מסדי נתונים שאתם מעבירים ממכונת הייצוג של המקור למכונה של Cloud SQL ביעד.
NEW_USERNAME חשבון המשתמש החדש לשכפול בשרת החיצוני.
NEW_PASSWORD הסיסמה לחשבון החדש.

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

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

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

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 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
מאפיין (property) תיאור
PROJECT_ID המזהה של הפרויקט ב- Google Cloud.
JSON_PATH הנתיב לקובץ JSON שמכיל את נתוני הבקשה לשרת החיצוני.
SOURCE_NAME השם של מופע הייצוג של המקור.

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

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

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

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

replica.json 

    {
        "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"
    }
מאפיין (property) תיאור
TIER סוג המכונה שבה תתארח מופע הרפליקה. אם אתם לא יודעים באיזה סוג מכונה להשתמש, התחילו עם db-custom-2-7680. אם צריך, אפשר לשנות את הגודל שלו וערכים נתמכים אחרים בהמשך.
DISK_SIZE נפח האחסון של הרפליקה ב-Cloud SQL, ב-GB.
PUBLIC_IP_STATUS ההגדרה קובעת אם למכונה מוקצית כתובת IP ציבורית. ערך ברירת המחדל של המאפיין הזה הוא true. כדי להשבית את ההקצאה של כתובת IP ציבורית לרפליקה, מגדירים את הערך ל-false. אם בפרויקט מופעלת מדיניות הארגון constraints/sql.restrictPublicIp, כדי ליצור את העותק המשוכפל של Cloud SQL, צריך להגדיר את הערך של המאפיין ipv4Enabled ל-false. מידע נוסף על השבתת ההקצאה של כתובות IP ציבוריות זמין במאמר השבתה של כתובת IP ציבורית.
PROJECT_ID אם הרפליקה של Cloud SQL נמצאת ברשת פרטית, צריך לכלול את המאפיין privateNetwork בקובץ replica.json. בשדה PROJECT_ID, מציינים את מזהה הפרויקט ב- Google Cloud.
NETWORK_NAME השם של הרשת הפרטית שבה רוצים להשתמש עם הרפליקה של Cloud SQL.
AVAILABILITY_TYPE סוג הזמינות של הרפליקה ב-Cloud SQL. ערך ברירת המחדל הוא ZONAL. כדי להגדיר את הרפליקה כ-HA, מגדירים את הערך כ-REGIONAL. כדי לראות את הערכים המותרים, עיינו ב-SqlAvailabilityType.
אחרי שיוצרים העתק HA של שרת חיצוני, אי אפשר לשנות אותו להעתק שאינו HA. הדבר נכון גם בכיוון ההפוך. אי אפשר לשנות רפליקה של שרת חיצוני שאינו HA לרפליקה של HA.
אם מנסים לבצע מעבר ידני לגיבוי בזמן שהמכונה עדיין טוענת את הנתונים הראשוניים, יכול להיות שההעברה לא תהיה ניתנת לשחזור. אם המכונה כבר משכפלת מהמקור, יכול להיות שיהיה זמן השבתה זמני. בודקים את סטטוס הרפליקציה.
SOURCE_REPRESENTATION_INSTANCE_NAME השם של מופע הייצוג של המקור.
SOURCE_REGION האזור שהוקצה למופע של ייצוג המקור.
DATABASE_VERSION גרסת מסד הנתונים שבה רוצים להשתמש עם הרפליקה של Cloud SQL. האפשרויות לגרסה הזו הן POSTGRES_9_6,‏ POSTGRES_10,‏ POSTGRES_11,‏ POSTGRES_12,‏ POSTGRES_13,‏ POSTGRES_14,‏ POSTGRES_15,‏ POSTGRES_16 או POSTGRES_17. הגרסה צריכה להתאים לגרסת מסד הנתונים שפועלת בשרת החיצוני, או להיות גרסה אחת מאוחרת יותר לכל היותר.
REPLICA_NAME השם של הרפליקה של Cloud SQL שרוצים ליצור.

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

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

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

לדוגמה 

    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
מאפיין (property) תיאור
PROJECT_ID מזהה הפרויקט ב- Google Cloud, שצריך להיות זהה למזהה של מכונת המקור.
JSON_PATH הנתיב לקובץ JSON שמכיל את נתוני הבקשה של הרפליקה של Cloud SQL.

אימות ההגדרה

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

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

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

חשוב גם לוודא שיש לכם הרשאה מסוג 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 הזו.

המסוף

כדי לקבל את כתובת ה-IP היוצאת של הרפליקה, בצע את הפעולות הבאות:

  1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

    כניסה לדף Cloud SQL Instances

  2. ליד כתובת ה-IP הציבורית של הרפליקה של Cloud SQL, מעבירים את הסמן מעל ההסבר הקצר More info ומאחזרים את כתובת ה-IP היוצאת.

    שימו לב שכתובת ה-IP היוצאת היא לא כתובת ה-IP שמוצגת ברשימה הראשית של הרפליקה במסוף Google Cloud .

gcloud

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

gcloud sql instances describe REPLICA_NAME --format="default(ipAddresses)"
מאפיין (property) תיאור
REPLICA_NAME השם של רפליקת Cloud SQL שרוצים לאחזר את כתובת ה-IP הציבורית היוצאת שלה.

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

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

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

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

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

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

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

הוספת נתונים למכונת ה-replica של 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, בדקו את המדדים הבאים לכל מסד נתונים:

מדד תיאור
per_database/postgresql/external_sync/initial_sync_complete להבין את שלב ההעברה של מסד נתונים. אם הערך של המדד הזה הוא 0, מסד הנתונים עדיין חלק מהעברת הנתונים הראשונית. אם הערך הוא 1, מסד הנתונים סיים את ה-dump הראשוני של הנתונים והוא נמצא בשלב של סימון נתונים שהשתנו (CDC).
per_database/postgresql/external_sync/replication_byte_lag לדעת את זמן ההשהיה של השכפול במסד נתונים (בבייטים).

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

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

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

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

המסוף

  1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

    כניסה לדף Cloud SQL Instances

  2. לוחצים על הכרטיסייה Replicas של הרפליקה שתשמש כהורה של הרפליקה שרוצים ליצור.
  3. לוחצים על יצירת העתק.
  4. בדף Create read replica, מעדכנים את מזהה המכונה ואת כל אפשרויות ההגדרה האחרות, כולל השם, האזור והתחום.
  5. לוחצים על יצירה.

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

  6. חוזרים על שלבים 4 עד 6 לכל רפליקה מדורגת חדשה שרוצים ליצור.

gcloud

  1. כדי ליצור את הרפליקה החדשה, מציינים את רפליקת Cloud SQL כמכונה הראשית באמצעות הדגל --master-instance-name: 
    gcloud sql instances create REPLICA_NAME \
      --master-instance-name=PARENT_REPLICA_NAME \
     מחליפים את הערכים הבאים:
    • ‫REPLICA_NAME: המזהה הייחודי של הרפליקה שיוצרים
    • ‫PARENT_REPLICA_NAME: השם של הרפליקה ב-Cloud SQL

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

curl

  1. כדי ליצור רפליקה מתחת לרפליקת ההורה, עורכים את דוגמת הקוד הבאה ב-JSON ושומרים אותה בקובץ בשם request.json: 
    {
  "masterInstanceName": "EXTERNAL_SERVER_REPLICA_NAME",
  "project": "PROJECT_ID",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
    {
      "tier": "MACHINE_TYPE",
    }
}
  2. מריצים את הפקודה הבאה: 
    curl -X POST
-H "Authorization: Bearer "$(gcloud auth print-access-token)
-H "Content-Type: application/json; charset=utf-8"
-d @request.json
"https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances"

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

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

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

מגבלות

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

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

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

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

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

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