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

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

מבוא

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

סיבות אחרות:

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

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

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

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

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

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

רפליקות לקריאה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תרחיש שימוש נוסף עבור רפליקות מדורגות הוא להפיץ יכולת קריאה לאזור שני בצורה חסכונית. אפשר ליצור עותקים משוכפלים מדורגים C ו-D שמשוכפלים מעותק משוכפל B. לקוחות יכולים להפיץ שאילתות קריאה בין הרפליקות ב', ג' ו-ד' כדי להפחית את העומס על כל רפליקה. העלות של תעבורת נתונים ברשת בין אזורים נצברת רק פעם אחת, מהמופע הראשי אל הרפליקה 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: המזהה או מספר הפרויקט של Cloud de Confiance הפרויקט שמכיל את המופע
  • ‫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)

  שומרים את גוף הבקשה בקובץ בשם 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)

  שומרים את גוף הבקשה בקובץ בשם 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": "user@example.com",
    "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 שכפול נתונים אל Cloud de Confiance by S3NS יעד ב-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)