יצירת עותקים לקריאה

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

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

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

מידע נוסף על אופן הפעולה של רפליקציה זמין במאמר רפליקציה ב-Cloud SQL.

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

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

יצירת עותק לקריאה

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

המסוף

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

    כניסה לדף Cloud SQL Instances

  2. מחפשים את המופע שרוצים ליצור לו רפליקה, ואז פותחים את התפריט more actions לצד כרטיס המוצר.
  3. בוחרים באפשרות יצירת עותק לקריאה.

    אם האפשרות הזו לא מופיעה, סימן שהמופע הוא העתק. אי אפשר ליצור העתק של העתק.

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

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

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

    מידע נוסף על כל הגדרה מופיע בדף מידע על הגדרות של מופעים.

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

  6. לוחצים על יצירת העתק.

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

gcloud

  1. בודקים את הסטטוס של המופע הראשי: 
    gcloud sql instances describe PRIMARY_INSTANCE_NAME

    אם הנכס databaseReplicationEnabled הוא true, המופע הוא רפליקה; אי אפשר ליצור רפליקה של רפליקה.

  2. אם המאפיין enabled בקטע backupConfiguration הוא false, צריך להפעיל עכשיו גיבויים למופע הראשי: 
    gcloud sql instances patch PRIMARY_INSTANCE_NAME \
--backup-start-time=>HH:MM
    הפרמטר backup-start-time מצוין בפורמט של 24 שעות, באזור הזמן UTC±00, ומציין את ההתחלה של חלון גיבוי של 4 שעות. הגיבויים יכולים להתחיל בכל שלב במהלך חלון הגיבוי.
  3. אם המאפיין binaryLogEnabled הוא false, מפעילים את היומנים הבינאריים במופע הראשי: 
    gcloud sql instances patch PRIMARY_INSTANCE_NAME \
--enable-bin-log
     הפעלת יומנים בינאריים גורמת להפעלה מחדש של המכונה.
  4. יוצרים את הרפליקה: 
    gcloud sql instances create REPLICA_NAME \
--master-instance-name=PRIMARY_INSTANCE_NAME

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

    אפשר לציין אזור אחר באמצעות הפרמטר --region.

    אפשר להוסיף עוד פרמטרים להגדרות אחרות של המופע. מידע נוסף זמין במאמר בנושא gcloud sql instances create.

    אם למופע הראשי יש רק כתובת IP פנימית, ואתם רוצים לאפשר לשירותים אחרים, כמו BigQuery, לגשת לנתונים ב-Cloud SQL ולבצע שאילתות על הנתונים האלה דרך חיבור פנימי, אתם צריכים להוסיף את הפרמטר --enable-google-private-path לפקודה. Google Cloud

    צריך ליצור את הרפליקה באותה רשת VPC שבה נמצאת המכונה הראשית. אפשר גם לציין allocated-ip-range-name ברשת ה-VPC הזו. אם לא מציינים טווח, הרפליקה נוצרת בטווח אקראי.

  • רישום בינארי נתמך במופעי העתקה לקריאה (MySQL 5.7 ואילך בלבד). לא נתמך ברפליקות של מעבר לגיבוי בעת כשל ב-HA מדור קודם). מפעילים רישום ביומן בינארי ברפליקה באמצעות אותה פקודה gcloud CLI, אבל משתמשים בשם המכונה של הרפליקה במקום בשם המכונה של השרת הראשי. 
    gcloud sql instances patch REPLICA_INSTANCE_NAME \
--enable-bin-log \
--enforce-new-sql-network-architecture

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

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

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

  • משתמשים בדגל enforce-new-network-architecture כדי לאכוף את השימוש בארכיטקטורת הרשת החדשה עבור המכונה עם היצירה שלה, גם אם הפרויקט לא שודרג באופן מלא. פרטים נוספים על ארכיטקטורת הרשת החדשה וההשלכות שלה מופיעים במאמרים שדרוג מכונה לארכיטקטורת הרשת החדשה והקצאת טווח כתובות IP.

Terraform

כדי ליצור העתק לקריאה, משתמשים במשאב של Terraform. 

