10 אוגוסט 2017

PostgreSQL 10 בטא 3 שוחררה לאוויר!

קבוצת הפיתוח העולמית PostgreSQL שמחה להודיע על הזמינות של PostgreSQL 10 בטא 3.

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

 

 

הגדרות נוספות

- commit_delay (במיקרו-שניות, 0 כברירת מחדל) ו commit_siblings (ברירת מחדל 5) מגדירים את מרווח הזמן בין הכנסת הטרנזקציה למאגרי היומן ושמירה שלה בדיסק.

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

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

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

fsync, synchronous_commit והאם ניתן לגעת בהם

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

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

PostgreSQL Bi-Directional Replication

Bi-Directional Replication או BDR, זאת התוספת הפונקציונלית החדשה ל PostgreSQL, המספקת כלים מתקדמים לשכפול הגיוני.

כרגע זה עדיין פתרון צעיר, אך כבר מוכן לשימוש. BDR מאפשר ליצור תצורות multi-master אסינכרוניות, .מבוזרות גאוגרפית באמצעות רפליקציה מובנית Logical Log Streaming Replication או LLSR
עם זאת, BDR אינו כלי Clustering, כפי שכאן אין Database transactions managers.

Meetup: Open-Source Projects from Israel, Based on PostgreSQL

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

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

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

הכניסה חופשית, אך יש להירשם:

https://www.meetup.com/PostgreSQL-Israel/events/236092627

pglogical

ההבדל העיקרי מפתרונות אחרים ל pglogical, זה שהוא מיושם עם מנגנון הפענוח של מגזרי WAL ולכן נקרא Logical Log Streaming Replication.

אפשר לומר כי עד לנקודה מסוימת, זה דומה מאוד ל PLSR.

Write-Ahead Log מועתק מן Master ל Slave, ושם הוא מפוענח. יתר על כן, לאחר מכן "נבחר" את הפקודות DML עבור הטבלאות המעורבות בשכפול.

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

יתרונות:

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

יתרונות:

תגובות אחרונות