בחברה עובדים על תוכנה בצד השרת שכוללת בסיס נתונים. כמובן שלא מפתחים ישירות על מערכת הפרודקשן, אלא על מערכת דומה - ואולי אפילו כל מפתח עובד על גרסא מקומית של בסיס הנתונים.
במשך הזמן, מפתחים משנים את המבנה של בסיס הנתונים, מוסיפים טבלות,עמודות ואינדקסים, ואולי גם מוחקים כמה.
יכול להיות שיש יותר ממפתח אחד שעושה את זה.
איך מעבירים את השינויים האלו למערכת הפרודקשן?
אם מערכת הפרודקשן עדיין לא למעלה, אפשר כמובן להעיף את בסיס הנתונים וליצור את הכל מחדש, אבל זה לא המקרה בדרך כלל.
אופציה אחרת היא לשאול את המפתחים, מה שיניתם? אבל הם אחרי שבועיים, אף אחד לא זוכר בדיוק מה הוא שינה כדי לפתור באג אזוטרי זה או אחר או כדי להוסיף פיצ’ר מסויים, וכמובן שאף אחד לא רושם דברים כאלו.
אופציה שלישית היא להשוות ידנית, לא כיף גדול ומועד לטעויות.
אבל חייבת להיות דרך לבצע אוטומציה של האופציה השלישית, זה תהליך די מכאני.
מסתבר שיש דרך, כלי בשם SQLFairy שמאפשר לקבל הבדלים בין שתי סכימות MySQL ומפיק הוראות MySQL למעבר מסכימה אחת לשניה. הוא מאפשר עוד כמה דברים, אבל אני חושב שזה הכי מעניין.
תיאורטית הכלי תומך גם במעבר בין בסיסי נתונים שונים, אבל קיבלתי רושם שזה עובד ממש רק עם MySQL.
בגדול, כדי לעבור מסכימה אחת לשניה, מה שצריך לעשות זה להוריד את המבנה של שני הסכימות לקובץ עם mysqldump, למשל:
ברגע ששיש לנו את שתי הסכימות ביד, ואחרי שהתקנו את SQLFairy כמובן (apt-get install sqlfairy על דביאן לני, אם אתם על Etch תתקינו ידנית מהקוד, הגרסא שבEtch לא עובדת טוב), אפשר לקבל הוראות מעבר מסכימה אחת לשניה כך:
זה יפיק הוראות מעבר (CREATE , ALTER, DROP) שיהיה אפשר להריץ על בסיס הנתונים כדי לישר קו בין הסכימות.
(אני שולח את stderr ל/dev/null כי יש אזהרות חסרות חשיבות מהסקריפט שנובעות מגרסת perl יותר חדשה מזו שהסקיפט פוחת עליה)
אני משתמש בסקריפט דומה לזה כדי להפוך את התהליך ליותר קל (הקובץ prod-struct.sql.gz מכיל את מבנה הסכימה שאני רוצה לקבל) :
בוקסי היא מערכת מדיה סנטר שמבוססת על המערכת פתוחת הקוד xbmc ומפותחת על ידי.. בוקסי, סטארטאפ ישראלי.
כיאה למערכת שמבוססת על מערכת אחרת בקוד פתוח, בוקסי בעצמה היא פתוחת קוד ומשוחררת ברשיון GPL ותחת עוד כמה רשיונות קוד פתוח (למרות שלא הצלחתי למצוא אישוש להנחה הזו בשום מקום).
בנוסף, הצוות של בוקסי משחרר קוד כל הזמן לפרוייקט XBMC, למשל את הפורטים ללינוקס ואולי גם לMac הם תרמו חזרה לפרוייקט. (תרומה משמעותית במיוחד).
בוקסי נמצאת בשלב האלפא, מה שאומר שיש באגים ויש בעיות שמישות.
מצד שני, בוקסי נמצאת בפיתוח מהיר ומתמיד, ורואים שיפורים מגרסא לגרסא.
אחד הדברים הבולטים שמבדילים את בוקסי ממערכות מדיה סנטר אחרות הוא שבוקסי היא מערכת מדיה סנטר חברתית, שמאפשרת לכם לדעת במה החברים שלכם צופים, וכן להמליץ ולקבל המלצות מהחברים.
למי שמודאג מהפרטיות, אפשר להגדיר דרך האתר שבוקסי תחלוק מידע עם כל העולם, רק עם חברים או עם אף אחד.
בוקסי תומכת בהזרמת וידאו ממגוון שרותים כולל hulu, קומדי סנטרל ועוד.
Hulu חסום למי שאינו תושב ארצות הברית, אבל ניתן לקוות שבשלב מסויים תהיה לו חלופה שעובדת בארץ (קשה לי להאמין שהולו “ישדרו” אל מחוץ לארצות הברית).
אחד הדברים הנחמדים הוא שבוקסי מאפשרת צפייה בטריילרים של סרטים, אפילו של סרטים שיש לכם (יכול לעזור להחליט באיזה סרט בא לכם לצפות עכשיו).
המערכת פשוט יפהפיה, והממשק נוח מאוד ברובו ומתאים לשלט, למקלדת ולעכבר.
בזמן ניגון סרט, תוכלו לנווט בתפריטים כאשר הסרט ממשיך לנגן מתחת לתפריטים החצי שקופים. ממש איכות חיים.
המסך הראשי של בוקסי מחולק לארבעה חלקים:
* המלצות חברים, שמכיל המלצות אחרונות של חברים שלכם.
* פעילות חברים אחרונה, שמכיל את הדברים האחרונים שראו או שמעו החברים שלכם
* קבצים שנוספו לאחרונה לאוסף שלכם
* דברים שעשיתם לאחרונה - מה ראיתם או שמעתם.
חוץ מזה, יש בצד שמאל של המסך תפריט נסתר שמאפשר עייון באוסף שלכם, צפיה בוידאו מוזרם מאתרים (כן, גם מיוטיוב - הידד!), הגדרות של בוקסי ועוד.
בוקסי כוללת גם לקוח ביט טורנט מובנה, שמאפשר להוריד תוכן חוקי למהדרין.
ניתן להוסיף פיד רסס מכל מקום אחר, והמבין יבין.
השילוב עם לקוח הביט טורנט עדיין בסיסי ויש עוד מה לשפר, אבל זו התחלה טובה.
הדבר הראשון שבוקסי עושה אחרי שמפעילים אותה ומוסיפים כמה מקורות וידאו ומוסיקה (במילים אחרות, מספרים לבוקסי איפה ספריית המדיה שלכם) זה לסרוק את הספריה, ולאסוף עליה מידע דרך מגוון שרותים באינטרנט.
בוקסי תשיג את הארטוורק של עטיפות הסידים של המוסיקה שלכם, את ה”פוסטרים” של הסרטים והסדרות, ובמקרה והיא לא הצליחה למצוא היא פשוט תציג תמונה מתוך קובץ הווידאו במקרה של וידאו.
חוץ מגרפיקות, בוקסי גם תביא תקצירים של סרטים וסדרות, אפילו ברמת הפרק הבודד (!).
לפעמים בוקסי לא מצליחה לזהות, או אפילו טועה בזיהוי. במקרים האלו תוכלו לעזור לה ולתקן אותה.
בזמן ניגון סרט, בוקסי מאפשרת חיפוש כתוביות אוטומטית לפי הסרט או הסדרה או לפי שם הקובץ במידה והקובץ לא מזוהה.
החוויה ממש מרעננת, במקום ללכת למחשב ולהתחיל לחפש תרגום מתאים, אפשר לעשות את זה מהסלון עם השלט ישר מתוך בוקסי, ולהתחיל להשתמש בתרגום לסרט בזמן שהסרט רץ, בלי להחסיר פריים.
עוד תכונה מרעננת, במיוחד למורידי הסדרות הסדרתיים - היא היכולת לנגן סרט ישירות מתוך קובץ הRAR, אפילו אם מדובר בRAR עם כמה קבצים.
בוקסי מתחילה לנגן מיד, בלי לחכות שהקובץ יפרש (במילים אחרות, בוקסי עושה הזרמת וידאו ישר מתוך הRAR).
לא הבחנתי בירידת ביצועים בזמן הצפיה בסרט מתוך RAR.
הבעיה עם זה שנכון לכרגע בוקסי לא מזהה ולא מאפשרת לעזור לה לזהות קבצים בתוך RAR, אבל אני בטוח שהחברה הטובים בבוקסי יפתרו את הבעיה הזו.
נכון לכרגע, בוקסי תומכת רשמית בMac, בAppleTV ובאובונטו לינוקס, אבל החל מהגרסא האחרונה ששוחררה היא גם עובדת על דביאן לני.
צפויה גם גרסאת חלונות בעוד כמה חודשים.
בוקסי לא חפה מבעיות, אבל היא אלפא ולכן אפשר לסלוח.
חלק קטן מהבאגים שנתקלתי בהם:
* תרגומים בעברית מוצגים כג’יבריש, כנראה חסר פונט.
* המערכת די יציבה, אבל יש קריסות עקביות אצלי בניגון קבצי מוסיקה, וכן קריסות אקראיות בסיטואציות מסויימות שטרם הצלחתי לאפיין.
כאמור, המערכת באלפא וכדי לנסות אותה צריך הזמנה.
מי שרוצה הזמנה שיבקש, אני אנסה לשלוח (אני לא יודע אם יש הגבלה על מספר ההזמנות שאני יכול להוציא).
שדרגתי את השרת שמפעיל את הבלוג הזה ואת האתר של פיירסטטס מדביאן Etch לדביאן Lenny.
הסיבה היא שקצתי בחבילות ישנות, ספציפית יש לי בעיה באתר של פיירסטטס (שרץ על trac) שמאוד יכול להיות שנובעת מגרסא ישנה של python ו/או גרסא ישנה של sqlite.
בכל אופן, השדרוג לא היה חלק במיוחד, אבל נראה שהוא הסתיים בהצלחה.
באופן רגיל, שדרוג של הפצת דביאן מתבצע כך:
משנים את /etc/apt/sources.list ומחליפים כל אזכור של etch בlenny.
מבצעים apt-get update
מבצעים apt-get dist-upgrade
ומקווים לטוב.
במקרה שלי, הוספתי שני שלבים נוספים:
אני משתמש בסקריפט בשם ipkungfu שאחראי להגדיר את הפיירוואל של השרת. הממשק שלו הרבה יותר ידידותי מזה של iptables (והוא בסך הכל מעטפת שדואגת שאני לא אצטרך להשתמש בiptables ישירות).
מכיוון שאני יודע שהיה שינוי בתחביר מהגרסא הישנה שבEtch לגרסא שבLenny, דאגתי לכבות את הפיירוואל לפני העדכון כדי לא לנעול את עצמי מחוץ למערכת בטעות.
לא בטוח שזה מה שהיה קורה, אבל עדיף להיות בטוח.
כדי לצמצם את הזמן שהאתר היה למטה, הורדתי מבעוד מועד את כל החבילות על ידי הרצת:
apt-get dist-upgrade –download-only
שמוריד את מה שצריך אבל לא מתקין.
אחרי ההכנות האלו, הרצתי dist-upgdade רגיל בתקוה שההרפתקאה לא תהפוך לסופת חרא.
אחרי השדרוג, הבעיה הראשונה שהבחנתי בה היתה שהאפאצ’י מתלונן על זה:
apache2[Fri Oct 24 19:09:36 2008] [warn] NameVirtualHost *:80 has no VirtualHosts
מסתבר שהחברים בדביאן החליטו להוסיף את ההצהרה על שימוש בהוסטים וירטואליים לקובץ הports.conf, מה שאמר שהיו שתי הצהרות כאלו.
הודעת השגיאה הסתומה שקיבלתי היא התוצאה.
הסרתי את ההגדרה שלי והבעיה נעלמה.
בעיה נוספת היא שtrac הפסיק לעבוד.
האמת היא שמכיוון שלא התקנתי את trac דרך apt-get הייתי מופתע אם הוא ההיה ממשיך לעבוד.
הסיבה הפעם היא שדביאן לני מתשמש בPython 2.5 ומכיוון שתוכניות פייתון מותקנות משום מה לתוך ספריה שספציפית לגרסאת הפייתון, הייתי צריך להתקין מחדש את trac לתוך פייתון 2.5.
עד כאן הכל טוב.
בעיה נוספת הגיעה מהכיוון של שרת הדואר postfix.
השרת הזה עדיין לא משמש אותי לקבלת דואר (אני עדיין משתמש בשרת שבבית למטרה הזו) אבל הוא כן משמש לשליחת דואר.
בשלב מסויים שמתי לב שאני לא מקבל אימיילים על טיקטים חדשים שנוספו לtrac, מה שמייד החשיד את מערכת הדואר.
נראה שברגעים אלו ההתקנה של postfix בלני שבורה, ונאלצתי לדרדס קבצים מהמחשב בסלון שגם מריץ את לני כדי להצליח בהתקנה.
בעיה אחרונה הגיעה מהכיוון של ipkungfu, סקריפט הפיירוואל.
הבעיה היתה הודעות שגיאה מוזרות, שאפילו המפתח שלו לא הצליח להבין מאיפה הן באות (הוא יושב ב#ipkungfu בפרינוד).
בסוף הצלחתי לגרום לו לפעול איכשהו.
כל הסיפור לקח כשלוש ארבע שעות, כאשר רוב האתרים שאני מריץ לא היו למטה יותר מחצי שעה להערכתי.
די בטוח שנגלה עוד תקלות בהמשך, אבל סך הכל זה לא היה נורא.
מחר אני נוסע לאינטל חיפה כדי לבדוק את הביצועים של תוכנה שאנחנו מפתחים על הדור הבא של המעבדים של אינטל (ארכיטקטורת Nehalem), שישוחררו עוד כחודש וחצי.
אני הולך לבדוק מכונה עם שני מעבדים של ארבעה ליבות כל אחד, כאשר כל ליבה מריצה שני נימים (אינטל מחזירים את הHyperThreading) - ככה שבעצם המוכנה הזו תהיה שקולה למדי למכונה עם 16 ליבות.
הארכיטקטורה החדשה של נהלם צפויה לתת ביצועים טובים משמעותית לעומת הדור הנוכחי (לכל ליבה), בצריכת חשמל יותר נמוכה.
מומלץ מאוד לראות את הדמו.
את הפיתוח של המערכת שאני הולך לבדוק שם אני מבצע על דביאן, ואינטל הכינו מערכת עם רדהאט.
למרות שמירב הסיכויים הם שאני אצליח לגרום למערכת לרוץ, ממש לא בא לי להתחיל לחקור ולתקן במקום כל מני בעיות אזוטריות (אני מודאג בעיקר מספריות מגרסאות לא תואמות).
חשבתי לעצמי שיהיה נחמד לבוא עם סביבה מוכנה במקום לבוא ולהתקין הכל במקום בסביבה זרה, ומה יותר מתאים לזה מLIVE CD + כונן קשיח נייד?
הבחירה הטבעית שלי היתה Knoppix, הורדתי את הISO, העלתי אותו בVirtualBox, שמתי את האפליקציה על הדיסק הנייד והתחלתי לנסות להפעיל אותה.
למרבה הצער היו מלא בעיות, כשהקש ששבר את ראש הגמל היה שlibstdc++ היה מגרסא לא מתאימה.
החלטתי לוותר על התענוג, וביגוני חיפשתי בגוגל “Debian live cd”.
התוצאה המפתיעה היא שיש פרוייקט בשם Debian live!
כמו תמיד עם live cd, חיפשתי מאיפה מורידים את הISO, התחלתי להוריד, ולמרבה המזל מהירות ההורדה היתה כ20K בשניה.
למה מזל?
כי במהירות כזו, היה לי מספיק זמן כדי להסתכל קצת מסביב.
About
A Debian Live system is a Debian operating system that does not require a classical installer to use it. It comes on various media, including CD-ROM, USB sticks, or via netboot.
Why Debian Live?
Although the Debian Live project is about the framework to create your own customized Live system, we offer some prebuilt images. Currently, builds for three desktop environments (GNOME, KDE and Xfce) as well as the standard system are available.
אז דביאן לייב היא בעצם מערכת ליצירת Live CD - מגניב, אבל ראיתי כבר כאלו:
לפני כשנה וחצי הגשתי פרוייקט של מנוע שחמט על דיסק Knoppix מותאם אישית.
התהליך של יצירת דיסק Knoppix מותאם הוא די מיגע, וסיקרן אותי לדעת איך זה בדביאן לייב.
מסתבר שהתהליך הוא פשוט במיוחד. כדי ליצור דיסק בסיסי ועובד:
apt-get install live-helper
mkdir live-cd
cd live-cd
lh_config
lh_build
במילים, מתקינים את live-helper, יוצרים ספרית עבודה, משתמשים בlh_config כדי ליצור קופיגורציה בסיסית, ובlh_build כדי לבנות ממנה ISO.
התהליך יכול לקחת זמן, ומומלץ להתקין את apt-cacher כדי לחסוך בזמני הורדה של חבילות דביאן.
אפשר לבדוק את הISO עם VirtualBox. המערכת שהוא מכיל היא בסיסית מאוד, אבל אפשר להתקין בתוכה מה שרוצים עם apt-get.
יש כמה דרכים להוסיף חבילות שיהיו מותקנות מראש בISO:
כדי להוסיף חבילות סטנדרטיות, בסך הכל צריך להוסיף את השם שלהן בLH_PACKAGES בקובץ config/chroot בספרייית הקונפיגורציה שיצרתם.
יש גם דרכים להוסיף חבילות מותאמות אישית, ואפשר גם להוסיף קבצים ספציפייים בקלות.
מי שהתקין את apt-cacher ירצה לשנות את מקורות ההתקנה של יצירת הISO, אפשר לעשות את זה על ידי עריכה של config/bootstrap.
התיעוד של המערכת עדיין לא מלא, אבל מספיק כדי להתחיל.
בנוסף, החברה בערוץ הIRC של הפרייקט עוזרים למי שיודע לשאול.
אני ממליץ בחום על Debian live למי שצריך Live CD.
קל מאוד ליצור דיסקים איתו, והתוצאה היא מערכת דביאן לכל דבר, שעולה מCD/DVD.
סידרתי לאמא שלי מחשב, ועליו לינוקס בלבד.
המחשב די ישן, אבל בהחלט מספיק: פנטיום 4 במהירות 2.6 ג’יגה הרץ עם 512 מגה זכרון ודיסק של 80GB.
אמא שלי חסרת כל נסיון עם מחשבים, ולא השתמשה במחשב מעולם עד עכשיו.
התקנתי לה דביאן לני, עם פיירפוקס ות’אנדרבירד בעברית (התקנות ידניות, אין את החבילות האלו בלני), וגם KDE בעברית כדי שתרגיש בנוח.
סך הכל אני אופטימי, בתוך יום אחד היא למדה את הדברים הבסיסיים (הפעלה וכיבוי של המחשב, גלישה באינטרנט, שליחה וקבלת אימיילים).
אני מרוצה מזה שאני אוכל לעזור לה מרחוק בלי בעיה:
התקנתי שרת SSH, ודאגתי שהמחשב שלה יהיה זמין בHOST קבוע (למרות שאין לה כתובת IP קבועה).
עוד יתרון משמעותי הוא שהמחשב יחזיק מעמד הרבה יותר טוב מאשר מכונה עם חלונות. גם מבחינת ביצועים וגם מבחינת עמידות לווירוסים וכו’.
נו, אז מה אתם אומרים? הניסוי יצליח או לא?
אם יש מישהו שלא עושה טעויות, ושהחומרה שלו חסינה לתקלות, הוא יכול לדלג על הפוסט הזה.
אוקיי, מי שנשאר טועה לפעמים ומוחק דברים שלא היה צריך למחוק, ולפעמים גם ההרדיסק שלו קורס בלי התגרות.
כמות העבודה שאפשר לאבד בקריסה כזו או במחיקה לא מכוונת הולכת וגדלה ככל שהכוננים הקשיחים גדלים.
לפעמים אפשר לשחזר את הנתונים שאבדו עם עבודה חוזרת, ולפעמים מה שאבד, אבד לנצח.
גיבוי ידאג למזער את הנזק שנגרם מטעות אנוש או מתקלת חומרה לחלון הזמן שמרגע התקלה לזמן שבו בוצע הגיבוי האחרון.
גיבויים ידניים נועדו להיכשל ברגע האמת כי אנשים הם עצלנים ולא טובים בביצוע של פעולות שחוזרות על עצמן לאורך זמן אם אין איזה גורם שידאג שהם ימשיכו.
במילים אחרות, אם תתחילו בגיבויים ידנייים היום, בעוד שנה תגלו שאתם לא מגבים בצורה תדירה מספיק, אם בכלל.
הפיתרון הוא גיבויים אוטומטיים לחלוטין, שלא דורשים עבודת תחזוקה ידנית.
גיבוי מערכת הקבצים
יש הרבה שיטות לגבות את מערכת הקבצים.
היסטורית, השיטה הנפוצה היתה גיבוי הקבצים לטייפ גיבוי, בפורמט TAR, למעשה, השם של TAR הוא קיצור של Tape archive.
מה שנהוג לעשות בשיטה הזו זה לשמור את הכל בפעם הראשונה, ובפעמים הבאות לשמור רק את הקבצים שהשתנו.
השיטה הזו נקראת “גיבוי מלא + גיבוי הדרגתי”, והחיסרון שלה הוא שכדי לשחזר את מה שהיה לפני שבוע, צריך ללכת לגיבוי המלא הכי קרוב ללפני שבוע (אולי בן חודשיים), ולעבור על כל הגיבויים מאותו רגע כדי לבנות את התמונה של הרגע הנתון.
לא כיף, במיוחד אם אנחנו לא בטוחים בתאריך המדוייק שבו הקובץ היה “נכון”.
גרסא נוספת של הגיבוי הזה היא “מלא + דיפרנציאלי”, בשיטה הזו גיבוי מלא נשמר, וכל גיבוי חלקי שאחריו הוא יחסי לגיבוי המלא, ולא לגיבוי החלקי האחרון. זה אומר שקבצים שהשתנו אחרי הגיבוי המלא יאוכסנו שוב ושוב, מצד שני יהיה הרבה יותר קל לשחזר את הגיבוי לרגע נתון.
הגיבוי התמים הוא פשוט להעתיק את הקבצים, כמו שהם, לספריה אחרת (ואולי למחשב אחר).
הבעיה עם זה היא שקבצים שלא משתנים יתפסו מקום כל פעם מחדש, מה שאומר שסך הכל הצריכה של המקום תהיה גבוהה מאוד.
הפתרון הוא לאכסן רק קבצים חדשים, אבל איך אפשר יהיה לשמור על הפשטות של השיטה התמימה?
אם אבד לי קובץ, אני רוצה לגשת לגיבוי של אתמול ולמצוא אותו שם, גם אם הוא לא השתנה כבר חודש.
כדי להנות משני העולמות, אפשר להשתמש בשיטה הבאה:
נגבה עם rsync, ולפני הגיבוי הבא, נעתיק את הספריה שגיבינו למקום חדש, אבל במקום להעתיק ממש את הקבצים ניצור hard-links לקבצים, ואז נגבה שוב עם rsync.
ברגע שrsync יזהה שקובץ השתנה, הוא יצור קובץ חדש במקום הלינק, ולא יפגע בקובץ המקורי שימשיך להיות זמין תחת הספריה המקורית שאליה הוא נכתב.
הרעיון הוא של מייק רובל, שפרסם אותו ב2004. מאז פותחו לא מעט סקריפטים שממשמשים את השיטה. אני משתמש בsnapback2 כדי לבצע את הגיבויים שלי.
כדי להתקין את snapback2, עקבו אחרי ההוראות האלו:
wget http://www.perusion.com/misc/Snapback2/Snapback2-0.913.tar.gz
tar xzf Snapback2-0.913.tar.gz cd Snapback2-0.913/
cpan -i Config::ApacheFormat
perl Makefile.PL && make && make test && make install && echo great success
cpan הוא מנגנון ניהול החבילות של שפת פרל. אם לא הפעלתם את cpan לפני כן, הוא ישאל כמה שאלות די קלות לפני שהוא יתקין את Config::ApacheFormat.
שימו לב לפלט של הפקודה האחרונה, אם הוא לא מסתיים ב “great success” אז היתה בעיה בהתקנה.
snapback2 עובד דרך הרשת, מה שאומר שאפשר לגבות איתו בקלות מכונה אחרת או את המכונה המקומית, אבל קודם צריך לדאוג לכך שנוכל להכנס בלי סיסמא (זהירות עם זה, צריך לשמור על הקובץ id_dsa.pub מכל משמר, כי מי שישיג אותו יוכל להכנס למכונה שאתם מגבים!).
חדי העין ישימו לב שלא גיביתי את /var/lib/mysql, שמכילה את בסיסי הנתונים של MySQL.
הסיבה היא שלא מומלץ לגבות את בסיס הנתונים של MySQL על ידי העתקת הקבצים, במיוחד אם השרת רץ (והוא רץ כל הזמן), כדי לא לתפוס קבצים תוך כדי שהם נכתבים (מה שיגרום לגיבוי של בסיס הנתונים להיות דפוק). גיבוי MYSQL
אני משתמש בסקריפט הזה, שמגבה את אל בסיסי הנתונים אל /var/backups/mysql, ויוצר מבנה ספריות דומה לזה:
כמובן שהספריות האלו מגובות אוטומטית במסגרת הגיבוי של מערכת הקבצים.
כדי להשתמש בסקריפט, יש לשים אותו ב/etc/cron.daily ולערוך אותו ככה ששם המשתמש והסיסמא יהיו אלו של משתמש שמורשה לגשת לכל בסיס הנתונים. לא לשכוח לשנות את ההרשאות של הקובץ ככה שרק root יוכל לקרוא אותו.
כדי לחסום את הנפח שהגיבויים האלו תופסים, ניצור בcron.weekly סקריפט שמוחק גיבויי mysql ישנים מ60 יום:
לשם הבטיחות, כדאי לגבות למחשב אחר, למשל זה שבבית, ככה שגם אם מתרסק הדיסק של השרת, השחזור יהיה אפשרי.
לשם הנוחות, כדאי לגבות גם לספריה מקומית את כל השרת, ככה שגם אם מחקתם קובץ גדול, לא תצטרכו להעלות אותו מהגיבוי המרוחק.
הPreprocessror שפיתחתי במסגרת העבודה של בVollee, שנכלל בפרוייקט הקוד הפתוח אנטנה (פרוייקט שעוזר בפיתוח ובבניה של ישומי ג’אווה למכשירים סלולריים), אושר על ידי Eclipse Legal, ויכלל בMTJ. MTJ הוא פרוייקט Eclipse רשמי שמטרתו להוסיף לEclipse תמיכה בפיתוח ישומי ג’אווה למכשירים סלולריים. כבר היום יש את EclipseME, פלאגין שפותח במשך שנים על ידי קרייג סטרה, שעושה את אותה עבודה - למעשה וקרייג עובד עם צוות MTJ, וMTJ מיועד להיות תחליף רשמי של EclipseME.
תהליך הקליטה של הPreprocessor לא היה קל:
הקוד המקורי הסתמך על ANTLR 2.7 (שמייצר אוטומטית קוד לפענוח קוד לפי הגדרה פורמלית - Parser generator) - הבעיה עם ANTLR 2.7 היתה שהרשיון שלו לא תאם את הרשיון של Eclipse (מסתבר שPublic domain זה לא תמיד טוב מספיק). למרבה המזל, ANTLR 3.0 כבר שוחרר ברשיון BSD שתאם את הרשיון של Eclipse, אבל הוא לא תאם את הקוד של הPreprocessor.
החב’רה בMTJ שאלו אם אני מוכן להמיר את הקוד כך שישתמש בANTLR 3.0: בינתיים עזבתי את Vollee ואת כל העולם של הפיתוח לסלולריים (בשעה טובה ומוצלחת) אז סירבתי, אבל אמרתי שאשמח לייעץ להם ולעזור מרחוק.
הם הרימו את הכפפה, וכמעט בלי עזרה מפתח אחד - דייגו סנדין - המיר את העסק לANTLR 3.0 תוך כשבועיים.
הזמן עבר, ולפני חודשיים צוות MTJ קיבל אישור למסור לי את הקוד, כדי שאקלוט אותו לתוך Antenna.
מכיוון שהקוד כלל בדיקות יחידה מקיפות, שדייגו הקפיד להשתמש בהן כדי לבדוק את ההמרה - התוצאה היתה טובה מאוד.
עוז זמן עבר, והיום הקוד קיבל אישור מEclipse Legal ויכנס לענף הראשי של MTJ.
כשכותבים בדיקת יחידה (Unit test) לקוד שקשור לבסיס נתונים, צריך לאתחל את בסיס הנתונים לאיזה שהוא מצב ידוע ויציב לפני כל בדיקה.
מול MySQL, אפשר להשתמש בmysql עצמו כדי ליבא סקריפט SQL מוכן, אבל זה לא נחמד במיוחד:
צריך לפתוח תהליך חדש, ויש כל מני בעיות מעצבנות עם זה (בג’אווה למשל, חובה לקרוא את הפלט של התהליך, אחרת הוא יתקע בכתיבה לפלט הסטנדרטי כשיתמלא הבאפר).
הרבה יותר נחמד יהיה ליבא את הקובץ ישירות מתוך ג’אווה, בשימוש בJDBC, לא?
הנה קוד שעושה בדיוק את זה, הוא מקבל זרם קלט (InputStream) שיכול להיות כל דבר, וגם Connection JDBC שחיברתם מבעוד מועד, וקולט את הSQL לתוך בסיס הנתונים.
הקוד מתמודד עם הפלט הסטנדרטי של mysqldump.
publicstaticvoidimportSQL(Connection conn, InputStream in) throws SQLException {
Scanner s = new Scanner(in);
s.useDelimiter(“(;(\r)?\n)|(–\n)”); Statement st = null; try {
st = conn.createStatement(); while(s.hasNext()) { String line = s.next(); if(line.startsWith(“/*!”) && line.endsWith(“*/”)) { int i = line.indexOf(‘ ‘);
line = line.substring(i + 1, line.length() - ” */”.length()); }
שוחררה הגרסא האחרונה (ככל הנראה) בענף של PHP 4.4.
הגרסא הזו מסמנת את סוף התמיכה הרשמית בPHP4.
PHP5 כבר בחוץ במשך יותר משלוש שנים, אבל עד עכשיו האימוץ שלו היה די איטי, מסיבות של ביצה ודינוזאור:
מפתחי התוכנות לא רצו להפסיק לתמוך בPHP4 כדי לא לאבד משתמשים. חברות אירוח האתרים לא טרחו לשדרג כי כל התוכנות החשובות תמכו גם ככה בPHP4 והמשתמשים, מה איכפת להם?
בשנה שעברה נפתח אתר gophp5.org, ששם לעצמו למטרה לדחוף את האימוץ של PHP5.
הרעיון הוא שאם מסה מספיק גדולה של פרוייקטים תעבור לPHP5, ומסה מספיק גדולה של חברות אירוח תעבור לPHP5, לשאר חברות האירוח לא תהיה ברירה והן תאלצנה לשדרג או לאבד משתמשים, ואז לשאר הפרוייקטים לא תהיה סיבה להשאר בPHP4 והם יוכלו להתחיל סוף סוף לנצל את היכולות של PHP5.
בפברואר 2008 כבר היו מעל 100 פרוייקטי תוכנה שהתחייבו להפסיק לדאוג לתמיכה בPHP4 (זה לא אומר שהם ילכו וישברו את התמיכה בPHP4 בכוונה, פשוט שהם יפסיקו לדאוג שקוד חדש ירוץ בPHP4), ומעל 200 חברות איכסון שתומכות בPHP 5.2 כביררת מחדל וgophp5 טענו להצלחה והפסיקו לאסוף הרשמות.
אז למה לא לתמוך בPHP4? הנה דוגמא מאתמול: JSON הוא דרך להעביר מבנה נתונים כלשהו לייצוג של מבנה הנתונים כאובייקט ג’אווה סקריפט, והוא אחת הדרכים הפשוטות והיעילות ביותר להעביר נתונים מקוד בצד השרת לדפדפן (שפשוט מפעיל על הטקסט שחוזר את המפסק (parser) של ג’אווה סקריפט כדי לקבל אובייקט מוכן לשימוש.
למרות שראשי התיבות של AJAX הן Asynchronous Javascript And XML, מעולם לא השתמשתי בAJAX כדי להעביר XML, למעשה אני מוצא את הרעיון מזעזע. הרבה יותר קל להעביר JSON, או אפילו קוד HTML ממש.
JSON משמש בהרבה מאוד פרוייקטים מבוססי AJAX, ומכיוון שאין בPHP4 תמיכה מובנית בJSON (אחרי הכל, PHP4 הוא בן שמונה, וJSON הוא די חדש בשכונה) צריך להשתמש בספריות חיצוניות שיודעות להעביר אובייקט PHP לפורמט JSON, אחת הספריות הנפוצות היא Services_JSON (למעשה אני משתמש בספריה הזו בFireStats).
הספריה כתובה בPHP, ולמרות שהיא עובדת נכון, היא לא ממש עובדת מהר, במיוחד כשממירים מבני נתונים גדולים (לא עצומים, משהו בסדר גודל של מערך עם 1000 אובייקטים טיפה מורכבים) לJSON.
ממש אתמול ניסיתי לשפר ביצועים של ישום PHP, אחרי חפירות גיליתי שאחד הדברים שמאטים מאוד את העסק היה המרה של תשובה לדפדפן לJSON בשימוש בServices_JSON, כשאני אומר איטי, אני מתכוון ל8 שניות.
שמונה שניות שהשרת טוחן את הCPU שלו כדי להכין תשובה ללקוח (במקרה הספציפי הזה, במקרים אחרים עם יותר נתונים זה כמובן יותר גרוע).
ברגע שראיתי את זה, לקח לי בדיוק שניה וחצי להיזכר שPHP5 תומך בJSON. בדיקה מהירה בphp.net הניבה את שתי הפונקציות הפשוטות json_encode וjson_decode. החלפתי את השימוש ב Services_JSON בקריאה לפונקציות של php5, ולא הייתי מופתע במיוחד לראות שהמרה של אותו מבנה נתונים לוקחת פתאום 40 מילישניות.
שיפור של פי 200, בזמן עבודה של כמה שניות (טוב, חוץ מלמצוא את הבעיה )
השיפור נובע מכך שהתמיכה של PHP בJSON לא כתובה בPHP אלא בC, ולכן היא הרבה הרבה יותר יעילה.
השיפור הזה התאפשר רק כי הפרוייקט הספציפי הזה לא צריך לתמוך בPHP4.
מה אני אצטרך לעשות בFireStats, שעדיין תומך בPHP4 כדי להנות מהשיפור הזה? לבדוק אם אני על PHP5, ואם כן להשתמש בפונקציות האלו אחרת להשתמש בServices_JSON. לא כיף במיוחד.
ואם לא היתה לי סיפריה כמו Services_JSON (כי אין, או כי תנאי הרשיון לא מתאימים לי), הייתי נאלץ לכתוב אחת או פשוט לעבוד בצורה אחרת, פחות נוחה. גם לא כיף.
אז איך מתקדם האימוץ של PHP5?
החל מFireStats 1.3 ששחרתי לפני יותר משנה, FireStats מכילה רכיב ששולח (באישור המשתמש) מידע מערכת אנונימי. חלק מהמידע הוא גרסאות הPHP והMySQL.
הכוונה היא שאני אוכל להשתמש במידע הזה כדי להחליט בצורה יותר מושכלת במה אני צריך לתמוך.
המידע הצטבר לי בבסיס הנתונים, ונכון לכרגע יש לי מידע על כמעט 12000 התקנות. מה שאומר כמעט 12000 שרתים בעולים (אני מתעלם ממקרים של כמה התקנות על אותו שרת).
למי שתוהה, זה לא אומר שFireStats הותקנה 12000 פעמים, אלא ש12000 פעמים המתקינים הסכימו לשלוח מידע מערכת אנונימי.
מי שרוצה את המידע הגולמי מוזמן לקחת אותם מפה (יצוא MSQL, כ5 מגה דחוסים, 65 מגה פרושים).
אז ישבתי כמה שעות כדי להוציא מהנתונים הגולמיים שני גרפים נחמדים:
הראשון הוא אחוזי ההתקנות של PHP 4 מול PHP 5, במהלך השנה האחרונה.
למרות שאחוזי ההתקנה של PHP4 ירדו במהלך השנה האחרונה מ52% ל38%, עדיין מי אי אפשר להתעלם ממנו. נקווה שהוא ימות סופית בקרוב:
השני הוא אחוזי ההתקנות של הגרסאות המשמעותיות של MYSQL:
כיף לראות שMYSQL 5.0 שולט בשוק, אבל נראה שMYSQL 4.0 הזוועתי נתקע על 7% ולא רוצה למות.
בכל מקרה, MYSQL 4.0 הוא בהחלט מועמד לנטישה, וכבר היום יש לא מעט תכונות חשובות של FireStats שלא נתמכות בגרסא הזו.
on 
on 
רסיסים (RSS)