סקירה כללית של אינדקסים של עותקים לקריאה בלבד

במאמר הזה נסביר על המושגים והמנגנונים לניהול אינדקסים משניים ברפליקות לקריאה בלבד של Cloud SQL, גם ב-Cloud SQL Enterprise וגם ב-Cloud SQL Enterprise Plus. ב-MySQL, אפשר ליצור שני סוגים עיקריים של אינדקסים בטבלה:

  • אינדקס מקובץ: האינדקס הראשי בטבלת MySQL שמסדר פיזית את השורות בדיסק. כשמגדירים מפתח ראשי בטבלה, MySQL משתמש בו בתור האינדקס המקובץ. בטבלה יכול להיות רק אינדקס מקובץ אחד.

  • אינדקס משני: אינדקס נוסף בטבלת MySQL שמשפר את ביצועי השאילתות.

    בדרך כלל רפליקה היא לקריאה בלבד, אבל אפשר ליצור אינדקסים משניים בטבלאות למטרות דיווח. ב-Cloud SQL יש שתי שיטות ליצירת אינדקסים משניים של רפליקות:

    • אינדקסים מנוהלים של רפליקות (מומלץ): המערכת של Cloud SQL שומרת את הגדרות האינדקסים במכונה הראשית, ובונה מחדש את האינדקסים המשניים באופן אוטומטי אחרי קריסה של הרפליקה או יצירה מחדש שלה. כדי למנוע אובדן של אינדקסים ולהימנע משחזור ידני שלהם, Google ממליצה להשתמש באינדקסים מנוהלים ולא באינדקסים בניהול עצמי.
    • אינדקסים של רפליקות בניהול עצמי: מאפשרים להוסיף ולהסיר אינדקסים משניים ישירות ברפליקה, אבל האינדקסים האלה לא נשמרים אחרי שהרפליקה קורסת או נוצרת מחדש. אם אתם משתמשים באינדקסים בניהול עצמי, אתם יכולים לעבור לשימוש באינדקסים מנוהלים של רפליקות.

השוואה בין שיטות של אינדקס רפליקה

בטבלה הבאה מוצגת השוואה בין אינדקסים של רפליקות מנוהלות לבין אינדקסים של רפליקות בניהול עצמי ב-Cloud SQL:

תכונה אינדקסים מנוהלים של רפליקות אינדקסים של רפליקות בניהול עצמי
התמדה ביצירה מחדש של רפליקות נוצר מחדש באופן אוטומטי הוסר (נדרשת בנייה מחדש באופן ידני)
מודל ההגדרות האישיות מטא-נתונים מרוכזים במופע הראשי ‫DDL ישיר ברפליקה לקריאה בלבד של היעד
מנגנון הביצוע תהליך תקופתי ברקע
(בערך כל חמש דקות)		 הרצה מיידית
הגנה מפני השהיה ברפליקציה השהיה אוטומטית של יצירת האינדקס אם זמן האחזור של השכפול עולה על 20 דקות ללא (בניהול המשתמש)
מהדורות נתמכות ‫Cloud SQL מהדורת Enterprise ו-Cloud SQL מהדורת Enterprise Plus ‫Cloud SQL מהדורת Enterprise ו-Cloud SQL מהדורת Enterprise Plus
גרסאות נתמכות של מסדי נתונים ‫Cloud SQL ל-MySQL
(גרסת תחזוקה R20260726.00_05 ואילך)		 ‫Cloud SQL ל-MySQL
(כל הגרסאות הנתמכות)
תמיכה ברפליקה של שרת חיצוני לא נתמך נתמך

אינדקסים מנוהלים של רפליקות

כדי למנוע אובדן של אינדקסים אחרי יצירה מחדש של רפליקה, Cloud SQL תומך באינדקסים מנוהלים של רפליקות. ‫Google ממליצה על השיטה הזו ליצירת אינדקסים ולשמירה שלהם. ב-Cloud SQL השיטה הזו מופעלת כברירת מחדל.

כדי להשתמש באינדקסים של רפליקות מנוהלות, צריך גרסת תחזוקה של Cloud SQL מ-R20260726.00_05 ואילך.

בקטעים הבאים מוסבר איך Cloud SQL מתחזק אינדקסים של רפליקות, מה היתרונות שלהם ואיך הם פועלים במהלך אירועים במחזור החיים.

איך Cloud SQL מתחזק אינדקסים של רפליקות מנוהלות

