הבלוג של Postgres Miktzoanim

יומן הטרנזקציות (Write-Ahead Log) ונקודות הבקרה (Checkpoints)

יומן הטרנזקציות של PostgreSQL עובד כדלקמן: שינוים בקבצי הנתונים (טבלאות ו אינדקסים) נעשים רק לאחר

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

שכפול לוגי

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

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

יתרונות:

  • היכולת לשכפל חלק מטבלאות של מסד הנתונים
  • היכולת לשכפל מסד נתונים
  • יכולת כתיבה לרפליקה
  • היכולת לשכפל גרסאות PostgreSQL שונות

חסרונות:

Parallel queries and transaction isolation levels

ב PostgreSQL 9.6 הופיעו שאילתא במקבילה (Parallel queries). זוהי פונקציונלית מאוד חזקה. מהות שאילתא במקבילה, היא בכך כי יש עכשיו ל planer יש את היכולת לפריד את שאילתא לתתי-שאילתות, לבצע אותם במקביל, ולאחר מכן לבצע אגרגציה עם התוצאות. לשם כך, ישנם מספר ישויות חדשים - Workers ו Gather. Workers מבצעים תת-שאילתות, Gather - משלב את התוצאות. עבור המספר המרבי של Workers קיים פרמטר max_parallel_workers_per_gather בקובץ postgresql.conf. זה לא הגיוני להגדיר ערך זה גבוה יותר מאשר מספר הליבות CPU הזמינות (CPU core).

כלים של PLSR

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

הראשון - replication slots. הופיע בגרסה 9.4.replication slots אוטומטית מספקים מנגנון להצלת מגזרי WAL עד שהם מתקבלים על ידי כל שרתי הגיבוי. השרת הראשי לא ימחק שורות אשר במצב recovery conflict גם אם הגיבוי כבוי.

שכפול סינכרוני

עד גרסה 9.5 כולל Master כאשר הוגדר synchronous_commit = on מחכה לאישור מלפחות רפליקה סינכרונית אחת אשר מופיעה בפרמטר synchronous_standby_names.

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

לדוגמה:

synchronous_standby_names = 2 (standby1, standby2, standby3)

בעת שימוש בשכפול סינכרוני Master לא יכול לבצע commit כל עוד WAL הנדררש לא יחול על Slaves.

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

יתרונות:

Physical Log Streaming Replication - PLSR

יש כמה רמות של WAL:

  • minimal
  • replica (עד 9.6 היה hot_standb)
  • logical

ל PLSR מתאים 2 - minimal ו logical, אבל גם מספיק לקבוע את replica.

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

יתרונות:

הקדמה ל PostgreSQL replication

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

 

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

במאמר זה אנסה לסקור את סוגי replication ב PostgreSQL.

 

הגדרה

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

שינוי הגדרות של השרת (המשך)

מאגר עבור אובייקטים זמניים: temp_buffers

משתשמים בעיקר עבור טבלאות זמניות.

 

max_prepared_transactions - מספר של PREPARED TRANSACTIONS

אפשר להשאיר את ברירת המחדל - 5.

 

משך הזמן, באלפיות שנייה, שבמהלכו התהליך יתעכב אשר עבר את vacuum_cost_delay.

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

כדי לאפשר פונקציונליות זו, אתה צריך להעלות את הערך של vacuum_cost_delay מעל 0. תשתמשו בערך סביר של 50 עד 200 ms.

זכרון עבור פקודת VACUUM

maintenance_work_mem - פרמטר זה מגידר את כמות הזיכרון עבור פקודות:

VACUUM, ANALYZE, CREATE INDEX והוספת מפתחות זרים.

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

אפשר לקבוע את ערך בין 50 ל 75% ביחס לגודל של טבלה או אינדקס הכי גדולים.

א כאשר אי אפשר לקבוע במדוייק, מ -32 עד 256 MB.

חייבים לקבוע ערך יותר גדול מאשר work_mem. ערך גדול מדי יגרום ל swappingי

לדוגמה, לזיכרון 1-4 GB מומלץ להגדירן 128-512 MB.

 

פעם הבאה נדבר על temp_buffers.

זיכרון מיון תוצאת השאילתה work_mem

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

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

ערך סביר נקבע כדלקמן:

הסכום הזמין של RAM (אחרי שמופחתים מהזיכרון כל מה שדרוש ליישומים אחרים ואת shared_buffers) מחולק במספר המרבי של בקשות מקבילות שמוכפל במספר הממוצע של פעולות בבקשה אשר הדורשים את הזיכרון.

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

אם קיבולת הזיכרון היא גדולה מדי, זה יכול להוביל ל swapping.