שכפול הוא היכולת ליצור עותקים של מכונת Cloud SQL או של מסד נתונים מקומי, ולהעביר עבודה לעותקים.
מבוא
הסיבה העיקרית לשימוש בשכפול היא להרחיב את השימוש בנתונים במסד נתונים בלי לפגוע בביצועים.
דוגמאות לסיבות אחרות:
- העברת נתונים בין אזורים
- העברת נתונים בין פלטפורמות
- העברת נתונים ממסד נתונים מקומי ל-Cloud SQL
בנוסף, אפשר לקדם רפליקה אם המופע המקורי נפגם.
כשמתייחסים למכונה של Cloud SQL, המכונה שמשוכפלת נקראת מכונה ראשית, והעותקים נקראים רפליקות לקריאה. המופע הראשי והרפליקות לקריאה נמצאים ב-Cloud SQL.
כשמדובר במסד נתונים מקומי, תרחיש השכפול נקרא שכפול משרת חיצוני. בתרחיש הזה, מסד הנתונים שמשוכפל הוא שרת מסד הנתונים של המקור. העותקים ששוכנים ב-Cloud SQL נקראים רפליקות של Cloud SQL. יש גם מופע שמייצג את שרת מסד הנתונים של המקור ב-Cloud SQL, שנקרא מופע ייצוג המקור.
בתרחיש של תוכנית התאוששות מאסון (DR), אפשר לקדם רפליקה כדי להמיר אותה למופע ראשי. כך תוכלו להשתמש בו במקום מכונה שנמצאת באזור שבו יש הפסקת חשמל. אפשר גם לקדם רפליקה כדי להחליף מופע פגום.
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 עבור הרפליקה, כי החיבור עובר בירושה מהמכונה הראשית.
מידע על יצירת עותק לקריאה זמין במאמר יצירת עותקים לקריאה. מידע על ניהול רפליקה לקריאה מופיע במאמר בנושא ניהול רפליקות לקריאה.
מומלץ להציב רפליקות לקריאה באזור אחר מהאזור של המופע הראשי כשמשתמשים בזמינות גבוהה במופע הראשי. השיטה הזו מבטיחה שעותקי הקריאה ימשיכו לפעול אם יש הפסקת חשמל באזור שמכיל את המופע הראשי. מידע נוסף זמין במאמר סקירה כללית של זמינות גבוהה.
בחירת סוג מכונה מתאים
לעותקי קריאה יכולים להיות מספר שונה של מעבדי CPU וירטואליים וזיכרון בהשוואה לשרת הראשי. כדאי לעקוב אחרי מדדים במכונה, כמו השימוש במעבד ובזיכרון, כדי לוודא שהגודל של מכונת הרפליקה מתאים לעומס העבודה שלה, במיוחד אם היא קטנה יותר מהמכונה הראשית. אם גודל המופע המשוכפל קטן מדי, הוא יהיה מועד יותר לביצועים נמוכים, כמו אירועים תכופים של חוסר זיכרון (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) כדי להגן מפני כשל אזורי.
- מאפשרת להעביר נתונים מאזור אחד לאזור אחר.
מידע נוסף על רפליקות באזורים שונים זמין במאמר קידום רפליקות להעברה אזורית או להתאוששות מאסון.
שכפול קריאה מדורג
שכפול מדורג מאפשר ליצור רפליקה לקריאה מתחת לרפליקה אחרת לקריאה באותו אזור או באזור אחר. התרחישים הבאים הם תרחישי שימוש בהעתקים מדורגים:
- תוכנית התאוששות מאסון (DR): אפשר להשתמש בהיררכיה מדורגת של רפליקות לקריאה כדי לדמות את הטופולוגיה של המופע הראשי והרפליקות לקריאה שלו. במהלך הפסקת שירות, העותק לקריאה שנבחר מקודם לראשי, והעותקים לקריאה שמתחת לראשי החדש ממשיכים לשכפל ומוכנים לשימוש.
- שיפורים בביצועים: הפחתת העומס על המופע הראשי על ידי העברת עבודת השכפול לכמה רפליקות לקריאה.
- הגדלת מספר הקריאות: אפשר להגדיל את מספר העותקים כדי לחלק את עומס הקריאה.
- הפחתת עלויות: אתם יכולים להפחית את עלויות הרשת על ידי שימוש בעותק יחיד של שכפול מדורג עם שכפול באזורים שונים באזורים אחרים.
הסברים על המונחים
- שכפול מדורג: עותק לקריאה שיכול להיות לו עותק משלו.
- רמות: אפשר ליצור רמות של רפליקות בהיררכיית רפליקות מדורגת. לדוגמה, אם מוסיפים ארבעה עותקים למקרה שימוש, ארבעת העותקים האלה נמצאים באותה רמה.
- מופעים מקבילים: כמה עותקים משוכפלים שמשוכפלים מאותו מופע ראשי. פריטים באותה רמה בהיררכיית הרפליקה. לעותק יכולים להיות עד שמונה עותקים רשמיים.
- רפליקה מסוג leaf: רפליקה לקריאה שאין לה רפליקות משלה. בהיררכיית שכפול מרובת רמות, העותק המשוכפל ברמת העלה הוא הרמה האחרונה.
- קידום פעולה שממירה עותק, בכל רמה בהיררכיה, למופע ראשי. כשמקודמים את העותק, היררכיית העותקים המשוכפלים שלו נשמרת.
הגדרת עותקים משוכפלים מדורגים
שכפול מדורג מאפשר להוסיף עותקים לקריאה לכל עותק קיים. אפשר להוסיף עד ארבע רמות של רפליקות, כולל המופע הראשי. כשמקדמים את הרפליקה בחלק העליון של היררכיית רפליקות מדורגת, היא הופכת למופע ראשי והרפליקות המדורגות שלה ממשיכות לשכפל.
כדי לתכנן את ההגדרה, צריך להגדיר יעד למה שמשכפלי הקריאה אמורים לעשות. בשני הסעיפים הבאים מתוארות ההגדרות לשחזור לאחר אסון ולשכפול מרובה אזורים.
תוכנית התאוששות מאסון (DR)
כדי להבין איך עותקים משוכפלים מדורגים עוזרים לכם להתאושש במהירות במהלך הפסקת חשמל, הנה תרחיש שכפול לדוגמה:
הגדרות אישיות
הפסקה זמנית בשירות
קידום
אם רוצים להשתמש במופע באזור ב' בהגדרת התאוששות מאסון ויש:
- עותקים זהים באותו אזור שמצורפים למכונה הראשית (עותק זהה א')
- עותקים באזורים אחרים (עותק משוכפל מדורג) שמצורפים לעותק הראשי.
אפשר ליצור עותקים לקריאה מתחת לעותק המשוכפל המדורג באזור ב'.
בכרטיסייה Outage (הפסקת פעולה), אם יש הפסקת פעולה באזור א', העותק המשוכפל המדורג מקודם למופע ראשי. כבר יש לו רפליקות לקריאה מתחתיו, מה שמקצר את היעד להתאוששות מאסון (RTO).
בכרטיסייה קידום אפשר לראות שכאשר מקדמים עותק משוכפל מדורג, גם העותקים המשוכפלים שלו מקודמים וממשיכים לשכפל מתחתיו.
רפליקציה במספר אזורים
תרחיש לדוגמה נוסף לשימוש בעותקים משוכפלים מדורגים הוא חלוקת יכולת קריאה לאזור שני בצורה חסכונית. אפשר ליצור עותקים משוכפלים מדורגים C ו-D שמשוכפלים מעותק משוכפל B. לקוחות יכולים להפיץ שאילתות קריאה בין העותקים המשוכפלים B, C ו-D כדי להפחית את העומס על כל עותק משוכפל. העלות של תנועה ברשת בין אזורים נצברת רק פעם אחת, מהמכונה הראשית אל הרפליקה 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
| נושא | קבוצת הדיון |
|---|---|
| גיבויים | אי אפשר להגדיר גיבויים בעותק המשוכפל. |
| ליבות וזיכרון | העותקים לקריאה יכולים להשתמש במספר ליבות שונה ובכמות זיכרון שונה מאלה של המופע הראשי. |
| מחיקת המכונה הראשית | כדי למחוק מופע ראשי, צריך להפוך את כל העותקים לקריאה בלבד למופעים עצמאיים או למחוק אותם. |
| מחיקת העותק | כשמוחקים עותק, אין לכך השפעה על הסטטוס של המופע הראשי. |
| השבתת רישום ביומן לפני כתיבה | כדי להשבית את היומנים של כתיבה מראש במופע ראשי, צריך לקדם או למחוק את כל העותקים לקריאה שלו. |
| מעבר לגיבוי (Failover) | מופע ראשי יכול לבצע מעבר לגיבוי כשל למופע משוכפל רק אם המופע המשוכפל הוא מופע משוכפל של DR. במהלך הפסקת שירות, העתקים לקריאה לא יכולים לבצע מעבר לגיבוי בשום צורה. |
| זמינות גבוהה | העתקים לקריאה מאפשרים להפעיל זמינות גבוהה בהעתקים. |
| איזון עומסים | ב-Cloud SQL אין איזון עומסים בין העותקים המשוכפלים. אתם יכולים לבחור להטמיע איזון עומסים במופע Cloud SQL. אתם יכולים גם להשתמש באיגום חיבורים כדי להפיץ שאילתות בין העותקים עם הגדרת איזון העומסים, וכך לשפר את הביצועים. |
| חלונות זמן לתחזוקה | הרפליקות לקריאה חולקות את חלונות הזמן לתחזוקה עם המכונה הראשית. הרפליקות פועלות לפי הגדרות התחזוקה של המכונה הראשית, כולל חלון הזמן לתחזוקה, שינוי מועד התחזוקה ותקופת התחזוקה האסורה. במהלך התחזוקה, מערכת Cloud SQL מעדכנת קודם את כל הרפליקות לקריאה לפני שהיא מעדכנת את המכונה הראשית. |
| עותקים לקריאה מרובים | Cloud SQL תומך בשכפול מדורג. כתוצאה מכך, אפשר ליצור עד 10 רפליקות למופע ראשי יחיד, וליצור רפליקות של הרפליקות האלה, עד ארבע רמות כולל המופע הראשי. |
| כתובת IP פרטית | אם אתם מתחברים לרפליקה באמצעות כתובת IP פרטית, אתם לא צריכים ליצור חיבור VPC פרטי נוסף לרפליקה, כי היא מקבלת אותו בירושה מהמופע הראשי. |
| שחזור המכונה הראשית | אי אפשר לשחזר את המופע הראשי של העותק המשוכפל כל עוד העותק המשוכפל קיים. לפני שמשחזרים מופע מגיבוי או מבצעים בו שחזור מערכת מנקודה מסוימת בזמן (PITR), צריך לקדם או למחוק את כל העותקים שלו. |
| הגדרות | ההגדרות של המופע הראשי מועברות למופע המשוכפל, כולל הסיסמה של משתמש postgres ושינויים בטבלת המשתמשים. |
| הפסקת העבודה של העותק | אי אפשר stop עותק משוכפל. אפשר restart, delete או disable replication, אבל אי אפשר לעצור אותו כמו מופע ראשי. |
| שדרוג רפליקה | שדרוג משבש יכול להתרחש בכל שלב בעותקי קריאה. |
| טבלאות משתמשים | אי אפשר לבצע שינויים בעותק המשוכפל. כל השינויים שקשורים למשתמשים צריכים להתבצע במופע הראשי. |