שלום לכולם
לאחרונה היתווסף טאב חדש תחת SQLDatabase בפורטל של AZURE.
הטאב קרוי: CONFIGURE
- בפוסט זה אסקור את מה התפקיד שלו ולמה סוף סוף נהיה רגועים לפני DEPLOY.
אז ככה - אחת הבעיות הגדולות שהיו לנו כמנהלי בסיס נתונים ב SQL Database הייתה סוג של גיבוי לפני ביצוע שינויים או סתם גיבוי רגיל.
כן אני מכיר את ה COPY - בטח שאני מכיר כתבתי על זה פוסט אי שם ב 2011 אבל יקר - SQL Database כל כך יקר ואני לא רוצה לשלם סתם.
כן - לעשות את זה כ HDV בבלוב שמקושר ל VM - זה באמת אחלה - ואכתוב על זה בפוסט הבא - אבל שוב לשחזר ממנו זה לא הכי נוח.
אז הוחלט ב AZURE להתחשב בנו ויצרו את הפונקציה CONFIGURE
הקונספט הוא פשוט - יוגדר תהליך קבוע - או לא קבוע שישמור את בסיס הנתונים ל Azure storage - כיצד זה מתבצע? לבסיס הנתונים נוצר עותק, אחרי כן הוא מועבר ל blob, ויושב לו שם בנחת עד שמחליטים לשחזר ממנו.
פשוט וקל.
תיאור התהליך
אפשרות ללחוץ ברמת DB, ואז יש 2 אפשרויות או NONE ואז לא עולה כלום על המסך.
- כאשר בוחרים ב CONFIGURE עולה מסך שמגדיר לאן בסיס הנתונים יישמר לאיזה BLOB Storage הוא יועבר.
יפה - בשעה שניקבע אנו ניראה לפתע שבסיס נתונים חדש נוצר
כאן הבעיה הראשונה - אם בסיס הנתונים גדול זה יכול לקחת שעות על שעות - מצד שני תנו ל Azure לעבוד.
לאחר מכן בצורה אוטמטית נוצר קונטיינר חדש תחת azure storage שיכיל את הקובץ של גיבוי בסיס הנתונים:
ואם ניכנס פנימה נראה את הקובץ עצמו
או אם ניכנס ל vs2012 נראה את הקובץ זה קובץ bacpac רגיל שאפשר למשוך אותו ולבנות ממנו בסיס נתונים כולל data.
השלב הבא יהיה ללכת ולראות לוג של הגיוביים וכדומה ופה תחת sqldatabase טאב servers יש כפתור history
לוחצים עליו - ממלאים ססמא:
ונכנסים ללוג עצמו של הגיבויים:
והנה רואים פרטים של מה ומתי קרה.
נשאר רק לשחזר מתוך זה... והנה הכפתור לשחזר:
לוחצים על new database עולה מסך קטן - ממלאים פרטים והעבודה מתחילה - יש לשים לב להגדיר לו storage לפחות כמו שהיה לו קודם.
זהו - זה התהליך
יתרונות - נותן גמישות שלא הייתה עד כה לשחק עם בסיס הנתונים ובעלות נמוכה.
חסרונות - בסיסי נתונים גדולים - התהליך נתקע. בבסיס נתונים של 100gb לא הצלחתי לסיים את התהליך.
ערב טוב