בשיטה הזו, מגדירים אינדקסים משניים של רפליקות, מקבצים אותם ומציינים אילו רפליקות יכולות לתחזק את קבוצות האינדקסים האלה. ‫Cloud SQL מריץ תהליך ברקע ברפליקה כדי ליצור ולמחוק את האינדקסים הנדרשים באופן אוטומטי ולתחזק את האינדקסים לאורך זמן. כש-Cloud SQL יוצר אינדקס של רפליקה מנוהלת, הוא מוסיף את התג [SIC_X_Y] לתחילת ההערה של האינדקס, כאשר X ו-Y הם מספרים שלמים. התג הזה משמש רק לניהול פנימי ואין לו פונקציונליות.

‫Cloud SQL מבצע תחזוקה של אינדקסים מנוהלים של רפליקות, כמו יצירה והסרה של אינדקסים, באצוות. אחרי שתהליך התחזוקה של האינדקסים ב-Cloud SQL אוסף קבוצה של פעולות CREATE או DROP, הוא יוצר רשומת סטטוס PENDING לכל אינדקס משני. לאחר מכן, הוא מבצע באופן סדרתי כל הצהרה של שפת הגדרת נתונים (DDL). אם אינדקס אחד נכשל, זה לא מונע את ההפעלה של האינדקסים הבאים בתור. אחרי כחמש דקות, Cloud SQL יתחיל את הגיבוי של הקבוצה הבאה.

יתרונות ותרחישים לדוגמה

היתרונות של אינדקסים מנוהלים של רפליקות:

  • שמירה אוטומטית של אינדקסים: כש-Cloud SQL יוצר מחדש רפליקה לקריאה בלבד (למשל, אחרי קריסה של מכונה), הוא יוצר מחדש באופן אוטומטי את האינדקסים המשניים שממופים לרפליקה הזו. לא צריך להריץ פרוצדורות מאוחסנות באופן ידני או לתחזק סקריפטים חיצוניים למעקב אחרי סכימות כדי לשחזר אינדקסים חסרים.
  • ביצועים עקביים של שאילתות: על ידי בנייה מחדש באופן אוטומטי של אינדקסים משניים אחרי שחזור רפליקה, Cloud SQL שומר על קצב העברת הנתונים של השאילתות ומונע קפיצות בזמן האחזור של השאילתות וניצול גבוה של המעבד (CPU) שנגרם על ידי שאילתות ללא אינדקס.
  • הגדרה מבוססת-קבוצה: מגדירים אינדקסים משניים פעם אחת במכונה הראשית ומארגנים אותם בקבוצות רפליקות עם שמות. אחרי זה, אפשר להקצות קבוצת אינדקסים שמכילה מאות אינדקסים לרפליקה לקריאה בלבד, על ידי הגדרה של דגל יחיד לניהול מסד נתונים (cloudsql_index_recreate_replica_group). כך לא צריך להריץ פרוצדורות מאוחסנות נפרדות בכמה רפליקות.
  • הקצאת אינדקסים סלקטיבית לפי תפקיד הרפליקה: אתם יכולים להקצות קבוצות אינדקסים ספציפית לרפליקות לקריאה בלבד של דיווח וניתוח נתונים כדי להאיץ שאילתות קריאה, תוך שמירה על רפליקות לקריאה בלבד של התאוששות מאסון (DR) ללא אינדקסים וזהות לסכימה של המכונה הראשית. כך נמנעים תקורה של טרנזקציות כתיבה ועיכוב ברפליקציה במכונות DR.
  • בידוד הביצועים של המכונה הראשית: אינדקסים משניים ברפליקות לקריאה בלבד מאפשרים לבצע אופטימיזציה של שאילתות קריאה ודיווח בלי לצרוך נפח אחסון או להוסיף זמן אחזור של טרנזקציות כתיבה למכונה הראשית.
  • ניטור מובנה: פרוצדורות ייעודיות מאוחסנות מאפשרות לכם לעקוב אחרי התקדמות יצירת האינדקס, משך הביצוע ויומני השגיאות בעותק הזהה לקריאה בלבד.
  • העברה ודו-קיום ללא הפרעה: אינדקסים של רפליקות מנוהלות יכולים להתקיים בבטחה לצד אינדקסים קיימים של רפליקות בניהול עצמי באותו מופע ובאותה טבלה. אתם יכולים להוסיף אינדקסים של רפליקות מנוהלות באופן הדרגתי בלי זמן השבתה, ובלי להפריע לעומסי העבודה של שאילתות הקריאה הפעילות.

קידום רפליקה

‫Cloud SQL שומר אינדקסים של רפליקות מנוהלות רק במכונות של רפליקות לקריאה בלבד. אם מקדמים רפליקה לקריאה בלבד למכונה ראשית, Cloud SQL מסיר באופן אוטומטי את כל האינדקסים המשניים שנוצרו כאינדקסים של רפליקות מנוהלות. יכול להיות עיכוב של כחמש דקות לפני ש-Cloud SQL יבצע את ההסרה.

