עוד פעם בעיות עם MySQL

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

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

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

כאן מתחילה הבעיה. ניסיתי לשחזר את טבלאות של MySQL, ולמזלי עשיתי גיבוי ב3 רמות:

  1. ספריית ‎/var/lig/mysql
  2. שמירת SQL Dump
  3. שמירה של קבצי migration בכל מה שקשור לפרוייקט ב ror שאני בונה.

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

show tables;

הליכה זריזה לספרייה הראתה שקיימים רק קבצי frm. הדבר הבא שעשיתי זה בדיקה של הקבצים שגיביתי, וגיליתי שבאמת היו בספרייה רק קבצי frm (ואיך לעזאזל הוא עבד עד אז ?!).

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

השלב הבא היה ללכת ל SQL Dump שלי אחרי שעשיתי drop database למסד נתונים. הבעיה היא, שה sql dump הוא יחסית ישן, כי בזמן הפיתוח שניתי כבר את המסד נתונים, אבל לא עשיתי dump חדש (לא חשבתי שאגיע למצב שאהיה צריך עוד פעם), ואז rails נכנס לפעולה על ידי שימוש של

rake db:migrate

וכן גם כתיבה של

rake db:sessions:create

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

אם לא היה לי כלי כדוגמת migrate של ror, אני לא בטוח מה הייתי עושה.

אני גם לא מבין למה ואיך MySQL הצליח לעבוד במכונה הקודמת רק עם קבצי frm, ולאן נעלמו הקבצים האחרים.

אז נכון ש MySQL מאוד נוח ביצירת שאילתות, אבל אם הוא לא אמין  (שוב פעם בעית אמינות שאני חווה אותה), למה לעזאזל משתמשים בו בשביל לשמור מידע ?!

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

