9 בפברואר 2017

PostgreSQL מהדורות 9.6.2, 9.5.6, 9.4.11, 9.3.16 ו 9.2.20  שוחררו לאוויר!

קבוצת הפיתוח העולמית PostgreSQL שמחה להודיע על הזמינות של PostgreSQL מהדורות 9.6.2, 9.5.6, 9.4.11, 9.3.16 ו 9.2.20.

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

 

 

קבוצת הקהילה ב Telegram

פתחנו את קבוצה של קהילה ב Telegram.

קבוצה נוצרה על מנת לתת מענה מהיר לבעיות או שאלות של חברי הקהילה בנושא של שימוש ב PostgreSQL.

נשמח לעזור למשתמשים מתחילים ומתקדמים כאחד.

ניתן להצטרף לקבוצה בלינק.

 

קול קורא

לפני שבוע ימים נערכה במוסקבה שברוסיה פגישה בין חברי הקהילה העולמית של PostgreSQL לבין נציגים מישראל. בין המשתתפים נכחו: מר Bruce Momjian חבר בצוות ליבה של PostgreSQL, מנכ"ל ספקית המוצר ברוסיה ו Major Contributor של התוכנה, מר Oleg Bartunov, מר מיכאל גולדברג ומר ודים יארצנקו היזמים מישראל.

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

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

HiLoad++ 2016

HighLoad 2016

הכנס HighLoad++ התקיים השנה בפעם העשירית ומשך 2,500 משתתפים. האירוע נועד לחילופי ידע על טכנולוגיות המשרתות בו זמנית אלפי או מיליוני משתמשים.

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

אופטימיזציה של מסד הנתונים ויישומים

להרצה מהירה של השאילתות במסד הנתונים בעיקר נדרשים:

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

תחזוקת מסד הנתונים בצורה תקינה

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

הגדרות של Planner/Optimizer

ההתאמות הבאות מאפשרות לPlanner להעריך נכון את הערך של פעולות שונות ולבחור את תכנית הביצוע הטובה ביותר עבור שאילתות.

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

default_statistics_target

פרמטר זה מציין את כמות הנתונים הסטטיסטיים שנאספת על ידי הפקודה ANALYZE. הגדלת הפרמטר תגרום למערכת לעבוד יותר, אך היא יכולה לאפשר לבנות תכניות מהירות יותר, ע"י שימוש במידע הנוסף שהתקבל. נתונים סטטיסטיים עבור שדה אפשר להגיד ע"י ALTER TABLE ... SET STATISTICS.

הגדרות אחרות (המשך)

- full_page_writes, תבחר באפשרות off, אם fsync = off. אחרת, כאשר on נבחר, PostgreSQL כותב את התוכן של כל רשומה ביומן בשינוי הראשון של הטבלה. זה נחוץ משום שהנתונים עשויים להיות שמורים באופן חלקי בלבד, אם בזמן התהליך נפלה מערכת ההפעלה. זה יגרום שבדיסק יהיה מידע חדש מעורבב עם הישן. רישום ביומן יכול להיות לא מספיק על מנת לשחזר את הנתונים באופן מלא לאחר נפילת מערכת ההפעלה. full_page_writes מבטיח התאוששות בצורה נכונה, ע"י עלייה בכמות הנתונים שייכתבו ביומן (הדרך היחידה להפחית את כמות הנתונים ביומן היא להגדיל checkpoint_interval).

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

- 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.

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