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

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

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

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

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

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

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

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

כך יוצרים עותק לקריאה בלבד:

המסוף

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

    כניסה לדף Cloud SQL Instances

  2. מוצאים את המכונה שרוצים ליצור לה רפליקה ופותחים את התפריט more actions לצד הרשומה.
  3. בוחרים באפשרות Create read replica.

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

  4. אם במכונה הופעלו גיבויים ורישום ביומן בינארי, ממשיכים לשלב הבא. אם לא, בוחרים באפשרויות Automate backups ו-Enable binary logging, לוחצים על Continue ואז על Save and restart כדי להפעיל מחדש את המכונה.

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

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

    מידע נוסף על כל הגדרה זמין בדף מידע על הגדרות המכונה.

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

  6. לוחצים על Create replica.

    אם צריך, 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 פנימית, ואתם רוצים לאפשר לשירותי Cloud de Confiance by S3NS אחרים, כמו BigQuery, לגשת לנתונים ב-Cloud SQL ולבצע שאילתות על הנתונים האלה באמצעות חיבור פנימי, הוסיפו את הפרמטר --enable-google-private-path לפקודה.

    צריך ליצור את הרפליקה באותה רשת 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 בפרויקט ב- Cloud de Confiance :

הכנת Cloud Shell

  1. מפעילים את Cloud Shell.
  2. מגדירים את פרויקט ברירת המחדל ב- Cloud de Confiance שבו רוצים להחיל את ההגדרות של Terraform.

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

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

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

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

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

    terraform destroy

REST v1

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

    משתמשים ב-method‏ get של המשאב instances כדי להחזיר את גרסת מסד הנתונים ואת הגדרת הגיבוי הנוכחית של המכונה הראשית.

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

    • ‫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, צריך להשתמש ב-method‏ patch של המשאב instances כדי להפעיל את שניהם. בבקשה, מציינים את המאפיינים של הגדרת הגיבוי שרוצים לשנות.

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

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

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

    • ‫PROJECT_ID: המזהה או מספר הפרויקט של הפרויקט ב- Cloud de Confiance שמכיל את המכונה
    • ‫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. יצירת העותק לקריאה בלבד

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

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

    • ‫project-id: מזהה הפרויקט
    • ‫database-version: מחרוזת גרסה של טיפוס בן מנייה (לדוגמה, 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. קבלת הגדרת הגיבוי הנוכחית

    משתמשים ב-method‏ get של המשאב instances כדי להחזיר את גרסת מסד הנתונים ואת הגדרת הגיבוי הנוכחית של המאסטר.

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

    • ‫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 במכונה הראשית, צריך להשתמש ב-method‏ patch של המשאב instances כדי להפעיל את שניהם. בבקשה, מציינים את המאפיינים של הגדרת הגיבוי שרוצים לשנות.

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

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

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

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

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

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

    • ‫PROJECT_ID: המזהה או מספר הפרויקט של הפרויקט ב- Cloud de Confiance שמכיל את המכונה
    • ‫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. יצירת העותק לקריאה בלבד

    משתמשים ב-method‏ insert של המשאב instances כדי ליצור את הרפליקה לקריאה בלבד. המאפיין databaseVersion חייב להיות זהה למאפיין הראשי. אם למכונה הראשית יש כתובת IP פנימית, אפשר לציין allocatedIpRange באותו אופן שבו יוצרים מכונה ראשית. כדי ליצור רפליקה לקריאה באזור אחר, צריך לציין אזור שונה מהאזור של המכונה הראשית.

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

    • ‫project-id: מזהה הפרויקט
    • ‫database-version: מחרוזת גרסה של טיפוס בן מנייה (לדוגמה, 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: המזהה או מספר הפרויקט ב- Cloud de Confiance שמכיל את המכונה.
  • ‫REGION_NAME: שם האזור של מכונת הרפליקה.
  • ‫ALLOWED_PROJECTS: רשימה של מזהי פרויקטים או מספרי פרויקטים מותרים, מופרדים בפסיקים. אם פרויקט לא מופיע ברשימה הזו, אי אפשר להשתמש בו כדי ליצור מכונה ולהפעיל בה את Private Service Connect.

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

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

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

REST v1

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

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

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

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

    ‫Cloud SQL לא מעתיק לרפליקה את הפרויקטים המורשים של המכונה הראשית. לכל רפליקה צריך ליצור נקודת קצה (endpoint) מסוג Private Service Connect. אם אתם משתמשים ב-Cloud SQL Auth Proxy או ב-Cloud SQL Language Connectors, אתם צריכים ליצור תחום 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: המזהה או מספר הפרויקט ב- Cloud de Confiance שמכיל את המכונה.
  • ‫REPLICA_INSTANCE_NAME: השם של מכונת הרפליקה.
  • ‫REGION_NAME: שם האזור של מכונת הרפליקה.
  • ‫MACHINE_TYPE: סוג המכונה.
  • ‫AVAILABILITY_TYPE: הפעלת זמינות גבוהה למכונה. בפרמטר הזה, מציינים את אחד מהערכים הבאים:
    • ‫REGIONAL: הפעלת זמינות גבוהה, מומלץ למכונות בסביבת הייצור. המכונה עוברת למצב של מעבר לגיבוי בעת כשל באזור אחר בתוך האזור שבחרתם.
    • ‫ZONAL: לא מספק יכולת יתירות כשל. זה ערך ברירת המחדל.

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

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

    ‫Cloud SQL לא מעתיק לרפליקה את הפרויקטים המורשים של המכונה הראשית. לכל רפליקה צריך ליצור נקודת קצה (endpoint) מסוג Private Service Connect. אם אתם משתמשים ב-Cloud SQL Auth Proxy או ב-Cloud SQL Language Connectors, אתם צריכים ליצור תחום 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 במסוף Cloud de Confiance .

    כניסה לדף Cloud SQL Instances

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

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

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

במאמר רפליקות מדורגות מוסבר איך הן פועלות.

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

המסוף

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

    כניסה לדף Cloud SQL Instances

  2. ב-MySQL מגרסה 5.7 ואילך, מפעילים את הרפליקציה.
  3. בכרטיסייה Replicas, לוחצים על הרפליקה שתשמש כהורה לרפליקה שרוצים ליצור.
  4. לוחצים על Create replica.
  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: השם של הרפליקה הראשית
  4. אחרי שיוצרים את הרפליקה המשורשרת, אפשר לראות שהשינויים שבוצעו במכונה הראשית משוכפלים בכל הרפליקות בשרשרת הרפליקות המשורשרות.

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

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

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

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

עורכים את המכונה כדי להפעיל את automatic storage increase.

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

פתרונות אפשריים:

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

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

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

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