resource "google_sql_database_instance" "read_replica" {
  name                 = "mysql-replica-instance-name"
  master_instance_name = google_sql_database_instance.primary.name
  region               = "europe-west4"
  database_version     = "MYSQL_8_0"

  replica_configuration {
    failover_target = false
  }

  settings {
    tier              = "db-n1-standard-2"
    availability_type = "ZONAL"
    disk_size         = "100"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

החלה של השינויים

כדי להחיל את ההגדרות של Terraform בפרויקט ב- Google Cloud , מבצעים את השלבים בקטעים הבאים.

הכנת Cloud Shell

  1. מפעילים את Cloud Shell.

  2. מגדירים את פרויקט ברירת המחדל שבו רוצים להחיל את ההגדרות של Terraform. Google Cloud

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

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

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

הכנת הספרייה

לכל קובץ תצורה של Terraform צריכה להיות ספרייה משלו (שנקראת גם מודול ברמה הבסיסית).

  1. יוצרים ספרייה חדשה ב-Cloud Shell ובה יוצרים קובץ חדש. שם הקובץ חייב לכלול את הסיומת .tf, למשל main.tf. במדריך הזה, הקובץ נקרא main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

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

    מעתיקים את הקוד לדוגמה בקובץ main.tf החדש שיצרתם.

    לחלופין, אפשר גם להעתיק את הקוד מ-GitHub. כדאי לעשות את זה כשקטע הקוד של Terraform הוא חלק מפתרון מקצה לקצה.

  3. בודקים את הפרמטרים לדוגמה ומשנים אותם בהתאם לסביבה שלכם.
  4. שומרים את השינויים.
  5. מפעילים את Terraform. צריך לעשות זאת רק פעם אחת לכל ספרייה. 
    terraform init

    אופציונלי: תוכלו לכלול את האפשרות -upgrade, כדי להשתמש בגרסה העדכנית ביותר של הספק של Google: 

    terraform init -upgrade

החלה של השינויים

  1. בודקים את ההגדרות ומוודאים שהמשאבים שמערכת Terraform תיצור או תעדכן תואמים לציפיות שלכם: 
    terraform plan

    מתקנים את ההגדרות לפי הצורך.

  2. מריצים את הפקודה הבאה ומזינים yes בהודעה שמופיעה, כדי להחיל את הגדרות Terraform: 
    terraform apply

    ממתינים עד שב-Terraform תוצג ההודעה "Apply complete!‎".

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

מחיקת השינויים

כדי למחוק את השינויים:

  1. כדי להשבית את ההגנה מפני מחיקה, בקובץ התצורה של Terraform מגדירים את הארגומנט deletion_protection לערך false. 
    deletion_protection =  "false"
  2. מריצים את הפקודה הבאה ומזינים yes בהודעה שמופיעה, כדי להחיל את הגדרות Terraform המעודכנות: 
    terraform apply

  1. כדי להסיר משאבים שהוחלו בעבר על הגדרות Terraform, מריצים את הפקודה הבאה ומזינים yes בהודעה שמופיעה:

    terraform destroy

REST v1

  1. קבלת הגדרות הגיבוי הנוכחיות

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

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

    • ‫project-id: מזהה הפרויקט
    • ‫primary-instance-name: השם של המופע הראשי

    ה-method של ה-HTTP וכתובת ה-URL: 

    GET https://sqladmin.googleapis.com/v1/projects/project-id/instances/primary-instance-name

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

    אתם אמורים לקבל תגובת JSON שדומה לזו:

  2. מוודאים ששדות השכפול מוגדרים

    אם אחד מהערכים enabled או pointInTimeEnabled הוא false, צריך להשתמש בשיטה patch של משאב המופעים כדי להפעיל את שניהם. בבקשה, מציינים את המאפיינים של הגדרת הגיבוי שרוצים לשנות.

    כדי להפעיל גיבויים, מגדירים את enabled ל-true ואת startTime לשעה ביום בפורמט HH:MM. הפרמטר startTime מצוין בפורמט של 24 שעות, באזור הזמן UTC±00, ומציין את ההתחלה של חלון גיבוי של 4 שעות. הגיבויים יכולים להתחיל בכל שלב במהלך חלון הגיבוי.

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

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

    • ‫PROJECT_ID: המזהה או מספר הפרויקט של Google Cloud הפרויקט שמכיל את המופע
    • ‫INSTANCE_NAME: השם של המופע הראשי או של העותק לקריאה שאתם מגדירים עבור זמינות גבוהה
    • ‫START_TIME: השעה (בדקות ושעות)

    ה-method של ה-HTTP וכתובת ה-URL: 

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    תוכן בקשת JSON: 

    {
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

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

    אתם אמורים לקבל תגובת JSON שדומה לזו:

  3. יצירת העתק לקריאה

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

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

    • ‫project-id: מזהה הפרויקט
    • ‫database-version: מחרוזת גרסת ה-Enum (לדוגמה, MYSQL_8_0)
    • ‫primary-instance-name: השם של המופע הראשי
    • ‫primary-instance-region: האזור של המכונה הראשית
    • ‫replica-region: האזור של מכונת הרפליקה
    • ‫replica-name: השם של מכונת הרפליקה
    • ‫machine-type: מחרוזת enum של סוג המכונה. לדוגמה: db-custom-1-3840
    • ‫private-network: הרשת המורשית שמוסיפים או בוחרים כדי ליצור חיבור פרטי.

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

    ה-method של ה-HTTP וכתובת ה-URL: 

    POST https://sqladmin.googleapis.com/v1/projects/project-id/instances

    תוכן בקשת JSON: 

    {
  "masterInstanceName": "primary-instance-name",
  "project": "project-id",
  "databaseVersion": "database-version",
  "name": "replica-name",
  "region": "replica-region",
  "settings":
  {
    "tier": "machine-type",
    "settingsVersion": 0,
    "ipConfiguration": {
    object (IpConfiguration)
  },
  {
  "ipv4Enabled": false,
  "privateNetwork": private-network,
  "requireSsl": boolean,
  "authorizedNetworks": [
    {
      object (AclEntry)
    }
  ],
  "allocatedIpRange": string
    }
  },
  "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE"
}

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

    אתם אמורים לקבל תגובת JSON שדומה לזו:

REST v1beta4

  1. קבלת הגדרות הגיבוי הנוכחיות

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

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

    • ‫project-id: מזהה הפרויקט
    • ‫primary-instance-name: השם של המופע הראשי

    ה-method של ה-HTTP וכתובת ה-URL: 

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/primary-instance-name

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

    אתם אמורים לקבל תגובת JSON שדומה לזו:

  2. מוודאים ששדות השכפול מוגדרים

    אם enabled או binaryLogEnabled מוגדרים כ-false במופע הראשי, צריך להשתמש בשיטה patch של משאב המופעים כדי להפעיל את שניהם. בבקשה, מציינים את המאפיינים של הגדרת הגיבוי שרוצים לשנות.

    כדי להפעיל גיבויים, מגדירים את enabled ל-true ואת startTime לשעה ביום בפורמט HH:MM. הפרמטר startTime מצוין בפורמט של 24 שעות, באזור הזמן UTC±00, ומציין את ההתחלה של חלון גיבוי של 4 שעות. הגיבויים יכולים להתחיל בכל שלב במהלך חלון הגיבוי.

    כדי להפעיל שחזור מערכת מנקודה מסוימת בזמן (PITR), מגדירים את binaryLogEnabled ל-true במכונה הראשית.

    רישום בינארי נתמך במופעי העתקה לקריאה (MySQL 5.7 ואילך בלבד). מפעילים יומן בינארי בעותק משוכפל עם אותו API, באמצעות מזהה המופע של העותק המשוכפל במקום מזהה המופע של השרת הראשי.

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

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

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

    • ‫PROJECT_ID: המזהה או מספר הפרויקט של Google Cloud הפרויקט שמכיל את המופע
    • ‫INSTANCE_NAME: השם של המופע הראשי או של העותק לקריאה שאתם מגדירים עבור זמינות גבוהה
    • ‫START_TIME: השעה (בדקות ושעות)

    ה-method של ה-HTTP וכתובת ה-URL: 

    PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

    תוכן בקשת JSON: 

    {
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

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

    אתם אמורים לקבל תגובת JSON שדומה לזו:

  3. יצירת העתק לקריאה

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

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

    • ‫project-id: מזהה הפרויקט
    • ‫database-version: מחרוזת גרסת ה-Enum (לדוגמה, MYSQL_8_0)
    • ‫primary-instance-name: השם של המופע הראשי
    • ‫primary-instance-region: האזור של המכונה הראשית
    • ‫replica-region: האזור של מכונת הרפליקה
    • ‫replica-name: השם של מכונת הרפליקה
    • ‫machine-type: מחרוזת enum של סוג המכונה. לדוגמה: db-custom-1-3840
    • ‫private-network: הרשת המורשית שמוסיפים או בוחרים כדי ליצור חיבור פרטי.

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

    ה-method של ה-HTTP וכתובת ה-URL: 

    POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances

    תוכן בקשת JSON: 

    {
  "masterInstanceName": "primary-instance-name",
  "project": "project-id",
  "databaseVersion": "database-version",
  "name": "replica-name",
  "region": "replica-region",
  "settings":
  {
    "tier": "machine-type",
    "settingsVersion": 0,
    
    "ipConfiguration": {
    object (IpConfiguration)
  },
  {
  "ipv4Enabled": false,
  "privateNetwork": private-network,
  "requireSsl": boolean,
  "authorizedNetworks": [
    {
      object (AclEntry)
    }
  ],
  "allocatedIpRange": string
    }
    
  },
  "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE"
}

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

    אתם אמורים לקבל תגובת JSON שדומה לזו:

יצירת העתק לקריאה של מופע עם Private Service Connect מופעל

כדי ליצור רפליקה לקריאה של מופע עם Private Service Connect מופעל, משתמשים ב-ה-CLI של gcloud או ב-API. אפשר ליצור את הרפליקה הזו באותו אזור או באזור אחר מהמופע הראשי (רפליקת קריאה חוצה אזורים).

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

gcloud

כדי ליצור העתק לקריאה של מכונה, משתמשים בפקודה gcloud sql instances create:

gcloud sql instances create REPLICA_INSTANCE_NAME \
--master-instance-name=PRIMARY_INSTANCE_NAME \
--project=PROJECT_ID \
--region=REGION_NAME \
--enable-private-service-connect \
--allowed-psc-projects=ALLOWED_PROJECTS \
--availability-type=AVAILABILITY_TYPE \
--no-assign-ip

מחליפים את הפרטים הבאים:

  • ‫REPLICA_INSTANCE_NAME: השם של מכונת הרפליקה.
  • ‫PRIMARY_INSTANCE_NAME: השם של המכונה הראשית.
  • ‫PROJECT_ID: המזהה או מספר הפרויקט של Google Cloud הפרויקט שמכיל את המופע.
  • ‫REGION_NAME: שם האזור של מכונת הרפליקה.

  • ‫ALLOWED_PROJECTS: רשימה של מספרי פרויקטים או מזהי פרויקטים מותרים, מופרדת בפסיקים. אם פרויקט לא מופיע ברשימה הזו, אי אפשר להשתמש בו כדי ליצור מופע ולהפעיל בו את Private Service Connect.

    ‫Cloud SQL לא מעתיק את הפרויקטים המורשים למופע הראשי אל העותק. לכל רפליקה צריך ליצור נקודת קצה מסוג Private Service Connect. אם אתם משתמשים בשרת proxy ל-Cloud SQL Auth או במחברי שפה ל-Cloud SQL, אתם צריכים ליצור תחום DNS ורשומת DNS עבור הרפליקות.

  • ‫AVAILABILITY_TYPE: הפעלת זמינות גבוהה למכונה. לפרמטר הזה מציינים אחד מהערכים הבאים:
    • ‫REGIONAL: הפעלה של זמינות גבוהה. מומלץ למופעי ייצור. המופע עובר לזמינות חלקית באזור אחר בתוך האזור שנבחר.
    • ZONAL: לא מספקות יכולת מעבר לגיבוי (failover). זה ערך ברירת המחדל.

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

REST v1

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

  • ‫PRIMARY_INSTANCE_NAME: השם של המכונה הראשית.
  • ‫PROJECT_ID: המזהה או מספר הפרויקט של Google Cloud הפרויקט שמכיל את המופע.
  • ‫REPLICA_INSTANCE_NAME: השם של מכונת הרפליקה.
  • ‫REGION_NAME: שם האזור של מכונת הרפליקה.
  • ‫MACHINE_TYPE: סוג המכונה של המופע.
  • ‫AVAILABILITY_TYPE: הפעלת זמינות גבוהה למכונה. לפרמטר הזה מציינים אחד מהערכים הבאים:
    • ‫REGIONAL: הפעלה של זמינות גבוהה. מומלץ למופעי ייצור. המופע עובר לזמינות חלקית באזור אחר בתוך האזור שנבחר.
    • ZONAL: לא מספקות יכולת מעבר לגיבוי (failover). זה ערך ברירת המחדל.

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

  • ‫ALLOWED_PROJECTS: רשימה של מספרי פרויקטים או מזהי פרויקטים מותרים, מופרדת בפסיקים. אם פרויקט לא מופיע ברשימה הזו, אי אפשר להשתמש בו כדי ליצור מופע ולהפעיל בו את Private Service Connect.

    ‫Cloud SQL לא מעתיק את הפרויקטים המורשים למופע הראשי אל העותק. לכל רפליקה צריך ליצור נקודת קצה מסוג Private Service Connect. אם אתם משתמשים בשרת proxy ל-Cloud SQL Auth או במחברי שפה ל-Cloud SQL, אתם צריכים ליצור תחום DNS ורשומת DNS עבור הרפליקות.

ה-method של ה-HTTP וכתובת ה-URL: 

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances

תוכן בקשת JSON: 

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "MYSQL_8_0",
  "name": "REPLICA_INSTANCE_NAME",
  "region": "REGION_NAME",
  "kind": "sql#instance",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "ipConfiguration": {
      "ipv4Enabled": false,
      "pscConfig": {
        "allowedConsumerProjects": [ALLOWED_PROJECTS],
        "pscEnabled": true
      }
    },
    "kind": "sql#settings",
    "pricingPlan": "PER_USE",
    "replicationType": "ASYNCHRONOUS",
    "tier": "MACHINE_TYPE"
  }
}

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

אתם אמורים לקבל תגובת JSON שדומה לזו:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "CREATE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

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

  • ‫PRIMARY_INSTANCE_NAME: השם של המכונה הראשית.
  • ‫PROJECT_ID: המזהה או מספר הפרויקט של Google Cloud הפרויקט שמכיל את המופע.
  • ‫REPLICA_INSTANCE_NAME: השם של מכונת הרפליקה.
  • ‫REGION_NAME: שם האזור של מכונת הרפליקה.
  • ‫MACHINE_TYPE: סוג המכונה של המופע.
  • ‫AVAILABILITY_TYPE: הפעלת זמינות גבוהה למכונה. לפרמטר הזה מציינים אחד מהערכים הבאים:
    • ‫REGIONAL: הפעלה של זמינות גבוהה. מומלץ למופעי ייצור. המופע עובר לזמינות חלקית באזור אחר בתוך האזור שנבחר.
    • ZONAL: לא מספקות יכולת מעבר לגיבוי (failover). זה ערך ברירת המחדל.

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

  • ‫ALLOWED_PROJECTS: רשימה של מספרי פרויקטים או מזהי פרויקטים מותרים, מופרדת בפסיקים. אם פרויקט לא מופיע ברשימה הזו, אי אפשר להשתמש בו כדי ליצור מופע ולהפעיל בו את Private Service Connect.

    ‫Cloud SQL לא מעתיק את הפרויקטים המורשים למופע הראשי אל העותק. לכל רפליקה צריך ליצור נקודת קצה מסוג Private Service Connect. אם אתם משתמשים בשרת proxy ל-Cloud SQL Auth או במחברי שפה ל-Cloud SQL, אתם צריכים ליצור תחום DNS ורשומת DNS עבור הרפליקות.

ה-method של ה-HTTP וכתובת ה-URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances

תוכן בקשת JSON: 

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "MYSQL_8_0",
  "name": "REPLICA_INSTANCE_NAME",
  "region": "REGION_NAME",
  "kind": "sql#instance",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "ipConfiguration": {
      "ipv4Enabled": false,
      "pscConfig": {
        "allowedConsumerProjects": [ALLOWED_PROJECTS],  
        "pscEnabled": true
      }
    },
    "kind": "sql#settings",
    "pricingPlan": "PER_USE",
    "replicationType": "ASYNCHRONOUS",
    "tier": "MACHINE_TYPE"
  }
}

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

