בדף הזה מפורטות שיטות מומלצות כלליות שיעזרו לכם לשפר את הביצועים, העמידות והזמינות של AlloyDB ל-PostgreSQL. הדף הזה מיועד לאדמינים של מסדי נתונים ולמפתחים שכבר מכירים את AlloyDB ואת PostgreSQL.
הגדרה וניהול של מופע
שימוש בכלים של AlloyDB כדי לעקוב אחרי השימוש במסד הנתונים והסטטוס שלו.
פועלים לפי ההנחיות התפעוליות.
הגדרת חלון זמן לתחזוקה למופע הראשי.
הוספת מופעים של מאגר לקריאה כדי להפחית עומס של תנועת קריאה
ניהול השהיית הרפליקציה.
אל תתחילו פעולה ניהולית לפני שהפעולה הקודמת מסתיימת.
הגדרת מכסת אחסון מספיקה כדי לאפשר תחזוקה של מסד נתונים קריטי.
מונעים שימוש יתר במעבד.
הימנעות מניצול יתר של הזיכרון.
מוודאים שלמופע יש מזהי עסקאות אופטימליים.
שימוש בכלים של AlloyDB כדי לעקוב אחרי השימוש במסד הנתונים והסטטוס שלו
בטבלה הבאה מפורטים כלי AlloyDB שיעזרו לכם לעקוב אחרי השימוש במסד הנתונים, הסטטוס והביצועים.
| כלי AlloyDB | תיאור |
|---|---|
| דוח תמונת מצב של הביצועים | משווה בין תמונות מצב של מדדי המערכת בשתי נקודות זמן שונות. |
| תובנות לגבי שאילתות | עוזר לכם לזהות, לאבחן ולמנוע בעיות בביצועי שאילתות במסדי נתונים של AlloyDB. הוא מספק שירות עצמי, ניטור אינטואיטיבי ומידע אבחוני שחורג מזיהוי בעיות, כדי לעזור לכם לזהות את שורש הבעיה בביצועים. |
| תובנות לגבי המערכת | מאפשר לעקוב אחרי משאבים ומדדים של מסד נתונים, כולל מספר הצמתים הפעילים, השימוש במעבד, מספר החיבורים המקסימלי, שגיאות ביומן, מספר הטרנזקציות בשנייה וזמן השהייה המקסימלי בשכפול. |
פועלים לפי הנחיות ההפעלה
כדי לוודא שהמכונות שלכם מכוסות על ידי הסכם רמת השירות (SLA) של AlloyDB ל-PostgreSQL, צריך לפעול בהתאם להנחיות התפעוליות.
הגדרת חלון זמן לתחזוקה למופע הראשי
כדי לתכנן מתי יתבצעו עדכונים שעלולים לשבש את הפעילות, צריך להגדיר חלון זמן לתחזוקה עבור המופע הראשי. מידע נוסף מופיע במאמר בנושא הצגה והגדרה של זמני תחזוקה.
הוספת מופעים של מאגר קריאה כדי להפחית עומס של תנועת קריאה
עבור עומסי עבודה עם הרבה קריאות, מוסיפים מופעים של מאגר קריאה כדי להפחית את העומס על המכונה הראשית שנוצר מתנועת הקריאה.
כדי לשפר את השמירה במטמון, צריך להגדיר מאגר קריאה אחד או יותר לכל מסד נתונים במופע.
כדאי להוסיף עוד צמתים לכל מאגר כדי לאפשר איזון עומסים אוטומטי וזמינות גבוהה.
ניהול השהיית רפליקציה
ב-AlloyDB בוצעו כמה שיפורים כדי לצמצם את השהיית השכפול. עם זאת, יכול להיות שתיתקלו בתרחישים שבהם הפעלת יומן האירועים חסומה או לא יכולה לעמוד בקצב, מה שעלול לגרום לעיכוב מוגבר בשכפול.
מידע מפורט על מעקב אחרי השהיית רפליקציה ופתרון בעיות שקשורות להשהיה זמין במאמר פתרון בעיות שקשורות לרפליקציה.
אל תתחילו פעולה ניהולית לפני שהפעולה הקודמת תסתיים
אי אפשר לשלוח בקשות חדשות לפעולות במופעי AlloyDB עד שהפעולה הקודמת תושלם. אם תנסו להתחיל פעולה חדשה לפני שהפעולה הקודמת תושלם, בקשת הפעולה תיכשל. הפעולה הזו כוללת הפעלה מחדש של מכונות.
הסטטוס של המופע במסוף Google Cloud לא משקף אם פעולה כלשהי פועלת. סימן הווי הירוק מציין רק אם המופע נמצא במצב RUNNABLE. כדי לראות אם פעולה פועלת, לוחצים על Operations (פעולות) בחלונית הניווט הימנית ובודקים את הסטטוס של הפעולה האחרונה.
הגדרת מכסת אחסון מספיקה כדי לאפשר תחזוקה קריטית של מסד הנתונים
כברירת מחדל, אפשר להשתמש בנפח אחסון של עד 16TB לכל אשכול. אם אתם צריכים נפח אחסון נוסף, כדאי להגדיל את מכסת האחסון.
מניעת ניצול יתר של המעבד (CPU)
בדף פרטי האינסטנס במסוף Google Cloud אפשר לראות את אחוז ה-CPU הזמין שבו נעשה שימוש באינסטנס. מידע נוסף זמין במאמר בנושא מעקב אחרי מופעים. אפשר גם לעקוב אחרי השימוש במעבד ולקבל התראות כשמגיעים לערך סף שצוין באמצעות יצירת מדיניות התראות מבוססת-מדדים.
כדי למנוע שימוש יתר, אפשר לשנות את גודל המכונה כך שתכלול מספר גבוה יותר של מעבדים. כדי לשנות את מספר ליבות ה-CPU, צריך להפעיל מחדש את המופע. אם המופע כבר הגיע למספר המקסימלי של מעבדי CPU, מומלץ לפצל את מסד הנתונים למספר מופעים.
איך נמנעים ממצב שבו הזיכרון נגמר
ב-AlloyDB יש ניהול זיכרון אוטומטי כדי למנוע בעיות שקשורות לחוסר זיכרון. עם זאת, עומס זיכרון קבוע עלול לגרום לבעיות בביצועים. כשמחפשים סימנים של ניצול מלא של הזיכרון, כדאי להשתמש בעיקר במדד הזיכרון הזמין. כדי ליהנות מביצועים אופטימליים, מומלץ לשמור על ערך של יותר מ-10% במדד הזה.
החל מ-PostgreSQL 17, מדד הזיכרון הזמין מתחשב בצורה מדויקת יותר בזיכרון מטמון של דפים במערכת ההפעלה שלא ניתן לשחרר. משתמשים שמשדרגים ל-PostgreSQL 17 עשויים להבחין בירידה בזיכרון הזמין שדווח כתוצאה מהשיפור בחישוב.
אם במופע שלכם מופיע עומס על הזיכרון, כדאי להגדיל את המופע או להפעיל ניהול מאגר חיבורים. AlloyDB תומך בזיכרון RAM של עד 2,304GB באמצעות סדרת המכונות C4. עבור עומסי עבודה עם הרבה חיבורים בלי פעילות או חיבורים קצרים, ניהול מאגר חיבורים יכול לצמצם באופן משמעותי את הזיכרון שבשימוש שנדרש לתקורה של החיבורים.
מידע נוסף על מעקב אחרי מדדי זיכרון במסוף Google Cloud זמין במאמר מעקב אחרי מופעים.
מוודאים שלמופע יש מזהי עסקאות אופטימליים
כדי לראות את השימוש במזהי העסקאות במופע שלכם, צריך להגדיר את Resource Type ל-AlloyDB for PostgreSQL Database ואת Metric ל-Percentage of instance's transaction IDs consumed בדף Metrics Explorer במסוף Google Cloud . מידע נוסף זמין במאמר יצירת תרשימים באמצעות Metrics Explorer.
ב-AlloyDB יש תכונה מובנית של autovacuum דינמי, שעוזרת לצמצם בעיות שקשורות ל-vacuum.
ארכיטקטורת נתונים
אם אפשר, כדאי לפצל את המכונות הגדולות למכונות קטנות יותר.
לא מומלץ להשתמש ביותר מדי טבלאות במסד הנתונים.
אם אפשר, כדאי לפצל את המקרים הגדולים למקרים קטנים יותר
אם אפשר, כדאי להשתמש בהרבה אשכולות קטנים של AlloyDB במקום במופע גדול אחד. ניהול מופע גדול ומונוליטי מציב אתגרים שלא קיימים כשמנהלים קבוצה של מופעים קטנים יותר.
אל תשתמשו ביותר מדי טבלאות במסד הנתונים
מספר הטבלאות במופע צריך להיות קטן מ-10,000. יותר מדי טבלאות במסד הנתונים יכולות להשפיע על משך השדרוג של מסד הנתונים.
ביצועי השאילתה
אם אתם מריצים שאילתות אנליטיות, מומלץ להפעיל את Columnar Engine.
הגדלת קיבולת המופע כדי לשפר את ביצועי השאילתות.
פריסת מאגרי קריאה והפחתת עומס של שאילתות קריאה למאגר הקריאה.
הפעלת מנוע עמודות אם מריצים שאילתות אנליטיות
קראו סקירה כללית על מנוע מבוסס-עמודות ב-AlloyDB. בודקים את סוגי השאילתות שיכולות להפיק תועלת מהפעלת מנוע העמודות.
אתם יכולים לעקוב אחרי השימוש במנוע העמודות.
אם אתם חדשים במנוע מבוסס-עמודות, כדאי להתחיל בקריאת המאמר בנושא הפיכה אוטומטית של נתונים לעמודות. אחר כך תוכלו לבחור לנהל את העמודות באופן ידני.
הגדלת המופע כדי לשפר את ביצועי השאילתות
אם אתם נתקלים בביצועים נמוכים של שאילתות, כדאי לשקול להגדיל את המכונה.
לכל מק"ט יש הגדרות מוגבלות של vCPU וזיכרון, ולכל מק"ט יש גם מטמון מהיר מוגבל. אם גודל הנתונים גדול ואתם נתקלים בביצועים נמוכים של שאילתות, כדאי לשקול להגדיל את המופע.
פריסת מאגרי קריאה והעברת שאילתות קריאה למאגר הקריאה
אם האפליקציה מבצעת פעולות כתיבה וקריאה רבות, כדאי לפרוס מאגרי קריאה ולהעביר שאילתות קריאה למאגר הקריאה.
עבור עומסי עבודה עם הרבה קריאות, מוסיפים מופעים של מאגר קריאה כדי להפחית את העומס על המכונה הראשית שנוצר מתנועת הקריאה.
הטמעת האפליקציה
משתמשים בטכניקות טובות לניהול חיבורים.
בדיקת התגובה של האפליקציה לעדכוני תחזוקה.
בודקים את התגובה של האפליקציה למעבר לגיבוי בעת כשל.
הימנעות מעסקאות גדולות.
הימנעות ממספר גדול של עסקאות משנה.
להשתמש בגרסה העדכנית ביותר של Auth Proxy.
שימוש בשיטות מומלצות לניהול חיבורים
להשתמש בשיטות מומלצות לניהול חיבורים, כמו איגום חיבורים והשהיה מעריכית לפני ניסיון חוזר (exponential backoff).
שימוש בטכניקות טובות לניהול חיבורים משפר את השימוש במשאבים באפליקציה ועוזר לכם להישאר במסגרת מגבלות החיבור של AlloyDB.
בדיקת התגובה של האפליקציה לעדכוני תחזוקה
בודקים את התגובה של האפליקציה לעדכוני תחזוקה, שיכולים לקרות בכל שלב במהלך חלון הזמן לתחזוקה.
אתם יכולים לדמות עדכון תחזוקה על ידי ביצוע פעולות של שינוי קנה מידה של מחשוב או עדכון של דגלים סטטיים של PostgreSQL, שמפעילים תחזוקה עם זמן השבתה קצר (LDTM).
במהלך LDTM, המופע שלכם לא יהיה זמין לפרק זמן קצר, והחיבורים הקיימים ינותקו. בדיקת LDTM מאפשרת להבין טוב יותר איך האפליקציה מטפלת בתחזוקה מתוזמנת ומה מהירות השחזור של המערכת.
בדיקת התגובה של האפליקציה למעבר לגיבוי בעקבות כשל
חשוב לבדוק את התגובה של האפליקציה למעבר לגיבוי, שיכול לקרות בכל שלב.
אפשר להפעיל מעבר לגיבוי ידני באמצעות מסוף Google Cloud , Google Cloud CLI או ה-API. מידע נוסף זמין במאמר בנושא התחלת מעבר לגיבוי בעת כשל.
הימנעות מעסקאות גדולות
העסקאות צריכות להיות קטנות וקצרות. אם נדרש עדכון גדול של מסד נתונים, עדיף לבצע את העדכון בכמה עסקאות קטנות יותר במקום לבצע עסקה גדולה אחת.
הימנעות ממספר גדול של עסקאות משנה
אם יש טרנזקציות שפועלות לאורך זמן, כדאי להימנע ממספר גדול של טרנזקציות משנה בטרנזקציה.
ב-AlloyDB, ביצוע טרנזקציה בבלוק שגיאות של PL/pgSQL יוצר טרנזקציות משנה של הטרנזקציה שמתאימה לבלוק השגיאות. הביצועים הכוללים של המערכת יורדים אם מספר עסקאות המשנה עולה על 64 בנוכחות עסקאות שפועלות לאורך זמן.
שימוש בגרסה העדכנית ביותר של Auth Proxy
אם אתם משתמשים ב-AlloyDB Auth Proxy, חשוב לוודא שאתם משתמשים בגרסה העדכנית ביותר. מידע נוסף זמין במאמר בנושא שמירה על עדכניות של לקוח Auth Proxy.
ייבוא וייצוא של נתונים
שחזור מגיבויים של Cloud SQL ל-PostgreSQL לצורך העברה
כדי להקל על ההעברה, אפשר לעיין במאמר העברה מ-Cloud SQL ל-PostgreSQL אל AlloyDB.
כדי ללמוד איך להעביר את הנתונים מ-Cloud SQL ל-PostgreSQL אל AlloyDB באמצעות שכפול נתונים רציף, אפשר לעיין במאמר Database Migration Service for PostgreSQL to AlloyDB.
האצת הייבוא במופעים קטנים
כשמייבאים מערכי נתונים גדולים למופעים קטנים, אפשר באופן זמני להגדיל את המעבד (CPU) ואת ה-RAM של המופע כדי לשפר את הביצועים.
גיבוי ושחזור
הגנה על הנתונים באמצעות היכולות המתאימות של AlloyDB.
הגנה על המופע ועל הגיבויים מפני מחיקה בטעות.
הגנה על הנתונים באמצעות היכולות המתאימות של AlloyDB
כדי להבטיח יתירות והגנה, כדאי להשתמש בגיבויים, בשחזור לנקודת זמן (PITR) ובייצוא. כל אחד מהם מגן מפני תרחישים שונים, והם משלימים זה את זה באסטרטגיה חזקה להגנה על נתונים.
הגיבויים קלים, והם מאפשרים לשחזר את הנתונים במופע למצב שבו הם היו בזמן הגיבוי. עם זאת, יש כמה מגבלות על תכונת הגיבוי של AlloyDB. אם מוחקים את המכונה, גם הגיבויים נמחקים. אי אפשר לגבות מסד נתונים או טבלה בודדים. אם האזור שבו נמצא המופע לא זמין, לא תוכלו לשחזר את המופע מהגיבוי הזה, גם אם יש אזור זמין.
שחזור מערכת מנקודה מסוימת בזמן מאפשר לכם לשחזר מופע לנקודה מסוימת בזמן. לדוגמה, אם שגיאה גורמת לאובדן נתונים, אפשר לשחזר מסד נתונים למצב שבו הוא היה לפני שהשגיאה התרחשה. שחזור מערכת מנקודה מסוימת בזמן (PITR) תמיד יוצר מופע חדש. אי אפשר לבצע שחזור מערכת מנקודה מסוימת בזמן (PITR) במופע קיים.
תהליך הייצוא אורך זמן רב יותר, כי נוצר קובץ חיצוני ב-Cloud Storage שאפשר להשתמש בו כדי ליצור מחדש את הנתונים. אם מוחקים את המופע, הייצוא לא מושפע. בנוסף, אפשר לייצא רק מסד נתונים או טבלה אחת, בהתאם לפורמט הייצוא.
הגנה על המופע ועל הגיבויים מפני מחיקה בטעות
כדי להפעיל את מניעת המחיקה בשוגג כברירת מחדל, יוצרים מכונת AlloyDB באמצעות מסוף Google Cloud או Terraform.
כדי להגן על הנתונים, אפשר להשתמש בתכונת הייצוא ב-AlloyDB. אפשר להשתמש ב-Cloud Scheduler עם Cloud Scheduler API כדי להפוך את ניהול הייצוא לאוטומטי.
לתרחישים מתקדמים יותר, אפשר להשתמש ב-Cloud Scheduler עם פונקציות Cloud Run לאוטומציה.