30-08-2011, 08:55
|
|
מנהל פורומי "תכנות ובניית אתרים" ו"חומרה ורשתות"
|
|
חבר מתאריך: 25.10.01
הודעות: 42,775
|
|
http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html
אם אתה חייב לשמור על consistency בין המידע שבטבלאות, כך ששחזור מלא יחזיר את כל הנתונים לנקודה מדוייקת ואחידה בזמן, אתה חייב לנעול את כל הטבלאות בזמן הגיבוי, עם הפרמטר lock-all-tables--. כמובן שבזמן זה הכל יהיה תקוע, ואם זה מסד נתונים גדול, זה בעייתי. אחד הפתרונות כדי שזה לא יהיה בעייתי, זה לעבוד בקונפיגורציית master/slave, ולעשות את הנעילה והגיבוי מה slave, ואז ה master לא מושפע.
הסיבה לכך היא ש mysqldump מגבה טבלה-טבלה בנפרד, ולגבות כל טבלה לוקח זמן. בזמן הזה, יכולים להתבצע שינויים בטבלאות אחרות, ובהחלט ייתכן שאחרי שסיימת לגבות טבלה אחת, יתווספו אליה נתונים, ואחרי זה יתווספו נתונים המתייחסים לנתונים האלה שהתווספו בטבלאות אחרות, ואז כשתהליך הגיבוי יגיע אל הטבלאות האחרות האלה, הוא יגבה אותן עם התייחסות למידע בטבלה - שלא גובה (כי הוא נכתב אחרי שכבר גיבית את הטבלה, אך לפני שגיבית את הטבלה שלתוכה נכנס המידע החדש ובהתאמה אליו מידע אל הטבלה שכבר גובתה) - ואז בשחזור יהיה לך inconsistency... והשאלה היא אם מדובר במשהו מהותי מבחינה אפליקטיבית - מבחינת המידע שילך לאיבוד, והאם האפליקציה תוכל להתמודד איתו, במידה ותצטרך לבצע שחזור שכזה (במערכות אמינות מבחינה חומרתית, עם מערכת הפעלה אמינה כגון לינוקס, הרבה פעמים יצא לך לא לנצל את הגיבוי אף פעם - אפילו אם המערכת רצה... שנים. לפחות ככה זה אצלי. עדיין, כמובן, אני עושה גיבויים, אבל שחזור אמור להיות רק במקרי אסון, ואלה אמורים להיות נדירים....)
כמובן שיש אפשרויות אחרות, של גיבויים ברמת snapshot למערכת הקבצים (לדוגמא LVM על גבי לינוקס) - גיבוי שיקפיא את מסד הנתונים ל... שנייה אחת בערך, אבל אנחנו מתחילים לדבר פה על עניינים "רציניים" יותר ממה שאתה מתעסק בו, ככל הנראה... 
|
ראשי
צ'אט
מצב כלאיים
