שכפול הוא היכולת ליצור עותקים של מכונת 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) באמצעות עותקים לקריאה בלבד
פעולות של אינדקס גיבוב לא משתמשות ב-write-ahead-logging ב-PostgreSQL 9.6. ב-Cloud SQL יש רק גרסה אחת שזמינה בPostgreSQL 10. המידע הזה מופיע בתיבת האזהרה הצהובה בדף הגרסה של PostgreSQL. הדבר נכון גם לגבי רפליקות לקריאה בלבד של Cloud SQL.
עדכונים של אינדקס גיבוב (hash) לא מופצים לעותק לקריאה בלבד ב-PostgreSQL 9.6, ולכן העותק לא יכול להשתמש בהם. כדי לעקוף את הבעיה, אתם יכולים להימנע משימוש ברפליקות לקריאה בלבד או לשדרג לגרסה ראשית של PostgreSQL (גרסה 10 ומעלה).
רפליקות לקריאה באזורים שונים
רפליקציה בין אזורים מאפשרת ליצור רפליקה לקריאה באזור שונה מהמופע הראשי. יוצרים רפליקה לקריאה באזור אחר באותו אופן שבו יוצרים רפליקה באותו אזור.
רפליקות בין אזורים:
- כדי לשפר את ביצועי הקריאה, כדאי להפוך רפליקות לזמינות קרוב יותר לאזור של האפליקציה.
- לספק יכולת נוספת של התאוששות מאסון כדי להגן מפני כשל אזורי.
- להעביר נתונים מאזור אחד לאחר.
מידע נוסף על רפליקות באזורים שונים זמין במאמר קידום רפליקות להעברה אזורית או להתאוששות מאסון.
שכפול קריאה מדורג
שכפול מדורג מאפשר ליצור רפליקה לקריאה מתחת לרפליקה אחרת לקריאה באותו אזור או באזור אחר. התרחישים הבאים הם תרחישי שימוש בהעתקים מדורגים:
- תוכנית התאוששות מאסון (DR): אתם יכולים להשתמש בהיררכיה מדורגת של רפליקות לקריאה בלבד כדי לדמות את הטופולוגיה של המכונה הראשית והרפליקות שלה לקריאה בלבד. במהלך הפסקה, העותק הזה מקודם לראשי, והעותקים האחרים ממשיכים לשכפל את הנתונים מהעותק הראשי החדש ומוכנים לשימוש.
- שיפורים בביצועים: הפחתת העומס על המופע הראשי על ידי העברת עבודת השכפול לכמה עותקים לקריאה בלבד.
- הרחבת פעולות הקריאה: אפשר להשתמש בעוד רפליקות כדי לחלק את עומס הקריאה.
- הפחתת עלויות: אתם יכולים להפחית את עלויות הרשת באמצעות רפליקה מדורגת אחת עם שכפול באזורים אחרים.
הסברים על המונחים
- רפליקה מדורגת: רפליקה לקריאה בלבד שיכולה להיות לה רפליקה משלה.
- רמות: אפשר ליצור רמות של רפליקות בהיררכיית רפליקות מדורגת. לדוגמה, אם מוסיפים ארבעה עותקים למקרה שימוש, ארבעת העותקים האלה נמצאים באותה רמה.
- מופעים מקבילים: כמה רפליקות שמשוכפלות מאותו מופע ראשי. אחים נמצאים באותה רמה בהיררכיית הרפליקה. לרפליקה יכולים להיות עד שמונה אחים.
- רפליקת עלה: רפליקה לקריאה בלבד שאין לה רפליקות משלה. בהיררכיית רפליקציה מרובת רמות, הרפליקה ברמת העלה היא הרמה האחרונה.
- קידום פעולה שממירה רפליקה, בכל רמה בהיררכיה, למכונה ראשית. כשמשדרגים, היררכיית הרפליקות המשורשרות של הרפליקה נשמרת.
הגדרת רפליקות מדורגות
שכפול מדורג מאפשר להוסיף עותקים לקריאה לכל עותק קיים. אפשר להוסיף עד ארבע רמות של רפליקות, כולל המופע הראשי. כשמקַדמים את הרפליקה בראש ההיררכיה של הרפליקות המשורשרות, היא הופכת למכונה ראשית והרפליקות המשורשרות שלה ממשיכות לשכפל.
כדי לתכנן את ההגדרות, צריך להגדיר מטרה לשימוש ברפליקות לקריאה בלבד. בשני החלקים הבאים מתוארות ההגדרות לתוכנית התאוששות מאסון ולרפליקה בכמה אזורים.
תוכנית התאוששות מאסון (DR)
כדי להבין איך עותקים משוכפלים מדורגים עוזרים לכם להתאושש במהירות במהלך הפסקת חשמל, הנה תרחיש שכפול לדוגמה:
הגדרות אישיות
הפסקה זמנית בשירות
קידום
אם רוצים להשתמש במופע באזור ב' בהגדרת התאוששות מאסון ויש:
- עותקים באותו אזור שמצורפים למופע הראשי (עותק א')
- רפליקות באזורים אחרים (רפליקה מדורגת) שמחוברות לרפליקה הראשית.
אפשר ליצור עותקים לקריאה בלבד מתחת לעותק המשורשר באזור ב'.
בכרטיסייה Outage (הפסקת פעולה), אם יש הפסקת פעולה באזור א', העותק המשוכפל המדורג מקודם למופע ראשי. כבר יש לו רפליקות לקריאה מתחתיו, מה שמקצר את היעד להתאוששות מאסון (RTO).
בכרטיסייה Promote, אפשר לראות שכאשר מקדמים רפליקה מדורגת, גם הרפליקות שלה מקודמות וממשיכות לשכפל תחתיה.
רפליקציה במספר אזורים
תרחיש שימוש נוסף לרפליקות מדורגות הוא הפצת קיבולת הקריאה לאזור שני באופן חסכוני. אפשר ליצור עותקים משוכפלים מדורגים 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
| נושא | קבוצת הדיון |
|---|---|
| גיבויים | אי אפשר להגדיר גיבויים בעותק המשוכפל. |
| ליבות וזיכרון | העותקים לקריאה יכולים להשתמש במספר ליבות שונה ובכמות זיכרון שונה מאלה של המופע הראשי. |
| מחיקת המכונה הראשית | כדי למחוק מכונה ראשית, צריך לקדם את כל הרפליקות לקריאה בלבד שלה למכונות עצמאיות או למחוק את הרפליקות לקריאה בלבד. |
| מחיקת הרפליקה | כשמוחקים רפליקה, אין השפעה על הסטטוס של המכונה הראשית. |
| השבתת רישום ביומן כתיבה מראש | כדי להשבית את יומני הכתיבה מראש במכונה ראשית, צריך לקדם או למחוק את כל הרפליקות לקריאה בלבד שלה. |
| יתירות כשל | מופע ראשי יכול לעבור למצב של יתירות כשל ברפליקה רק אם הרפליקה היא רפליקת DR. רפליקות לקריאה לא יכולות לבצע מעבר לגיבוי בכל דרך שהיא במהלך הפסקת שירות. |
| זמינות גבוהה | עותקים לקריאה בלבד מאפשרים להפעיל זמינות גבוהה בעותקים. |
| איזון עומסים | ב-Cloud SQL אין איזון עומסים בין העותקים המשוכפלים. אתם יכולים להטמיע איזון עומסים במכונה של Cloud SQL. אתם יכולים גם להשתמש באיגום חיבורים כדי לפזר את השאילתות בין העותקים המשוכפלים באמצעות הגדרת איזון העומסים, וכך לשפר את הביצועים. |
| חלונות זמן לתחזוקה | הרפליקות לקריאה חולקות את חלונות הזמן לתחזוקה עם המכונה הראשית. הרפליקות פועלות לפי הגדרות התחזוקה של המכונה הראשית, כולל חלון הזמן לתחזוקה, תזמון מחדש ופרק הזמן לדחיית עדכונים ותחזוקה. במהלך התחזוקה, מערכת Cloud SQL מעדכנת קודם את כל הרפליקות לקריאה לפני שהיא מעדכנת את המכונה הראשית. |
| עותקי קריאה מרובים | ב-Cloud SQL יש תמיכה ברפליקות מדורגות. כתוצאה מכך, אפשר ליצור עד 10 רפליקות למופע ראשי יחיד וליצור רפליקות של הרפליקות האלה, עד ארבע רמות כולל המופע הראשי. |
| כתובת IP פרטית | אם אתם מתחברים לרפליקה באמצעות כתובת IP פרטית, אתם לא צריכים ליצור חיבור פרטי נוסף ל-VPC בשביל הרפליקה, כי היא עוברת בירושה מהמכונה הראשית. |
| שחזור המכונה הראשית | אי אפשר לשחזר את המופע הראשי של רפליקה בזמן שהרפליקה קיימת. לפני שמשחזרים מכונה מגיבוי או מבצעים בה שחזור מערכת מנקודה מסוימת בזמן (PITR), צריך לקדם או למחוק את כל העותקים שלה. |
| הגדרות | ההגדרות של המכונה הראשית מועברות לרפליקה, כולל הסיסמה של המשתמש ב-Postgres והשינויים בטבלת המשתמשים. |
| הפסקת רפליקה | אי אפשר stop רפליקה. אפשר restart, delete או disable replication, אבל אי אפשר לעצור אותו כמו מכונה ראשית. |
| שדרוג רפליקה | עותקי קריאה בלבד יכולים לעבור שדרוג משבש בכל שלב. |
| טבלאות משתמשים | אי אפשר לבצע שינויים ברפליקה. כל השינויים של המשתמשים צריכים להתבצע במכונה הראשית. |
המאמרים הבאים
- איך יוצרים עותק לקריאה בלבד
- איך מגדירים מכונה לזמינות גבוהה
- מידע על תוכנית התאוששות מאסון (DR) מתקדמת