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

במאמר הזה מתוארים המושגים והמנגנונים לניהול אינדקסים משניים ברפליקות לקריאה בלבד של 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)

במהלך מעבר להתאוששות מאסון, כשמקַדמים את הרפליקה של ה-DR למכונה הראשית החדשה, Cloud SQL מסיר באופן אוטומטי את כל האינדקסים המשניים שנוצרו ברפליקה של ה-DR. ‫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 מסיר את האינדקס הקיים בניהול עצמי כחלק מהיצירה מחדש של המכונה, ויוצר באופן אוטומטי את האינדקס של העותק הזהה המנוהל מההגדרה הרשומה.

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