אתם אמורים לקבל תגובת JSON שדומה לזו:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "CREATE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

הדגל cloudsql_iam_authentication לא מופעל אוטומטית בעותקי קריאה כשהוא מופעל במופע הראשי.

כדי להגדיר רפליקה לקריאה לאימות מסד נתונים ב-IAM:

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

    כניסה לדף Cloud SQL Instances

  2. כדי לפתוח את הדף סקירה כללית של מכונה, לוחצים על שם המכונה.
  3. בכרטיס ההגדרה, מחפשים את הדגל cloudsql_iam_authentication. אם הדגל לא מופיע ברשימה, אין צורך להפעיל אותו בעותק לקריאה. אם הדגל מופיע ברשימה, צריך להפעיל אותו בעותק לקריאה. אם צריך להפעיל את הדגל ב-read replica, ממשיכים לשלב הבא.
  4. בתפריט הניווט של SQL, בוחרים באפשרות Replicas (רפליקות).
  5. לוחצים על השם של הרפליקה שרוצים לערוך.
  6. לוחצים על Edit.
  7. בקטע Configuration options (אפשרויות הגדרה), מרחיבים את Flags (דגלים).
  8. בוחרים באפשרות + הוספה.
  9. מזינים cloudsql_iam_authentication בשם הדגל. מוודאים שהאפשרות On (מופעל) נבחרה בשביל הדגל הזה.
  10. לוחצים על Save.

