מידע על רפליקציה ב-Cloud SQL

MySQL   |  PostgreSQL   |  SQL Server

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

מבוא

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

דוגמאות לסיבות אחרות:

• העברת נתונים בין אזורים
• העברת נתונים בין פלטפורמות
• העברת נתונים ממסד נתונים מקומי ל-Cloud SQL

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

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

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

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

ב-Cloud SQL יש תמיכה בסוגים הבאים של רפליקות:

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

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

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

אפשר גם להשתמש ב-Database Migration Service כדי לשכפל באופן רציף משרת מסד נתונים של מקור ל-Cloud SQL.

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

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

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

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

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

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

הערה: טרנזקציות פעילות לטווח ארוך עשויות להשפיע על היצירה של רפליקות לקריאה בלבד. מומלץ ליצור עותק לקריאה בלבד במקרים הבאים:

• כשהמכונה נמצאת בדרישות תנועה נמוכות.
• אחרי שהעסקאות הארוכות מסתיימות.

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

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

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

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

בחירת סוג מכונה מתאים

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

נפח האחסון ברפליקות לקריאה בלבד

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

רפליקות לקריאה באזורים שונים

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

רפליקות באזורים שונים:

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

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

רפליקות מדורגות לקריאה בלבד

רפליקציה מדורגת מאפשרת ליצור רפליקה לקריאה מתחת לרפליקה אחרת לקריאה באותו אזור או באזור אחר. התרחישים הבאים הם תרחישים לדוגמה לשימוש ברפליקות מדורגות:

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

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

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

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

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

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

תוכנית התאוששות מאסון (DR)

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

הגדרות אישיות

הפסקה זמנית בשירות

קידום

אם רוצים להשתמש במכונה באזור ב' בהגדרה של תוכנית התאוששות מאסון (DR) ויש לכם:

