רפליקציה היא היכולת ליצור עותקים של מכונת 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, המשתמשים יכולים לנהל את השכפול שלהם באמצעות התכונות של שכפול לוגי ב-PostgreSQL.Cloud SQL לא תומך בשכפול בין שני שרתים חיצוניים.
רפליקות לקריאה
אתם משתמשים בעותק לקריאה כדי להפחית את העומס על מכונת Cloud SQL. העותק לקריאה הוא עותק מדויק של המופע הראשי. הנתונים ושינויים אחרים במכונה הראשית מתעדכנים ברפליקה לקריאה כמעט בזמן אמת.
העתקים לקריאה בלבד הם לקריאה בלבד, ואי אפשר לכתוב להם. העותק לקריאה מעבד שאילתות, בקשות קריאה ותנועה של ניתוח נתונים, וכך מפחית את העומס על המופע הראשי.
מתחברים ישירות לרפליקה באמצעות שם החיבור וכתובת ה-IP שלה. אם אתם מתחברים לרפליקה באמצעות כתובת IP פרטית, אתם לא צריכים ליצור חיבור פרטי נוסף ל-VPC עבור הרפליקה, כי החיבור עובר בירושה מהמכונה הראשית.
מידע על יצירת עותק לקריאה זמין במאמר יצירת עותקים לקריאה. מידע על ניהול רפליקה לקריאה מופיע במאמר בנושא ניהול רפליקות לקריאה.
כשיטה מומלצת, אם משתמשים בזמינות גבוהה במופע הראשי, כדאי למקם את העותקים לקריאה באזור אחר מהמופע הראשי. השיטה הזו מבטיחה שרפליקות קריאה ימשיכו לפעול כשהאזור שמכיל את המופע הראשי חווה הפסקה זמנית בשירות. מידע נוסף זמין במאמר סקירה כללית של זמינות גבוהה.
בחירת סוג מכונה מתאים
לעותקי קריאה יכולים להיות מספר שונה של מעבדים וירטואליים וזיכרון בהשוואה לשרת הראשי. כדאי לעקוב אחרי מדדים במכונה, כמו השימוש במעבד ובזיכרון, כדי לוודא שהגודל של מכונת הרפליקה מתאים לעומס העבודה שלה, במיוחד אם היא קטנה יותר מהמכונה הראשית. אם גודל המופע המשוכפל קטן מדי, הוא יהיה מועד יותר לביצועים ירודים, כמו אירועים תכופים של חריגה מזיכרון (OOM).
נפח אחסון בעותקי קריאה
כשמשנים את הגודל של מכונה ראשית, כל הרפליקות לקריאה שלה משנות את הגודל, אם צריך, כך שלפחות יהיה להן נפח אחסון כמו למכונה הראשית המעודכנת.
ההשפעה על הדגל max_connections כשעותק הקריאה כולל סוג מכונה עם פחות זיכרון מהמכונה הראשית
במופע PostgreSQL, אם לא מגדירים את הערך של הדגל max_connections, Cloud SQL מגדיר אותו באופן אוטומטי על סמך כמות הזיכרון במופע. מידע נוסף זמין במאמר בנושא דגלים נתמכים. ב-PostgreSQL, הערך של max_connections צריך להיות תמיד לפחות גדול כמו שהוא במקור, גם בעותק לקריאה. לכן, אם העותק לקריאה כולל פחות זיכרון מהעותק הראשי, ולא הגדרתם את הדגל max_connections, יכול להיות שהוא יקבל בירושה ערך גדול יותר של max_connections על סמך הגודל של המופע הראשי. במצב כזה, אם אתם מסתמכים על ההגדרה max_connections כדי להגביל את מספר החיבורים למופע הרפליקה, יכול להיות שיווצר עומס יתר כי הערך גבוה מדי ביחס לסוג המכונה של המופע. כדי להימנע מכך, אפשר:
- משנים את הגודל של מופע הרפליקה לסוג מכונה גדול יותר.
- צריך להגדיר את אפליקציית הלקוח כך שמספר החיבורים יהיה קטן מהערך של
max_connections. - מגדירים את הדגל
max_connectionsבשרת הראשי ובשרת הרפליקה לערך מתאים.
פעולות של אינדקס גיבוב באמצעות עותקים לקריאה
פעולות של אינדקס גיבוב לא משתמשות ב-write-ahead-logging ב-PostgreSQL 9.6. ב-Cloud SQL יש רק גרסה אחת שזמינה בPostgreSQL 10. המידע הזה מופיע בתיבת האזהרה הצהובה בדף הגרסה של PostgreSQL. הדבר נכון גם לגבי רפליקות לקריאה ב-Cloud SQL.
מכיוון שעדכונים של אינדקס הגיבוב לא מועברים לרפליקה לקריאה ב-PostgreSQL 9.6, הרפליקה לא יכולה להשתמש בהם. כפתרון עקיף, אפשר להימנע משימוש בעותקים לקריאה או לשדרג לגרסה ראשית של PostgreSQL (גרסה 10 ומעלה).
רפליקות לקריאה באזורים שונים
רפליקציה בין אזורים מאפשרת ליצור עותק לקריאה באזור שונה מהמופע הראשי. יוצרים רפליקה לקריאה באזור אחר באותו אופן שבו יוצרים רפליקה באותו אזור.
רפליקות בין אזורים:
- כדי לשפר את ביצועי הקריאה, כדאי להפוך רפליקות לזמינות קרוב יותר לאזור של האפליקציה.
- לספק יכולת נוספת להתאוששות מאסון כדי להגן מפני כשל אזורי.
- מאפשרת להעביר נתונים מאזור אחד לאזור אחר.
מידע נוסף על רפליקות חוצות-אזורים זמין במאמר העלאת רפליקות בדרגה להעברה אזורית או להתאוששות מאסון.
שכפול קריאה מדורג
שכפול מדורג מאפשר ליצור רפליקה לקריאה מתחת לרפליקה אחרת לקריאה באותו אזור או באזור אחר. התרחישים הבאים הם תרחישי שימוש בהעתקים מדורגים:
- תוכנית התאוששות מאסון (DR): אפשר להשתמש בהיררכיה מדורגת של רפליקות לקריאה כדי לדמות את הטופולוגיה של המופע הראשי והרפליקות לקריאה שלו. במהלך הפסקה זמנית בשירות, העותק לקריאה שנבחר מקודם לראשי, והעותקים לקריאה שמתחת לראשי החדש ממשיכים לשכפל ומוכנים לשימוש.
- שיפורים בביצועים: הפחתת העומס על המופע הראשי על ידי העברת עבודת הרפליקציה למספר רפליקות לקריאה.
- הגדלת קריאות: אפשר להגדיל את מספר הרפליקות כדי לחלק את עומס הקריאה.
- הפחתת עלויות: אתם יכולים להפחית את עלויות הרישות על ידי שימוש ברפליקה יחידה של שכפול מדורג עם רפליקציה באזורים שונים באזורים אחרים.
הסברים על המונחים
- שכפול מדורג: עותק לקריאה שיכול להיות לו עותק משלו.
- רמות: אפשר ליצור רמות של רפליקות בהיררכיית רפליקות מדורגת. לדוגמה, אם מוסיפים ארבעה עותקים למקרה שימוש, ארבעת העותקים האלה נמצאים באותה רמה.
- מופעים מקבילים: כמה עותקים משוכפלים שמשוכפלים מאותו מופע ראשי. פריטים באותה רמה בהיררכיית הרפליקה. לרפליקה יכולים להיות עד שמונה אחים.
- רפליקה מסוג leaf: רפליקה לקריאה שאין לה רפליקות משלה. בהיררכיית שכפול מרובת רמות, הרפליקה ברמת העלה היא הרמה האחרונה.
- קידום פעולה שממירה העתק, בכל רמה בהיררכיה, למופע ראשי. כשמקודמים את העותק, היררכיית העותקים המשוכפלים שלו נשמרת.
הגדרת עותקים משוכפלים מדורגים
שכפול מדורג מאפשר להוסיף עותקים לקריאה לכל עותק קיים. אפשר להוסיף עד ארבע רמות של רפליקות, כולל המופע הראשי. כשמקדמים את הרפליקה בחלק העליון של היררכיית רפליקות מדורגת, היא הופכת למופע ראשי והרפליקות המדורגות שלה ממשיכות לשכפל.
כדי לתכנן את ההגדרות, צריך להגדיר מטרה לשימוש ברפליקות לקריאה. בשני הסעיפים הבאים מתוארות ההגדרות לתוכנית התאוששות מאסון (DR) ולרפליקציה במספר אזורים.
תוכנית התאוששות מאסון (DR)
כדי להבין איך רפליקות מדורגות עוזרות לכם להתאושש במהירות במהלך הפסקה זמנית בשירות, כדאי לעיין בתרחיש הרפליקציה הבא:
הגדרות אישיות
הפסקה זמנית בשירות
קידום
אם רוצים להשתמש במופע באזור ב' בהגדרת תוכנית התאוששות מאסון (DR) ויש:
- עותקים זהים באותו אזור שמצורפים למכונה הראשית (עותק זהה א')
- עותקים משוכפלים באזורים אחרים (עותק משוכפל מדורג) שמצורפים לעותק הראשי.
אפשר ליצור עותקים לקריאה מתחת לעותק המשוכפל המדורג באזור ב'.
בכרטיסייה Outage (הפסקת פעולה), אם יש הפסקת פעולה באזור א', העותק המשוכפל המדורג מקודם למופע ראשי. כבר יש לו רפליקות לקריאה מתחתיו, מה שמקצר את משך ההתאוששות (RTO).
בכרטיסייה קידום, אפשר לראות שכאשר מקדמים רפליקה מדורגת, גם הרפליקות שלה מקודמות וממשיכות לשכפל מתחתיה.
רפליקציה במספר אזורים
תרחיש שימוש נוסף עבור רפליקות מדורגות הוא להפיץ יכולת קריאה לאזור שני בצורה חסכונית. אפשר ליצור עותקים משוכפלים מדורגים C ו-D שמשוכפלים מעותק משוכפל B. לקוחות יכולים להפיץ שאילתות קריאה בין הרפליקות ב', ג' ו-ד' כדי להפחית את העומס על כל רפליקה. העלות של תעבורת נתונים ברשת בין אזורים נצברת רק פעם אחת, מהמופע הראשי אל הרפליקה B. שכפול מ-B ל-C ול-D משתמש בהעברה ברשת באזור, שהיא בחינם.
אפשר ליצור היררכיה של עד ארבעה מופעים באמצעות רפליקות מדורגות לרפליקציה במספר אזורים:
Primary A → Replica B → Replica C and Replica D
הגבלות
- אי אפשר למחוק רפליקה שיש מתחתיה רפליקות. כדי למחוק את העותק, צריך להתחיל עם העותקים של העלים ולהתקדם כלפי מעלה בהיררכיה.
- אין תמיכה בתלות אזורית מעגלית. כדי שהרפליקה של רפליקה מדורגת תהיה באותו אזור כמו המופע הראשי, הרפליקה המדורגת צריכה להיות גם היא באותו אזור.
שכפול לוגי
Cloud SQL מאפשר לכם להגדיר פתרונות שכפול משלכם באמצעות תכונות השכפול הלוגי של PostgreSQL. רפליקציה לוגית היא פתרון גמיש שמאפשר:
- רפליקציה רגילה ממכונה ראשית למכונת העתקה
- שכפול סלקטיבי של טבלאות או שורות מסוימות בלבד
- שכפול בין גרסאות ראשיות של PostgreSQL
- שכפול למסדי נתונים שאינם PostgreSQL
- תהליכי עבודה של סימון נתונים שהשתנו (CDC) שבהם כל השינויים במסד הנתונים מועברים בסטרימינג לצרכן
מידע נוסף זמין במאמר בנושא הגדרה של שכפול לוגי. בדף הזה מופיע מידע על:
- שכפול לוגי מובנה
- התוסף pglogical
תרחישי שימוש בשכפול
תרחישי השימוש הבאים רלוונטיים לכל סוג של שכפול.
| שם | ראשי | רפליקה | יתרונות ותרחישי שימוש | מידע נוסף |
|---|---|---|---|---|
| עותק לקריאה | מופע Cloud SQL | מופע Cloud SQL |
|
|
| עותק לקריאה באזור אחר | מופע Cloud SQL | מופע Cloud SQL |
|
|
| שכפול לוגי | כל מופע עצמאי או ראשי של PostgreSQL | כל מכונת PostgreSQL או צרכן חיצוני |
|
חיוב
- החיוב על רפליקה לקריאה זהה לחיוב על מופע רגיל של Cloud SQL. אין חיוב על שכפול הנתונים.
- התמחור של רפליקת קריאה חוצה-אזורים זהה לתמחור של יצירת מופע חדש של Cloud SQL באזור. אפשר לעיין במחירון של מופעי Cloud SQL ולבחור את האזור המתאים. בנוסף לעלות הרגילה שמשויכת למופע, שכפול חוצה אזורים כרוך בחיובים על העברת נתונים חוצה אזורים עבור יומני שכפול שנשלחים מהמופע הראשי למופע המשוכפל, כפי שמתואר בתמחור של תעבורת נתונים יוצאת (egress) ברשת.
הסבר מהיר על רפליקות לקריאה ב-Cloud SQL
| נושא | קבוצת הדיון |
|---|---|
| גיבויים | אי אפשר להגדיר גיבויים ברפליקה. |
| ליבות וזיכרון | העותקים לקריאה יכולים להשתמש במספר ליבות שונה ובכמות זיכרון שונה מאלה של המופע הראשי. |
| מחיקת המכונה הראשית | כדי למחוק מופע ראשי, צריך להעלות בדרגה את כל הרפליקות לקריאה בלבד למופעים עצמאיים או למחוק אותן. |
| מחיקת הרפליקה | כשמוחקים רפליקה, אין לכך השפעה על הסטטוס של המופע הראשי. |
| השבתת כתיבה מראש ביומן (WAL) | כדי להשבית את יומני כתיבה מראש במופע ראשי, צריך להעלות בדרגה או למחוק את כל הרפליקות לקריאה שלו. |
| מעבר לגיבוי (Failover) | מופע ראשי יכול לבצע יתירות כשל למופע רפליקה רק אם המופע רפליקה הוא מופע רפליקה של DR. במהלך הפסקה זמנית בשירות, רפליקות לקריאה לא יכולות לבצע יתירות כשל בשום צורה. |
| זמינות גבוהה | רפליקות לקריאה מאפשרות להפעיל זמינות גבוהה ברפליקות. |
| איזון עומסים | ב-Cloud SQL אין איזון עומסים בין העותקים המשוכפלים. אתם יכולים לבחור להטמיע איזון עומסים במופע Cloud SQL. אפשר גם להשתמש באיגום חיבורים כדי להפיץ שאילתות בין העותקים עם הגדרת איזון העומסים, וכך לשפר את הביצועים. |
| חלונות זמן לתחזוקה | רפליקות לקריאה חולקות את חלונות הזמן לתחזוקה עם המכונה הראשית. הרפליקות פועלות לפי הגדרות התחזוקה של המכונה הראשית, כולל חלון הזמן לתחזוקה, שינוי מועד התחזוקה ותקופת התחזוקה האסורה. במהלך התחזוקה, מערכת Cloud SQL מעדכנת קודם את כל הרפליקות לקריאה לפני שהיא מעדכנת את המכונה הראשית. |
| עותקי קריאה מרובים | Cloud SQL תומך ברפליקות מדורגות. כתוצאה מכך, אפשר ליצור עד 10 רפליקות למופע ראשי יחיד וליצור רפליקות של הרפליקות האלה, עד ארבע רמות כולל המופע הראשי. |
| כתובת IP פרטית | אם מתחברים לרפליקה באמצעות כתובת IP פרטית, לא צריך ליצור חיבור VPC פרטי נוסף לרפליקה, כי היא מקבלת אותו בירושה מהמופע הראשי. |
| שחזור המכונה הראשית | אי אפשר לשחזר את המופע הראשי של רפליקה כל עוד הרפליקה קיימת. לפני שמשחזרים מופע מגיבוי או מבצעים בו שחזור מערכת מנקודה מסוימת בזמן (PITR), צריך לקדם את כל הרפליקות שלו או למחוק אותן. |
| הגדרות | ההגדרות של המופע הראשי מועברות לרפליקה, כולל הסיסמה של משתמש postgres ושינויים בטבלת המשתמשים. |
| הפסקת רפליקה | אי אפשר stop רפליקה. אפשר restart, delete או disable replication, אבל אי אפשר לעצור אותה כמו שניתן לעצור מופע ראשי. |
| שדרוג רפליקה | שדרוג משבש יכול להתרחש בכל שלב בעותקי קריאה. |
| טבלאות משתמשים | אי אפשר לבצע שינויים ברפליקה. כל השינויים שקשורים למשתמשים צריכים להתבצע במופע הראשי. |