יצירת רפליקות מדורגות

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

מידע על שכפול מדורג זמין במאמר שכפול מדורג.

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

המסוף

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

    כניסה לדף Cloud SQL Instances

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

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

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

gcloud

  1. אם אתם משתמשים ב-MySQL בגרסה 5.7 ואילך, צריך להפעיל את קובצי ה-binlog בשרת הראשי של הרפליקה החדשה:
    ‫
    gcloud sql instances patch --enable-bin-log PARENT_REPLICA_NAME
     מחליפים את PARENT_REPLICA_NAME בשם של הרפליקה ההורה.
  2. יוצרים את הרפליקה החדשה על ידי ציון הרפליקה הראשית כמכונה הראשית באמצעות הדגל --master-instance-name:
    3. gcloud sql instances create REPLICA_NAME \
      --master-instance-name=PARENT_REPLICA_NAME \
     מחליפים את מה שכתוב בשדות הבאים:
    • ‫REPLICA_NAME: המזהה הייחודי של הרפליקה שאתם יוצרים
    • ‫PARENT_REPLICA_NAME: השם של הרפליקה הראשית
  3. אחרי שיוצרים את העותק המשוכפל המדורג, אפשר לראות שהשינויים שבוצעו במופע הראשי משוכפלים בכל העותקים המשוכפלים בשרשרת של העותקים המשוכפלים המדורגים.

