שיטות מומלצות

בדף הזה מפורטות שיטות מומלצות להשגת הביצועים, העמידות והזמינות הכי טובים ב-Cloud SQL.

אם מתרחשות בעיות במכונה של Cloud SQL, כדאי לבדוק את הדברים הבאים במהלך פתרון הבעיות:

הגדרה וניהול של מופע

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

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

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

הגדרת אחסון כדי לאפשר תחזוקה קריטית של מסד הנתונים.

אם הגדרת המכונה enable automatic storage increases מושבתת או שההגדרה automatic storage increase limit מופעלת, צריך לוודא שיש לפחות 20% מקום פנוי כדי לאפשר פעולות תחזוקה קריטיות של מסד הנתונים ש-Cloud SQL עשוי לבצע.

כדי לקבל התראה אם המקום הפנוי בדיסק יורד מתחת ל-20%, צריך ליצור מדיניות התראות שמבוססת על מדדים עבור המדד disk utilization עם מיקום above threshold וערך של .8. מידע נוסף זמין במאמר בנושא יצירת מדיניות התראות מבוססת-מדדים.
למנוע ניצול יתר של המעבד (CPU).

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

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

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

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

ההבדל בין שני המדדים האלה מאפשר לכם לזהות כמה זיכרון משמש לתהליכים וכמה זיכרון משמש למטמון של מערכת ההפעלה. אפשר להשתמש מחדש בזיכרון במטמון הזה.

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

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

אבטחה

שיטה מומלצת מידע נוסף
העדפה של כתובת IP פרטית אלא אם נדרשת גישה באמצעות כתובת IP ציבורית, מומלץ להשתמש בכתובת IP פרטית. כך תוכלו לצמצם את הסיכוי לחיבורים לא מורשים לרשת למסד הנתונים.
איך להימנע משימוש ב-0.0.0.0/0 ברשתות מורשות לא מומלץ לכלול את 0.0.0.0/0 ברשתות מורשות, כי זה מאפשר גישה מהאינטרנט הגלובלי ללא הגבלה.
מומלץ להימנע מרשתות מורשות גדולות מדי מומלץ להימנע משימוש בקידומות CIDR קטנות ברשתות מורשות, כי זה מאפשר גישה ממספר רב מדי של מארחים. מומלץ להשתמש בקידומת CIDR בגודל ‎ /16 לפחות, ועדיף בגודל ‎ /19 ומעלה.
הפעלת מדיניות לסיסמאות כדי למנוע הגדרה של סיסמאות חלשות, להגדיר זמן תפוגה ולהגדיר נעילת חשבון במקרה של ניסיונות התחברות שנכשלו, צריך להשתמש במדיניות סיסמאות של מכונות MySQL או PostgreSQL כדי לציין מדיניות סיסמאות מתאימה למכונת מסד הנתונים. זה חשוב במיוחד אם אתם מגדירים את המופע לכתובת IP ציבורית.
פועלים לפי דפוסי שימוש מאובטחים בסכימה כדי למנוע מתקפות של חטיפת נתיב חיפוש, חשוב לוודא שלמשתמשים עם הרשאת אדמין יש נתיב חיפוש מאובטח. אנחנו ממליצים להגדיר את הפרמטר search_path לערך pg_catalog למשתמשים עם הרשאות גבוהות. אפשר לקרוא מידע נוסף במאמר בנושא שימוש בנתיב חיפוש מאובטח.
הגדרה של log_statement לערך none הדגל log_statement מוגדר כ-none כברירת מחדל. אם הערך לא מוגדר ל-none, ‏ PostgreSQL יכול לרשום ביומן הצהרות שכוללות סיסמאות. מומלץ להשתמש ב-pgAudit לביקורת מסדי נתונים במקום ב-log_statement.

ארכיטקטורת נתונים

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

הטמעה של אפליקציה

שיטה מומלצת מידע נוסף
להשתמש בשיטות טובות לניהול חיבורים, כמו איגום חיבורים (connection pooling) והשהיה מעריכית לפני ניסיון חוזר (exponential backoff). השימוש בטכניקות האלה משפר את השימוש במשאבים באפליקציה ועוזר לכם להישאר במסגרת מגבלות החיבור של Cloud SQL. למידע נוסף ולדוגמאות קוד, אפשר לעיין במאמר בנושא ניהול חיבורים למסדי נתונים.
בודקים את התגובה של האפליקציה לעדכוני תחזוקה, שיכולים להתבצע בכל שלב במהלך חלון הזמן לתחזוקה. אפשר לנסות תחזוקה בשירות עצמי כדי לדמות עדכון תחזוקה. במהלך התחזוקה, המופע שלכם לא יהיה זמין לפרק זמן קצר, והחיבורים הקיימים ינותקו. בדיקה של השקות תחזוקה מאפשרת לכם להבין טוב יותר איך האפליקציה מטפלת בתחזוקה מתוזמנת וכמה מהר המערכת יכולה להתאושש.
בודקים את התגובה של האפליקציה למעבר לגיבוי, שיכול לקרות בכל שלב. אפשר להפעיל מעבר לגיבוי ידנית באמצעות המסוף Google Cloud ,‏ gcloud CLI או ה-API. מידע נוסף זמין במאמר בנושא הפעלה של מעבר לגיבוי בשעת כשל.
הימנעו מעסקאות גדולות. חשוב שהעסקאות יהיו קטנות וקצרות. אם צריך לעדכן מסד נתונים גדול, עדיף לבצע את העדכון בכמה עסקאות קטנות ולא בעסקה גדולה אחת.
אם אתם משתמשים בשרת proxy ל-Cloud SQL Auth, חשוב לוודא שאתם משתמשים בגרסה העדכנית ביותר. איך מעדכנים את שרת ה-proxy ל-Cloud SQL Auth

ייבוא וייצוא של נתונים

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

גיבוי ושחזור

שיטה מומלצת מידע נוסף
הגנה על הנתונים באמצעות הפונקציונליות המתאימה של Cloud SQL.

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

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

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

הגנה על המופע ועל הגיבויים מפני מחיקה מקרית.

מכונת Cloud SQL שיוצרים במסוף Google Cloud או באמצעות Terraform מאפשרת כברירת מחדל מניעת מחיקה בטעות.

כדי להוסיף שכבת הגנה לנתונים, אפשר להשתמש בתכונת הייצוא ב-Cloud SQL. אפשר להשתמש ב-Cloud Scheduler עם REST API כדי לבצע אוטומציה של ניהול הייצוא. בתרחישים מתקדמים יותר, אפשר להשתמש ב-Cloud Scheduler עם פונקציות Cloud Run לאוטומציה.

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

מידע נוסף על שיטות כלליות לפי מנוע מסד נתונים זמין במאמרים הבאים: