רפליקציה היא היכולת ליצור עותקים של מכונת Cloud SQL או של מסד נתונים מקומי, ולהעביר את העבודה לעותקים.
מבוא
הסיבה העיקרית לשימוש ברפליקציה היא להרחיב את השימוש בנתונים במסד נתונים בלי לפגוע בביצועים.
דוגמאות לסיבות אחרות:
- העברת נתונים בין אזורים
- העברת נתונים בין פלטפורמות
- העברת נתונים ממסד נתונים מקומי ל-Cloud SQL
בנוסף, אפשר לקדם רפליקה אם המכונה המקורית נפגמת.
כשמתייחסים למכונה של Cloud SQL, המכונה שמשוכפלת נקראת המכונה הראשית והעותקים נקראים רפליקות לקריאה בלבד. המכונה הראשית והרפליקות לקריאה בלבד נמצאות ב-Cloud SQL.
כשמתייחסים למסד נתונים מקומי, תרחיש הרפליקה נקרא רפליקה משרת חיצוני. בתרחיש הזה, מסד הנתונים שמשוכפל הוא שרת מסד הנתונים של המקור. העותקים שנמצאים ב-Cloud SQL נקראים רפליקות של Cloud SQL. יש גם מכונה שמייצגת את שרת מסד הנתונים של המקור ב-Cloud SQL, שנקראת מכונה לייצוג המקור.
בתרחיש של תוכנית התאוששות מאסון (DR), אפשר לקדם רפליקה כדי להמיר אותה למכונה ראשית. כך תוכלו להשתמש בה במקום מכונה שנמצאת באזור שבו יש הפסקה זמנית בפעילות. אפשר גם לקדם רפליקה כדי להחליף מכונה פגומה.
ב-Cloud SQL יש תמיכה בסוגים הבאים של רפליקות:
באמצעות אכיפת מחברים, אתם יכולים לאכוף שימוש רק ב-Cloud SQL Auth Proxy או במחברי שפה של Cloud SQL כדי להתחבר למכונות של Cloud SQL. כשמפעילים אכיפת מחבר, Cloud SQL דוחה חיבורים ישירים למסד הנתונים. אי אפשר ליצור רפליקות לקריאה בלבד למכונה שמופעלת בה אכיפת מחבר. באופן דומה, אם למכונה יש רפליקות לקריאה בלבד, אי אפשר להפעיל אכיפת מחבר במכונה.
אפשר גם להשתמש ב-Database Migration Service כדי לשכפל באופן רציף משרת מסד נתונים של מקור ל-Cloud SQL. הערה: Cloud SQL מאפשר למשתמשים לנהל את הרפליקציה שלהם באמצעות תכונות הרפליקציה הלוגית של PostgreSQL.ב-Cloud SQL אין תמיכה ברפליקציה בין שני שרתים חיצוניים.
עותקים לקריאה בלבד
אתם משתמשים ברפליקה לקריאה בלבד כדי להפחית את העומס על מכונה של Cloud SQL. הרפליקה לקריאה בלבד היא עותק מדויק של המכונה הראשית. נתונים ושינויים אחרים במכונה הראשית משוכפלים באופן אסינכרוני ומוחלים על הרפליקה לקריאה בלבד.
רפליקות לקריאה בלבד הן לקריאה בלבד, ואי אפשר לכתוב בהן. עותק לקריאה בלבד מעבד שאילתות, בקשות קריאה ותנועת ניתוח נתונים, וכך מפחית את העומס על המכונה הראשית.
מתחברים לרפליקה ישירות באמצעות שם החיבור וכתובת ה-IP שלה. אם אתם מתחברים לרפליקה באמצעות כתובת IP פרטית, אתם לא צריכים ליצור חיבור פרטי נוסף ל-VPC בשביל הרפליקה, כי החיבור עובר בירושה מהמכונה הראשית.
במאמר יצירת עותקים לקריאה בלבד מוסבר איך יוצרים עותק לקריאה בלבד. למידע על ניהול רפליקה לקריאה בלבד, ראו ניהול רפליקות לקריאה בלבד.
כשמשתמשים בזמינות גבוהה במכונה הראשית, מומלץ להציב את העותקים לקריאה בלבד באזור שונה מזה של המכונה הראשית. כך אפשר לוודא שהרפליקות לקריאה בלבד ימשיכו לפעול גם אם יש הפסקה זמנית בשירות באזור שבו נמצא המכונה הראשית. מידע נוסף זמין במאמר סקירה כללית של זמינות גבוהה.
בחירת סוג מכונה מתאים
לעותקי ה-Read Replica יכולים להיות מספר שונה של מעבדי vCPU וזיכרון מאלה של המכונה הראשית. כדאי לעקוב אחרי המדדים במכונה, כמו השימוש במעבד (CPU) ובזיכרון, כדי לוודא שהגודל של מכונת הרפליקה מתאים לעומס העבודה שלה, במיוחד אם היא קטנה יותר מהמכונה הראשית. מופע של רפליקה קטנה מדי נוטה יותר לביצועים נמוכים, כמו אירועים תכופים של חוסר בזיכרון (OOM).
נפח האחסון ברפליקות לקריאה בלבד
כשמשנים את הגודל של מכונה ראשית, כל הרפליקות לקריאה שלה משתנות בהתאם, אם צריך, כדי שיהיה להן לפחות את אותו נפח אחסון כמו למכונה הראשית המעודכנת.
ההשפעה על הדגל max_connections כשלעותק המשוכפל לקריאה בלבד יש סוג מכונה עם פחות זיכרון מאשר למכונה הראשית
במכונה של PostgreSQL, אם לא מגדירים את הדגל max_connections לערך לבחירתכם, Cloud SQL מגדיר אותו באופן אוטומטי על סמך כמות הזיכרון במכונה. מידע נוסף זמין במאמר דגלים נתמכים. ב-PostgreSQL, הערך של max_connections ברפליקה לקריאה בלבד צריך להיות תמיד לפחות באותו גודל כמו הערך ברפליקה הראשית. לכן, אם לרפליקה לקריאה בלבד יש פחות זיכרון מאשר למכונה הראשית, ולא הגדרתם את הדגל max_connections, היא עשויה לרשת ערך גדול יותר של max_connections על סמך הגודל של המכונה הראשית. במצב כזה, אם אתם מסתמכים על ההגדרה max_connections כדי להגביל את מספר החיבורים למכונה המשוכפלת, יכול להיות שהיא תהיה עמוסה מדי כי הערך גבוה מדי ביחס לסוג המכונה של המכונה. כדי למנוע את זה, אתם יכולים:
- משנים את הגודל של מכונת הרפליקה לסוג מכונה גדול יותר.
- מגדירים את אפליקציית הלקוח כך שתגביל את מספר החיבורים לערך נמוך מ-
max_connections. - מגדירים את הדגל
max_connectionsבראשי וברפליקה לערך מתאים.
פעולות של אינדקס גיבוב (hash) באמצעות עותקים לקריאה בלבד
פעולות של אינדקס גיבוב לא משתמשות בכתיבה מראש ביומן (WAL) ב-PostgreSQL 9.6. ל-Cloud SQL יש רק גרסה אחת זמינה ב-PostgreSQL 10. הבעיה הזו מתועדת בתיבת האזהרה הצהובה בדף הגרסה של PostgreSQL. הדבר נכון גם לגבי רפליקות לקריאה בלבד של Cloud SQL.
עדכונים של אינדקס גיבוב (hash) לא מופצים לרפליקה לקריאה בלבד ב-PostgreSQL 9.6, ולכן הרפליקה לא יכולה להשתמש בהם. כדי לעקוף את הבעיה, אפשר להימנע משימוש בעותקים לקריאה בלבד או לשדרג לגרסה ראשית של PostgreSQL (גרסה 10 ומעלה).
רפליקות לקריאה באזורים שונים
רפליקה לקריאה בלבד בין אזורים מאפשרת ליצור רפליקה לקריאה בלבד באזור שונה מהמכונה הראשית. כדי ליצור עותק לקריאה בלבד באזור אחר, פועלים באותו אופן שבו יוצרים עותק באותו אזור.
רפליקות באזורים שונים:
- שיפור ביצועי הקריאה על ידי הפיכת הרפליקות לזמינות קרוב יותר לאזור של האפליקציה.
- לספק יכולת נוספת של התאוששות מאסון כדי להגן מפני כשל אזורי.
- להעביר נתונים מאזור אחד לאחר.
למידע נוסף על רפליקות באזורים שונים, ראו קידום רפליקות להעברה אזורית או להתאוששות מאסון.
רפליקות מדורגות לקריאה בלבד
רפליקציה מדורגת מאפשרת ליצור רפליקה לקריאה מתחת לרפליקה אחרת לקריאה באותו אזור או באזור אחר. התרחישים הבאים הם תרחישים לדוגמה לשימוש ברפליקות מדורגות:
- תוכנית התאוששות מאסון (DR): אתם יכולים להשתמש בהיררכיה מדורגת של רפליקות לקריאה בלבד כדי לדמות את הטופולוגיה של המכונה הראשית והרפליקות שלה לקריאה בלבד. במהלך הפסקה, כשמשדרגים רפליקה לקריאה בלבד לראשית, הרפליקות לקריאה בלבד שמתחת לראשית החדשה ממשיכות לשכפל ומוכנות לשימוש.
- שיפור הביצועים: הפחתת העומס על המכונה הראשית על ידי העברת עבודת הרפליקציה לכמה רפליקות לקריאה בלבד.
- הגדלת מספר הקריאות: אפשר להשתמש ביותר רפליקות כדי לחלוק את עומס הקריאה.
- הפחתת עלויות: אתם יכולים להפחית את עלויות הרשת באמצעות רפליקה מדורגת אחת עם שכפול באזורים אחרים.
הסברים על המונחים
- רפליקה מדורגת: רפליקה לקריאה בלבד שיכולה להיות לה רפליקה משלה.
- Levels: אתם יכולים ליצור רמות של רפליקות בהיררכיית רפליקות מדורגת. לדוגמה, אם מוסיפים ארבע רפליקות למכונה, ארבע הרפליקות האלה נמצאות באותה רמה.
- מכונות אחיות: כמה רפליקות שמשוכפלות מאותה מכונה ראשית. רפליקות אחיות נמצאות באותה רמה בהיררכיית הרפליקות. לרפליקה יכולים להיות עד שמונה אחים.
- רפליקת עלה: רפליקה לקריאה בלבד שאין לה רפליקות משלה. בהיררכיית רפליקציה עם כמה רמות, הרפליקה ברמת העלה היא הרמה האחרונה.
- קידום פעולה שממירה רפליקה, בכל רמה בהיררכיה, למכונה ראשית. כשמשדרגים, היררכיית הרפליקות המשורשרות של הרפליקה נשמרת.
הגדרת רפליקות מדורגות
רפליקות מדורגות מאפשרות להוסיף רפליקות לקריאה בלבד לכל רפליקה קיימת. אפשר להוסיף עד ארבע רמות של רפליקות, כולל המכונה הראשית. כשמקַדמים את הרפליקה בראש היררכיית הרפליקות המשורשרות, היא הופכת למכונה ראשית והרפליקות המשורשרות שלה ממשיכות לשכפל.
כדי לתכנן את ההגדרות, צריך להגדיר מטרה לרפליקות לקריאה בלבד. בשני החלקים הבאים מתוארות ההגדרות לתוכנית התאוששות מאסון (DR) ולרפליקציה בכמה אזורים.
תוכנית התאוששות מאסון (DR)
כדי להבין איך רפליקות מדורגות עוזרות להתאושש במהירות בזמן הפסקה, נבחן את תרחיש הרפליקציה הבא:
הגדרות אישיות
הפסקה זמנית בשירות
קידום
אם רוצים להשתמש במכונה באזור ב' בהגדרה של תוכנית התאוששות מאסון (DR) ויש לכם:
- רפליקות באותו אזור שמחוברות למכונה הראשית (רפליקה א')
- רפליקות באזורים אחרים (רפליקה מדורגת) שמחוברות לרפליקה הראשית.
אפשר ליצור עותקים לקריאה בלבד מתחת לעותק המשורשר באזור ב'.
בכרטיסייה Outage, אם יש הפסקה זמנית בשירות באזור A, הרפליקה המשורשרת מקודמת למכונה ראשית. כבר יש לו רפליקות לקריאה בלבד, מה שמקצר את יעד זמן ההתאוששות (RTO).
בכרטיסייה Promote, אפשר לראות שכאשר מקדמים רפליקה מדורגת, גם הרפליקות שלה מקודמות וממשיכות לשכפל תחתיה.
רפליקציה במספר אזורים
תרחיש לדוגמה נוסף של רפליקות מדורגות הוא הפצת קיבולת הקריאה לאזור שני באופן חסכוני. אפשר ליצור רפליקות מדורגות C ו-D שמשוכפלות מרפליקה B. הלקוחות יכולים להפיץ שאילתות קריאה בין הרפליקות B, C ו-D כדי להפחית את העומס על כל רפליקה. העלות של תנועת הרשת בין האזורים נצברת רק פעם אחת, מהמכונה הראשית לרפליקה B. השכפול מ-B ל-C ול-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) | כדי להשבית את יומני הכתיבה מראש במכונה ראשית, צריך לקדם או למחוק את כל הרפליקות לקריאה בלבד שלה. |
| יתירות כשל | מופע ראשי יכול לעבור למצב של יתירות כשל ברפליקה רק אם הרפליקה היא מסוג DR. עותקים לקריאה בלבד לא יכולים לעבור למצב יתירות כשל במהלך הפסקה. |
| זמינות גבוהה | רפליקות לקריאה בלבד מאפשרות להפעיל זמינות גבוהה ברפליקות. |
| איזון עומסים | ב-Cloud SQL אין איזון עומסים בין רפליקות. אתם יכולים להטמיע איזון עומסים במכונה של Cloud SQL. כדי לשפר את הביצועים, אתם יכולים גם להשתמש במאגר חיבורים כדי להפיץ שאילתות בין רפליקות באמצעות הגדרת איזון העומסים. |
| חלונות זמן לתחזוקה | הרפליקות לקריאה חולקות את חלונות הזמן לתחזוקה עם המכונה הראשית. הרפליקות פועלות לפי הגדרות התחזוקה של המכונה הראשית, כולל חלון הזמן לתחזוקה, תזמון מחדש ופרק הזמן לדחיית עדכונים ותחזוקה. במהלך התחזוקה, Cloud SQL מעדכן קודם את כל הרפליקות לקריאה בלבד, ורק אחר כך את המכונה הראשית. |
| כמה עותקים לקריאה בלבד | ב-Cloud SQL יש תמיכה ברפליקות מדורגות. כתוצאה מכך, אפשר ליצור עד 10 רפליקות למכונה ראשית אחת, וליצור רפליקות של הרפליקות האלה, עד ארבע רמות כולל המכונה הראשית. |
| כתובת IP פרטית | אם אתם מתחברים לרפליקה באמצעות כתובת IP פרטית, אתם לא צריכים ליצור חיבור VPC פרטי נוסף לרפליקה, כי היא עוברת בירושה מהמכונה הראשית. |
| שחזור המכונה הראשית | אי אפשר לשחזר את המכונה הראשית של רפליקה כל עוד הרפליקה קיימת. לפני שמשחזרים מכונה מגיבוי או מבצעים בה שחזור מערכת מנקודה מסוימת בזמן (PITR), צריך לקדם או למחוק את כל הרפליקות שלה. |
| הגדרות | ההגדרות של המכונה הראשית מופצות לרפליקה, כולל הסיסמה של המשתמש ב-postgres והשינויים בטבלת המשתמשים. |
| הפסקת רפליקה | אי אפשר stop רפליקה. אפשר restart, delete או disable replication, אבל אי אפשר לעצור אותו כמו מכונה ראשית. |
| שדרוג רפליקה | עותקים לקריאה בלבד יכולים לעבור שדרוג משבש בכל שלב. |
| טבלאות משתמשים | אי אפשר לבצע שינויים ברפליקה. כל השינויים של המשתמשים צריכים להתבצע במופע הראשי. |