curl

  1. אם אתם משתמשים ב-MySQL בגרסה 5.7 ואילך, צריך להפעיל רישום ביומן בינארי:

    כדי להפעיל רישום ביומן בינארי, שומרים את ה-JSON הבא בקובץ בשם request.JSON, ואז מפעילים את פקודת ה-curl כדי להפעיל רישום ביומן בינארי. 
    {
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": true
    }
  }
}
  2. כדי ליצור רפליקה מתחת לרפליקה הראשית, עורכים את דוגמת קוד ה-JSON הבאה ושומרים אותה בקובץ בשם request.json: 
    {
  "masterInstanceName": "PARENT_REPLICA_NAME",
  "project": "PROJECT_ID",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
    {
      "tier": "MACHINE_TYPE",
    }
}
  3. מריצים את הפקודה הבאה: 
    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"

פתרון בעיות

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

קודם כול, בודקים שהערך של הדגל max_connections גדול מהערך בשרת הראשי או שווה לו.

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

אם השגיאה היא: set Service Networking service account as servicenetworking.serviceAgent role on consumer project, צריך להשבית ואז להפעיל מחדש את Service Networking API. הפעולה הזו יוצרת את חשבון השירות שנדרש כדי להמשיך בתהליך.
הדיסק מלא. יכול להיות שהגודל של הדיסק של המופע הראשי יתמלא במהלך יצירת רפליקה. עורכים את המופע הראשי כדי לשדרג אותו לגודל דיסק גדול יותר.
מופע הרפליקה משתמש ביותר מדי זיכרון. הרפליקה משתמשת בזיכרון זמני כדי לשמור במטמון פעולות קריאה שמבוקשות לעיתים קרובות, מה שעלול לגרום לה להשתמש ביותר זיכרון מהמופע הראשי.

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

