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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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