• רפליקות באותו אזור שמחוברות למכונה הראשית (רפליקה א')
• רפליקות באזורים אחרים (רפליקה מדורגת) שמחוברות לרפליקה הראשית.

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

בכרטיסייה Outage, אם יש הפסקה זמנית בשירות באזור A, הרפליקה המשורשרת מקודמת למכונה ראשית. כבר יש לו רפליקות לקריאה בלבד, מה שמקצר את יעד זמן ההתאוששות (RTO).

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

רפליקציה במספר אזורים

תרחיש לדוגמה נוסף של רפליקות מדורגות הוא הפצת קיבולת הקריאה לאזור שני באופן חסכוני. אפשר ליצור רפליקות מדורגות C ו-D שמשוכפלות מרפליקה B. הלקוחות יכולים להפיץ שאילתות קריאה בין הרפליקות B,‏ C ו-D כדי להפחית את העומס על כל רפליקה. העלות של תנועת הרשת בין האזורים נצברת רק פעם אחת, מהמכונה הראשית לרפליקה B. השכפול מ-B ל-C ול-D מתבצע באמצעות העברה ברשת בתוך האזור, שהיא בחינם.

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

ראשי א' ← רפליקה ב' ← רפליקה ג' ורפליקה ד'

הגבלות

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

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

רפליקות לקריאה בלבד הן מכונות MySQL חיצוניות שמשכפלות ממכונה ראשית של Cloud SQL. לדוגמה, מכונה של MySQL שפועלת ב-Compute Engine נחשבת למכונה חיצונית.

לעותקי קריאה חיצוניים יש את המגבלות הבאות:

• העותק הראשי של הרפליקה החיצונית לא יכול להיות רפליקה לקריאה בלבד של Cloud SQL.
• יכול להיות שלא תוכלו לשכפל למכונה של MySQL שמתארחת בפלטפורמת ענן אחרת. כדאי לבדוק את התיעוד של הספק האחר. לדוגמה, צריך להגדיר את שדה התצורה replicate-ignore-db, ואין תמיכה בספקי שירותי ענן שלא מאפשרים את זה. במאמר הגדרת רפליקות חיצוניות מפורטים שדות תצורה נדרשים אחרים.
• אם הרפליקציה מופסקת לכמה שעות, למשל בגלל הפסקת חשמל ברשת או בשרת, הרפליקה תפגר אחרי המקור. הרפליקה מתעדכנת כשהיא מתחברת מחדש לשרת הראשי ומתחילה לשכפל שוב. עם זאת, אם הרפליקציה מופסקת למשך זמן ארוך יותר מהזמן שבו נשמרים יומני הרפליקציה של Cloud SQL (שבעה גיבויים), צריך למחוק את הרפליקה וליצור אחת חדשה.
• הנתונים שמועברים מהרפליקה הראשית לרפליקה החיצונית מחויבים כהעברת נתונים יוצאת. בדף התמחור תוכלו לראות את מחירי העברת הנתונים לפי סוג המכונה של Cloud SQL.

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

  gcloud

  כדי להגדיר הרשאת IP למכונה שתאפשר תעבורת נתונים מטווחים של כתובות IP של רפליקה חיצונית לקריאה בלבד, משתמשים בפקודה gcloud sql instances patch:

  gcloud sql instances patch \
  --authorized-networks=IP_ADDRESS_RANGE_1/24,IP_ADDRESS_RANGE_2/24

  מחליפים את IP_ADDRESS_RANGE_1 ואת IP_ADDRESS_RANGE_2 בטווחי כתובות ה-IP של הרפליקה החיצונית לקריאה בלבד.

  REST

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

  • ‫PROJECT_ID: המזהה או מספר הפרויקט של הפרויקט ב- Google Cloud שמכיל את המכונה
  • ‫INSTANCE_NAME: השם של מכונת Cloud SQL
  • ‫IP_ADDRESS_RANGE_1: טווח כתובות ה-IP הראשון של הרפליקה החיצונית לקריאה בלבד
  • ‫IP_ADDRESS_RANGE_2: טווח כתובות ה-IP השני של הרפליקה החיצונית לקריאה בלבד

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

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

  תוכן בקשת JSON:

  {
    "kind": "sql#instance",
    "name": INSTANCE_NAME,
    "project": PROJECT_ID,
    "settings": {
      "ipConfiguration": {
        "authorizedNetworks": [{"kind": "sql#aclEntry", "value": "IP_ADDRESS_RANGE_1/24"}, {"kind": "sql#aclEntry", "value": "IP_ADDRESS_RANGE_2/24"}]},
    "kind": "sql#settings"
    }
  }

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

  ‫Curl (Linux,‏ macOS או Cloud Shell)

  הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

  שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

  curl -X PATCH \
       -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/INSTANCE_NAME"

  ‎PowerShell (Windows)

  הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

  שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

  $cred = gcloud auth print-access-token
  $headers = @{ "Authorization" = "Bearer $cred" }
  
  Invoke-WebRequest `
      -Method PATCH `
      -Headers $headers `
      -ContentType: "application/json; charset=utf-8" `
      -InFile request.json `
      -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

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

  {
    "kind": "sql#operation",
    "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME",
    "status": "PENDING",
    "user": "[e-mail]",
    "insertTime": "2020-01-16T02:32:12.281Z",
    "operationType": "UPDATE",
    "name": "OPERATION_ID",
    "targetId": "INSTANCE_NAME",
    "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
    "targetProject": "PROJECT_ID"
  }
  

תרחישי שימוש ברפליקציה

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

שם	ראשי	רפליקה	יתרונות ותרחישים לדוגמה	מידע נוסף
עותק לקריאה בלבד	מכונה של Cloud SQL	מכונה של Cloud SQL	קיבולת קריאה נוספת יעד ב-Analytics	יצירת רפליקות לקריאה ניהול רפליקות לקריאה מדדי רפליקציה זמן השהיה של שכפול אינדקסים של עותקים לקריאה בלבד
רפליקה לקריאה באזורים שונים	מכונה של Cloud SQL	מכונה של Cloud SQL	קיבולת קריאה נוספת יעד ב-Analytics יכולת נוספת של תוכנית התאוששות מאסון (DR) שיפור ביצועי קריאה העברת נתונים בין אזורים	יצירת רפליקות לקריאה ניהול רפליקות לקריאה מדדי רפליקציה
רפליקה חיצונית לקריאה בלבד	מכונה עצמאית או ראשית של Cloud SQL	מכונה של MySQL מחוץ ל-Cloud SQL	זמן אחזור קצר יותר בחיבורים חיצוניים יעד ב-Analytics נתיב העברה לפלטפורמות אחרות	הגדרת רפליקות חיצוניות
שכפול משרת חיצוני	מכונה של MySQL מחוץ ל-Cloud SQL	מכונה של Cloud SQL ל-MySQL	נתיב ההעברה ל-Cloud SQL שכפול נתונים אל Google Cloud יעד ב-Analytics	שכפול משרת חיצוני

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

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

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

דרישות נוספות לרפליקה החיצונית:

• גרסת ה-MySQL של הרפליקה צריכה להיות זהה לגרסת ה-MySQL של המכונה הראשית או גבוהה ממנה. מידע נוסף
• מטעמי אבטחה, צריך להגדיר SSL או TLS במכונה הראשית. מידע נוסף

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

ההשפעה של הפעלת יומן בינארי

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

• תקורה של ביצועים

  ב-Cloud SQL נעשה שימוש ברפליקציה מבוססת-שורות עם הדגלים sync_binlog=1 ו-innodb_support_xa=true של MySQL. לכן, נדרש fsync נוסף בדיסק לכל פעולת כתיבה, מה שמפחית את הביצועים.

• תקורה של אחסון

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

  כדי לראות את הגודל של היומנים הבינאריים, אפשר להשתמש בפקודה SHOW BINARY LOGS ב-MySQL.

  כשמבצעים גיבויים, היומנים נשמרים בגיבוי יחד עם הנתונים.

רישום ביומן בינארי ברפליקות לקריאה בלבד

• יש תמיכה ברישום ביומן בינארי במכונות של רפליקות לקריאה בלבד (MySQL 5.7 ו-8.0 בלבד). כדי להפעיל יומן בינארי ברפליקה, משתמשים באותן פקודות API כמו במכונה הראשית, אבל עם שם המכונה של הרפליקה במקום שם המכונה הראשית. שימו לב שהמונחים enable binary logging ו-enable point-in-time recovery הם חלופיים.

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

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

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

חיוב

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

הפניה מהירה לרפליקות לקריאה בלבד ב-Cloud SQL

נושא	קבוצת הדיון
גיבויים	אי אפשר להגדיר גיבויים ברפליקה.
ליבות וזיכרון	עותקים לקריאה בלבד יכולים להשתמש במספר ליבות ובכמות זיכרון שונים מאלה של המכונה הראשית.
מחיקת המכונה הראשית	כדי למחוק מכונה ראשית, צריך לקדם את כל הרפליקות לקריאה בלבד שלה למכונות עצמאיות או למחוק את הרפליקות לקריאה בלבד.
מחיקת הרפליקה	כשמוחקים רפליקה, אין לכך השפעה על הסטטוס של המכונה הראשית.
השבתת הרישום ביומן הבינארי	כדי להשבית את היומנים הבינאריים במכונה ראשית, צריך לקדם או למחוק את כל הרפליקות לקריאה בלבד שלה.
יתירות כשל	מופע ראשי יכול לעבור למצב של יתירות כשל ברפליקה רק אם הרפליקה היא מסוג DR. עותקים לקריאה בלבד לא יכולים לעבור למצב יתירות כשל במהלך הפסקה.
זמינות גבוהה	רפליקות לקריאה בלבד מאפשרות להפעיל זמינות גבוהה ברפליקות.
איזון עומסים	ב-Cloud SQL אין איזון עומסים בין רפליקות. אתם יכולים להטמיע איזון עומסים במכונה של Cloud SQL. כדי לשפר את הביצועים, אתם יכולים גם להשתמש במאגר חיבורים כדי להפיץ שאילתות בין רפליקות באמצעות הגדרת איזון העומסים.
חלונות זמן לתחזוקה	הרפליקות לקריאה חולקות את חלונות הזמן לתחזוקה עם המכונה הראשית. הרפליקות פועלות לפי הגדרות התחזוקה של המכונה הראשית, כולל חלון הזמן לתחזוקה, תזמון מחדש ופרק הזמן לדחיית עדכונים ותחזוקה. במהלך התחזוקה, Cloud SQL מעדכן קודם את כל הרפליקות לקריאה בלבד, ורק אחר כך את המכונה הראשית.
כמה עותקים לקריאה בלבד	ב-Cloud SQL יש תמיכה ברפליקות מדורגות. כתוצאה מכך, אפשר ליצור עד 10 רפליקות למכונה ראשית אחת, וליצור רפליקות של הרפליקות האלה, עד ארבע רמות כולל המכונה הראשית.
רפליקציה מקבילה	מידע נוסף על שימוש ברפליקציה מקבילה לשיפור הביצועים זמין במאמר הגדרת רפליקציה מקבילה.
כתובת IP פרטית	אם אתם מתחברים לרפליקה באמצעות כתובת IP פרטית, אתם לא צריכים ליצור חיבור VPC פרטי נוסף לרפליקה, כי היא עוברת בירושה מהמכונה הראשית.
שחזור המכונה הראשית	אי אפשר לשחזר את המכונה הראשית של רפליקה כל עוד הרפליקה קיימת. לפני שמשחזרים מכונה מגיבוי או מבצעים בה שחזור מערכת מנקודה מסוימת בזמן (PITR), צריך לקדם או למחוק את כל הרפליקות שלה.
הגדרות	הגדרות ה-MySQL של המכונה הראשית מופצות לרפליקה, כולל סיסמת הבסיס והשינויים בטבלת המשתמשים. שינויים במעבד ובזיכרון לא מופצים לרפליקה.
הפסקת רפליקה	אי אפשר stop רפליקה. אפשר restart, delete או disable replication, אבל אי אפשר לעצור אותו כמו מכונה ראשית.
שדרוג רפליקה	עותקים לקריאה בלבד יכולים לעבור שדרוג משבש בכל שלב.
טבלאות משתמשים	אי אפשר לבצע שינויים ברפליקה. כל השינויים של המשתמשים צריכים להתבצע במופע הראשי.

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

• איך יוצרים עותק לקריאה בלבד
• איך מגדירים רפליקה חיצונית
• איך משכפלים את הנתונים משרת חיצוני
• איך מגדירים שרת חיצוני
• מידע על רפליקציה ב-MySQL
• איך מגדירים מכונה לזמינות גבוהה
• מידע על התאוששות מתקדמת מאסון (DR)