למרות ש-Cloud SQL מסיר את האינדקסים המשניים ואת הדגלים לניהול מסד הנתונים מהמכונה שקודמה, המכונה הראשית שומרת את ההגדרות של האינדקסים המשניים ואת המיפויים של הקבוצות.

מעבר לתוכנית התאוששות מאסון (DR)

במהלך מעבר להתאוששות מאסון, כשמשדרגים את הרפליקה להתאוששות מאסון למכונה הראשית החדשה, Cloud SQL מסיר באופן אוטומטי את כל האינדקסים המשניים שנוצרו ברפליקה להתאוששות מאסון. ‫Cloud SQL לא יוצר באופן אוטומטי את האינדקסים המשניים האלה במכונה הראשית הישנה כשהיא הופכת לרפליקה.

כדי ליצור אינדקסים משניים במכונה הראשית הישנה אחרי המעבר, מגדירים את הדגל לניהול מסד הנתונים cloudsql_index_recreate_replica_group במכונה הזו.

זמן השהיה ברפליקציה

‫Cloud SQL משהה את פעולות היצירה של אינדקסים משניים אם זמן האחזור של הרפליקציה עולה על 20 דקות. אם יצירת האינדקס של הרפליקה המנוהלת כבר מתבצעת כשהפיגור חורג מ-20 דקות, Cloud SQL מאפשר להשלים את הפעולה. השהיית הרפליקציה לא משהה את פעולות ההסרה של אינדקסים ברפליקות מנוהלות.

מגבלות

כשמשתמשים באינדקסים מנוהלים של רפליקות, חלות המגבלות הבאות:

  • אי אפשר ליצור אינדקסים של רפליקות מנוהלות ברפליקות של שרתים חיצוניים: ב-Cloud SQL אין תמיכה ביצירת אינדקסים של רפליקות מנוהלות ברפליקות של שרתים חיצוניים.
  • עד 1,000 אינדקסים לכל קבוצת רפליקות: אפשר להקצות עד 1,000 אינדקסים משניים לקבוצת רפליקות.
  • אין תמיכה בעדכון או בשינוי של מטא-נתונים של אינדקס: אי אפשר לעדכן או לשנות מטא-נתונים קיימים של אינדקס. כדי לשנות אינדקס, צריך למחוק את הגדרת האינדקס הקיימת וליצור הגדרה חדשה.

אינדקסים של רפליקות בניהול עצמי

אינדקסים של רפליקות בניהול עצמי הם אינדקסים משניים שאתם יוצרים ומבטלים ישירות ברפליקות נפרדות לקריאה בלבד ב-Cloud SQL. בדומה לאינדקסים של רפליקות מנוהלות, הם משפרים את הביצועים של שאילתות קריאה – למשל לעומסי עבודה של דיווח וניתוח נתונים – בלי לצרוך נפח אחסון או להשפיע על זמן האחזור של הכתיבה במכונה הראשית.

ניהול אינדקסים בניהול עצמי

אתם יכולים לנהל אינדקסים של רפליקות בניהול עצמי ישירות ברפליקה לקריאה בלבד, באמצעות הפרוצדורות המאוחסנות הבאות בסכימה mysql:

  • ‫mysql.addSecondaryIdxOnReplica: הוספת אינדקס משני בטבלה שצוינה ברפליקה לקריאה בלבד. התהליך המאוחסן הזה הוא wrapper להצהרת ה-DDL של CREATE INDEX.
  • ‫mysql.dropSecondaryIdxOnReplica: הסרת אינדקס משני שנוצר בעבר מהעותק הזהה לקריאה בלבד. התהליך המאוחסן הזה הוא wrapper להצהרת ה-DDL של DROP INDEX.

כדי להריץ את הפרוצדורות המאוחסנות האלה, צריך את התפקיד cloudsqlsuperuser.

כשיוצרים אינדקס בניהול עצמי, Cloud SQL מתעד מטא-נתונים בסיסיים בטבלה mysql.cloudsql_replica_index ברפליקה, כולל שם מסד הנתונים, שם הטבלה ושם האינדקס. בניגוד לאינדקסים של רפליקות מנוהלות, אינדקסים בניהול עצמי לא רשומים במכונה הראשית ולא מתוחזקים על ידי תהליך הרפליקה ברקע של Cloud SQL.

לפרטים על התחביר ודוגמאות לשימוש, קראו את המאמר אינדקסים של רפליקות בניהול עצמי.

יתרונות ותרחישים לדוגמה