עורכים את המופע כדי להפעיל את automatic storage increase.
ההשהיה בשכפול גבוהה באופן עקבי. עומס הכתיבה גבוה מדי בשביל הרפליקה. השהיית שכפול מתרחשת כשהשרשור של SQL ברפליקה לא מצליח לעמוד בקצב של השרשור של IO. סוגים מסוימים של שאילתות או עומסי עבודה עלולים לגרום לעיכובים זמניים או קבועים בשכפול של סכימה נתונה. חלק מהסיבות הנפוצות להשהיה בשכפול:
  • שאילתות איטיות ברפליקה. איתור ותיקון של הבעיות.
  • לכל הטבלאות צריך להיות מפתח ייחודי/ראשי. כל עדכון בטבלה כזו בלי מפתח ייחודי או ראשי גורם לסריקות מלאות של הטבלה ברפליקה.
  • שאילתות כמו DELETE ... WHERE field < 50000000 גורמות להשהיית רפליקציה ברפליקציה מבוססת-שורות, כי מספר עצום של עדכונים מצטבר ברפליקה.

הנה כמה פתרונות אפשריים:
הפיגור בשכפול עולה בפתאומיות. הסיבה לכך היא עסקאות שפועלות במשך זמן רב. כשמתבצעת פעולת אישור (commit) של טרנזקציה (דף חשבון יחיד או כמה דפי חשבון) במופע המקור, שעת ההתחלה של הטרנזקציה נרשמת ביומן הבינארי. כשעותק המשנה מקבל את אירוע ה-binlog הזה, הוא משווה את חותמת הזמן הזו לחותמת הזמן הנוכחית כדי לחשב את השהיית השכפול. לכן, טרנזקציה שפועלת לאורך זמן במקור תגרום להשהיה גדולה בשכפול ברפליקה. אם כמות השינויים בשורות בעסקה גדולה, ייקח הרבה זמן גם לרפליקה לבצע אותה. במהלך הזמן הזה, ההשהיה בשכפול גדלה. אחרי שהרפליקה תסיים את העסקה הזו, משך תקופת ההשלמה יהיה תלוי בעומס העבודה של הכתיבה במקור ובמהירות העיבוד של הרפליקה.

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

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

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

  1. משנים את הדגלים binlog_transaction_dependency_tracking ו-transaction_write_set_extraction:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. מוסיפים את הדגל slave_pending_jobs_size_max:

    slave_pending_jobs_size_max=33554432

  3. משנים את הדגל transaction_write_set_extraction:

    transaction_write_set_extraction=XXHASH64

  4. משנים את הדגל binlog_transaction_dependency_tracking:

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

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

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