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

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

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

מאגרי חיבורים וכלים לניהול מאגרי חיבורים

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

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

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

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

הקשר בין המשתתפים במאגר לבין המאגרים

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

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

הביצועים ויכולות ההתאמה לעומס של Managed Connection Pooling פועלים בכמה רמות:

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

    • במכונה עם 2 או 4 מעבדי vCPU פועל מאגר חיבורים אחד.
    • מופע עם 8 vCPU מריץ 2 connection poolers.
    • במכונה עם 16 מעבדי vCPU פועלים 4 מאגרי חיבורים.
    • במכונה עם 32 vCPUs פועלים 8 מאגרי חיבורים.
    • במופע עם 64 vCPU פועלים 16 connection poolers.

  • מאגרים ושינוי גודל המאגר: מאגרי החיבורים פועלים באופן עצמאי, ולכן כל אפשרויות ההגדרה חלות על כל מאגר חיבורים בנפרד, ולא באופן גלובלי על כל המכונה. חיבורים לשרת נוצרים לפי דרישה עד למגבלה המקסימלית שמוגדרת על ידי max_pool_size לכל מאגר מנוהל בכל מאגר חיבורים. לדוגמה, אם הערך של max_pool_size הוא 50 במכונה שפועלים בה 2 מאגרי חיבורים (8 מעבדי vCPU), כל מאגר חיבורים יכול לפתוח עד 50 חיבורים לשרת בשביל זוג ספציפי של מסד נתונים ומשתמש, וכך לאפשר עד 100 חיבורים לשרת במכונה בשביל המאגר הזה. חשוב להגדיר את גודל המאגר בצורה מדויקת כדי לשפר את הביצועים: אם הערך נמוך מדי, זמני ההמתנה לחיבור עלולים להתארך, ואם הוא גבוה מדי, משאבי השרת של מסד הנתונים עלולים להתבזבז.

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

    • ‫max_client_connections: מגבילה את מספר החיבורים המקסימלי של לקוחות שמותר לכל מאגר חיבורים (ערך ברירת המחדל הוא 5,000 חיבורים לכל מאגר חיבורים).
    • ‫client_connection_idle_timeout: קובעת את משך הזמן שבו חיבור של לקוח יכול להישאר במצב של חוסר פעילות לפני שתוקף הזמן שלו יפוג.
    • ‫query_wait_timeout: קובע את משך הזמן שבו שאילתה ממתינה לחיבור זמין לשרת במאגר לפני שהזמן הקצוב לתפוגה נגמר.

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

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

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

ערך ברירת המחדל הוא 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 שניות, החיבור ייסגר מיד אחרי השימוש.

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

מגבלות

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

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

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

אם אתם משתמשים בערך ברירת המחדל של max_pool_size ל-50 חיבורים לכל מאגר, מומלץ להקצות לפחות 15 חיבורים לשרת לכל מעבד (CPU) לניהול מאגר החיבורים כשמגדירים את הדגל max_connections למסד הנתונים. מידע נוסף על הדגל max_connections מופיע במאמר מספר החיבורים המקסימלי בו-זמנית. כדי לשנות את הדגל max_connections במכונה, קראו את המאמר הגדרת דגלים של מסדי נתונים.

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