14 תגובות על עוד פעם בעיות עם MySQL

  1. yhager הגיב:

    הדרך לגבות היא באמצעות dump – אם היה לך dump מתאים, לא היתה שום בעיה. מכאן ועד להשמיץ את mysql רחוקה הדרך.

  2. ik_5 הגיב:

    זהו שלא ! השימוש ב sql dump בשביל גיבוי ב mysql זה hack שהשתרש בגלל הבעיות של השיטה המקורית.

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

    מה סתם להשמיץ ? יש ל mysql כלי לגיבוי ושיחזור שלא עובד, והוא כל כך "טוב" שהדרך שהשתרשה (דרך רעה ד"א) זה לעשות dump של המסד נתונים לשאילתת sql.

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

    אז להתלונן על עבודה לא אמינה עם המידע שלי נחשב לסתם השמצות, אז אני משמיץ.

  3. elcuco הגיב:

    עידו… אני בספק רב…

    באמת מובטח לך שהתסדיר הבינארי של בסיסי הנתונים לא ישתנו בין תתי גרסאות? בין מערכות הפעלה? עד כמה שאני יודע, ה־sql הנוצר מה־dump אמור להיות תואם "תמיד"…

    תגיד, חוץ מבטלנות, יש סיבה בגללה אין לך cron ששומר את כל סביבת העבודה שלך? אצלי בעבודה יש אחד כזה שמגבה פעם ביום את כל ה־db, את svn את trac ועוד כמה תסריטים שונים לצורך שיחזור (והתסריטים הללו נמצאים גם ככה ב־svn!). אחרי זה המידע מסתנכרן לאתר חיצוני – שם יש גיבוי במיקרה שיש שריפה במשרד.

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

  4. ik_5 הגיב:

    העניין הוא שהמסד נתונים צריך לדעת כיצד להמיר בין גרסאות בינאריות.
    dump של sql נבנה במקור (עזוב כרגע את mysql) בשביל להבטיח לך המרה של טבלאות בין מסדי נתונים שונים לגמרי, ולא כאמצעי גיבוי.
    mysqldump נבנה במקור בכלל ככלי צד שלישי ולא של mysql בדיוק לשם כך.

    ד"א למעט pg שאומר לך במפורש שהדרך לגבות אצלו זה dump, אתה אמור להשתמש בכל מנוע מסד נתונים להשתמש בכלים שלו. ב firebird/interbase יש לי את
    gbak שנועד לא רק לגבות אלא גם להמיר בין גרסאות של מסד נתונים. קרה לי עם sql dump של interbase שלא היה אפשר לייבא אותו חזרה בגלל שהוא הכיל מידע בינארי של blob. איך אתה מתמודד עם בעיה כזו עם sql dump בלי קשר למסד נתןנים ?

    בקשר לגיבויים, המכונת פיתוח שלי היא גם המכונת שולחן עבודה שלי (לצערי), ובנוסף לזה כמובן שאין אף פעם סבלנות לסדר תסריט מסויים, אבל כל הפרוייקט שאני עושה נשמר בגיט, ועכשיו כולל הdump של המסד נתונים. (אני עושה את זה דרך rake db:schema:dump

  5. elcuco הגיב:

    האמת? גם אני חשבתי לשמור את הבסיס נתונים בתור חלק מה־svn… אולי עבור פרויקטים ב"סוף מחזור הפיתוח". נראה.

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

  6. Vedder הגיב:

    הדרך הנכונה (והמומלצת ע"י MySQL) היא להשתמש בכלי mysqlhotcopy

    http://dev.mysql.com/doc/refman/5.0/en/mysqlhotcopy.html

  7. גורו יאיא הגיב:

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

  8. yhager הגיב:

    לא ידעתי ש rails עובד עם innoDB. מתוך התיעוד של MySQL:
    "
    You can also create a binary backup simply by copying all table files (*.frm, *.MYD, and *.MYI files), as long as the server isn't updating anything…. (But note that these methods do not work if your database contains InnoDB tables. InnoDB does not necessarily store table contents in database directories…)…
    For InnoDB tables, it is possible to perform an online backup that takes no locks on tables; see Section 4.5.4, “mysqldump — A Database Backup Program”.
    "

  9. Vedder הגיב:

    מעניין שהתגובה שכתבתי נעלמה … אז אכתוב אותה שוב.

    הדרך הממולצת (ע"י MySQL) לגיבוי מסדי נתונים היא בעזרת הסקריפט mysqlhotcopy

    http://dev.mysql.com/doc/refman/5.0/en/mysqlhotcopy.html

  10. אורי הגיב:

    MYD ו-MYI נמצאים בשימוש רק במנוע MyISAM. במנוע InnoDB בתצורתו הרגילה (מבלי להשתמש ב-file per table או איך שזה נקרא..) כל בסיס הנתונים נמצא בספרית המידע עצמה בתוך קבצי ibdata, בפורמט שמזכיר קצת את FB שאתה מכיר לטובה (ואני, לרעה).

  11. דוד הגיב:

    כאשר אתה משתמש ב- innodb, ברירת המחדל היא ליצור קובץ אחד בשם ibdata שמכיל את כל המידע ולעולם לא קטן. דרך עדיפה היא לבצע את השינויים הבאים ב- my.cnf: למחוק את innodb_data_file_path ולהוסיף שורה עם הפרמטר innodb_file_per_table=1
    אז תוכל לראות לצד כל קובץ frm גם קובץ ibd שמכיל את המידע.

    חוץ מזה, תמיד עדיף להשתמש בכלים ששייכים למסד הנתונים – mysqldump וה- incremental logs.

  12. ik_5 הגיב:

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

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

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

  13. אורן הגיב:

    לא ברור לי למה אתה טוען ש- mysqldump זה HACK.
    גם בעולם האורקל יש כמה צורות גיבוי, כאשר אחת מהן היא "לוגית" ונקראת EXPORT,
    שזה פשוט לשפוך את המידע בצורת SQL.

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

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

  14. Shlomi Noach הגיב:

    היי,
    כפי שכתבו ככל הנראה השתמשת בטבלאות InnoDB – וזה מצוין.
    אבל אז צריך גם לדעת מה לגבות ואיך. למשל, לא ניתן לגבות ע"י העתקה של קבצי ה-ibdata בזמן שהשרת רץ.
    לעומת זאת, מומלץ להריץ mysqldump –single-transaction בכדי להפעיל גיבוי שאינו מצריך הורדה של השרת ואינו שם נעילות (!) בזמן הגיבוי,
    או להשתמש ב-InnoHotBackup
    והרשימה עוד ארוכה.

    לממליץ על mysqlhotbackup – תופס רק לטבלאות MyISAM ומייצר נעילות בזמן הריצה – ולא מאוד מומלץ.

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

    בהצלחה

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s