סקירה כללית על ניהול מאגר חיבורים

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

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

תרחישי שימוש ושיקולים

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

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

מידע נוסף על הפעלת ניהול מאגר חיבורים זמין במאמר הגדרת ניהול מאגר חיבורים.

דרישות

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

אפשרויות שיתוף

התכונה 'ניהול מאגר חיבורים' מאפשרת לכם לנהל את אופן יצירת מאגר החיבורים באמצעות הפרמטר pool_mode. אפשר להשתמש באפשרויות הבאות של שיתוף משאבים:

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

אפשרויות הגדרה מתקדמות

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

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

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

ערך ברירת המחדל הוא 0 חיבורים.
max_client_connections המספר המקסימלי של חיבורים שמותרים למופע כשמשתמשים ב-Managed Connection Pooling. ערך ברירת המחדל הוא 5,000 חיבורים.
max_prepared_statements המספר המקסימלי של משפטי SQL מוכנים בעלי שם ברמת הפרוטוקול שנתמכים במצב איגום transaction.

הגדרת האפשרות הזו ל-0 משביתה את התמיכה בהצהרות מוכנות. כדי להשיג ביצועים אופטימליים, הערך הזה צריך להיות גבוה ממספר ההצהרות המוכנות שנעשה בהן שימוש נפוץ במסד הנתונים. מספר גדול של משפטי SQL מוכנים ב-Managed Connection Pooling עלול לגרום לעלייה בשימוש בזיכרון.

ערך ברירת המחדל הוא 0 הצהרות.
client_connection_idle_timeout משך הזמן שחיבור לקוח נשאר בלי פעילות לפני שהוא נסגר בגלל זמן קצוב לתפוגה. הערך הזה יכול להיות בין 0 ל-2,147,483 שניות, וערך ברירת המחדל הוא 0 שניות.
server_connection_idle_timeout משך הזמן שחיבור לשרת נשאר ללא פעילות לפני שפג הזמן הקצוב שלו. הערך הזה יכול להיות בין 0 ל-2,147,483 שניות, וערך ברירת המחדל הוא 600 שניות.
query_wait_timeout הזמן שבו שאילתה ממתינה לחיבור לשרת במאגר לפני שפג הזמן הקצוב לתפוגה שלה.

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

הערך יכול להיות בין 0 ל-2,147,483 שניות, וערך ברירת המחדל הוא 120 שניות.
ignore_startup_parameters הפרמטרים שרוצים להתעלם מהם, שלא מתבצע אחריהם מעקב בחבילות ההפעלה של Managed Connection Pooling כברירת מחדל.
server_lifetime משך הזמן המקסימלי שחיבור לשרת לא נמצא בשימוש לפני שהתכונה 'ניהול מאגר חיבורים' סוגרת אותו. אם הערך מוגדר כ-0 שניות, החיבור נסגר מיד אחרי השימוש.

ערך ברירת המחדל הוא 3,600 שניות.

מגבלות

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

  • הפעלת ניהול מאגר חיבורים במופע קיים גורמת להפעלה מחדש של מסד הנתונים.
  • אפשר להשתמש בניהול מאגר חיבורים רק עם Cloud SQL Auth Proxy בגרסה 2.15.2 ואילך.
  • אם אתם משתמשים ב-Cloud SQL Go Language Connector, מומלץ להשתמש בגרסת Go 1.24 לפחות. אם אתם משתמשים בגרסה 1.23 של Go או בגרסה מוקדמת יותר, יכול להיות שתיתקלו במגבלות על הביצועים כשאתם משתמשים בניהול מאגר חיבורים.

  • אם משתמשים בניהול מאגר חיבורים במצב transaction pooling, התכונות הבאות של SQL לא נתמכות:

    • SET/RESET
    • LISTEN
    • WITH HOLD CURSOR
    • PREPARE/DEALLOCATE
    • PRESERVE/DELETE ROW טבלאות זמניות
    • LOAD
    • נעילות מייעצות ברמת הסשן

  • אם אתם משתמשים בספריית ממשק מסד הנתונים asyncpg לניהול מאגר חיבורים ביציאות 3307 ו-6432, אתם צריכים לעדכן את max_prepared_statements לערך גדול מ-0 כדי להפעיל תמיכה בהצהרות מוכנות בניהול מאגר חיבורים.

  • אם אתם משתמשים ב-Cloud SQL ל-PostgreSQL בגרסה 17, האפשרות sslnegotiation=direct לא נתמכת.

  • אין תמיכה במעקב אחרי כתובות IP של לקוחות בשימוש במאגר חיבורים מנוהל. אם מפעילים את האפשרות שמירת כתובות ה-IP של לקוחות בתובנות לגבי שאילתות, כתובות ה-IP של הלקוחות מוצגות כ-local במקום כתובת ה-IP עצמה.

יציאות שמשמשות את Managed Connection Pooling

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

היציאות שבהן נעשה שימוש בניהול מאגר חיבורים והאפשרויות הזמינות של IAM הן:

חיבורי שרת שמשמשים את Managed Connection Pooling

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

אם אתם משתמשים בברירת המחדל max_pool_size של 50 מאגרי חיבורים במופע שלכם, מומלץ להזמין לפחות 15 חיבורי שרת לכל CPU עבור Managed Connection Pooling כשמגדירים את האפשרות max_connections למסד הנתונים. מידע נוסף על הדגל max_connections זמין במאמר חיבורים מקבילים מקסימליים. כדי לשנות את האפשרות max_connections במופע, אפשר לעיין במאמר בנושא הגדרת אפשרויות של מסד נתונים.

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