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

באמצעות אכיפת מחברים, אתם יכולים לאכוף שימוש רק בשרת proxy ל-Cloud SQL Auth או במחברים של Cloud SQL Language כדי להתחבר למכונות 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. העותק לקריאה הוא עותק מדויק של המופע הראשי. הנתונים ושינויים אחרים במכונה הראשית מתעדכנים כמעט בזמן אמת ברפליקה לקריאה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שכפול קריאה מדורג

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

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

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

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

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

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

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

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

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

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

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

קידום

אם רוצים להשתמש במופע באזור ב' בהגדרת התאוששות מאסון ויש:

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

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

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

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

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

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

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

Primary A → Replica B → Replica C and Replica D

הגבלות

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

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

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

ההגבלות הבאות חלות על רפליקות לקריאה חיצוניות:

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

• אם יוצרים רפליקה חיצונית לקריאה של מכונה, ומגדירים שרק שרת ה-proxy ל-Cloud SQL Auth או מחברי השפה של Cloud SQL ישמשו לחיבור למכונה שמוגדרת לה גישה לשירותים פרטיים, צריך להוסיף את טווחי רשתות המשנה של הרפליקה לרשתות המורשות של המכונה הראשית. אתם צריכים להגדיר את כל הטווחים כרשתות מאושרות של מופע 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 יכולת נוספת של התאוששות מאסון שיפור ביצועי קריאה העברת נתונים בין אזורים	יצירת עותקים לקריאה ניהול רפליקות לקריאה מדדי שכפול
עותק לקריאה חיצוני	מכונה עצמאית או ראשית של 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 משתמש בשכפול מבוסס-שורות עם פלאגים של MySQL‏ sync_binlog=1 ו-innodb_support_xa=true. לכן, נדרש fsync נוסף לדיסק לכל פעולת כתיבה, מה שמפחית את הביצועים.

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

  האחסון של יומני הנתונים הבינאריים מחויב באותו תעריף כמו נתונים רגילים. יומני ה-binary נחתכים אוטומטית לגיל של הגיבוי האוטומטי הכי ישן. ‫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

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

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

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