אינדקסים של רפליקות בניהול עצמי מספקים את היתרונות הבאים לתהליכי עבודה ספציפיים:

  • בידוד הביצועים של המכונה הראשית: אינדקסים משניים ברפליקות לקריאה בלבד מאפשרים לבצע אופטימיזציה של שאילתות קריאה ודיווח בלי לצרוך נפח אחסון או להוסיף זמן אחזור של טרנזקציות כתיבה למכונה הראשית.
  • ביצוע מיידי: קריאות לפרוצדורות מאוחסנות מתבצעות באופן מיידי כהצהרות DDL ברפליקה, בלי לחכות למחזור התחזוקה התקופתי ברקע (בערך כל חמש דקות) שנדרש לאינדקסים של הרפליקה המנוהלת.
  • בדיקות וניסויים מבודדים: אתם יכולים לבדוק את ביצועי השאילתות ולאמת את האופטימיזציות של האינדקסים ברפליקה נפרדת לקריאה בלבד, לפני שאתם יוצרים אינדקסים של רפליקות מנוהלות בקבוצת רפליקות.

מגבלות

לאינדקסים של רפליקות בניהול עצמי יש מגבלות תפעוליות משמעותיות:

  • חוסר עקביות ביצירה מחדש של רפליקות: אם Cloud SQL יוצר מחדש רפליקה לקריאה בלבד (למשל במהלך שחזור מכונה, תחזוקה או כשל בחומרה), כל האינדקסים המשניים בניהול עצמי ברפליקה הזו נמחקים ולא משוחזרים באופן אוטומטי.
  • עומס עבודה של שחזור ידני: Cloud SQL לא יכול לשחזר ולבנות מחדש את האינדקסים. צריך ליצור מחדש את האינדקסים באופן ידני על ידי הפעלה חוזרת של mysql.addSecondaryIdxOnReplica.
  • פגיעה בביצועי השאילתות: יכול להיות ששאילתות קריאה יחוו פגיעה בביצועים אחרי יצירה מחדש של רפליקה, עד שתבנו מחדש באופן ידני את האינדקסים החסרים.

מכיוון שאינדקסים של רפליקות מנוהלות נשמרים ונבנים מחדש באופן אוטומטי באירועים של יצירה מחדש של רפליקות, Google ממליצה להשתמש באינדקסים של רפליקות מנוהלות לעומסי עבודה בסביבת הייצור. אם יש לכם אינדקסים קיימים בניהול עצמי, העבירו אותם לאינדקסים מנוהלים של רפליקות.

דו-קיום של סוגי אינדקסים של רפליקות

אינדקסים של רפליקות בניהול עצמי (שנוצרו באמצעות mysql.addSecondaryIdxOnReplica) ואינדקסים של רפליקות מנוהלות יכולים להתקיים במקביל באותו מופע של רפליקה לקריאה בלבד ב-Cloud SQL ובאותה טבלה. כך אתם יכולים להשתמש באינדקסים של רפליקות מנוהלות באופן הדרגתי, בלי להפריע לעומסי העבודה הקיימים במסד הנתונים.

כשמשתמשים בשתי השיטות לניהול אינדקסים, חשוב לשים לב להתנהגויות הבאות:

  • פעולה עצמאית: אינדקסים בניהול עצמי שאתם יוצרים ישירות ברפליקה לקריאה בלבד ממשיכים לפעול לצד אינדקסים מנוהלים של רפליקות.
  • הערכה תקופתית: תהליך התחזוקה ברקע של Cloud SQL מעריך מדי פעם (בערך כל חמש דקות) את הגדרות האינדקס שממופות לקבוצת הרפליקות שהקציתם לרפליקה.
  • טיפול בהתנגשויות בשמות: אם רושמים הגדרה של אינדקס מנוהל של רפליקה עם שם זהה לזה של אינדקס קיים בניהול עצמי ברפליקה לקריאה בלבד, התהליך ברקע מזהה שכבר קיים אינדקס עם השם הזה. התהליך מתעד סטטוס FAILED בטבלה mysql.cloudsql_replica_idx_status. השגיאה הזו לא משפיעה על תעבורת הנתונים במסד הנתונים, לא יוצרת נעילות של טבלאות ולא משפיעה על האינדקס הקיים בניהול עצמי.
  • פתרון אוטומטי אחרי יצירה מחדש: כשיוצרים מחדש את העותק הזהה לקריאה בלבד, Cloud SQL מוחק את האינדקס הקיים בניהול עצמי כחלק מהיצירה מחדש של המכונה, ויוצר באופן אוטומטי את האינדקס המנוהל של העותק הזהה מההגדרה הרשומה.

המאמרים הבאים