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