הידעתם? ( ככה מספרים לנו) הידעתם כי מאחורי בסיס הנתונים שלנו עומדים 3 בסיסי נתונים מרופלקים מבסיס הנתונים שלנו? המטרה לבטח את ההבטחה של מיקרוסופט ל 99.9% של נגישות וזמינות (availability – נשמע יותר יפה באנגלית הא?) לבסיס הנתונים שלנו (גם פה יש המון המון חומר ברשת והרחבות טכניות וכלליות – אני מביא רק תקציר של התקציר כדי לתת ידע בסיסי – מי שרוצה יותר פרטים יכול לפנות אליי או לקרוא לבד...)
רפליקציה אחת נקראת primary והאחרות נקראות secondary, איך זה עובד? ה קריאות והכתיבות מרופלקים לבסיס הראשי ובצורה א-סינכרונית אז זה עובר ל 2 האחרים המשניים, במידה ורפליקציה אחת נופלת – מייד מתרוממת אחת חליפית הנקראית - 'reconfiguration' .
היכן שוכנות רפליקציות אלו? הן שוכנות בסרברים פיזיים (לא וירטואליים) אחרים, למה זה ככה? נאמר ייפול השרת שבו יושב בסיס הנתונים המרופלק הקרוי primary, מיד יש 2 אחרים בשרתים חיים אחרים (לדעתם הסבירות שייפלו 3 זו סבירות נמוכה מאד).
בארכיטקטורה כזו מתי נחשב מידע כ committed ב SQL Azure שלנו בבסיס הנתונים שלנו? הארכיטקטורה שלהם קבעה כי מידע נחשב כ committed רק אחרי שרופלק (ה transaction log דיווח כי המידע נכתב לדיסק) ל primary ולפחות לאחד ה secondary.
כשיש נפילה ב ב SQL Server רגיל ה DBA אחראי להרמה ואחראי גם במשך היום יום לוודא שזה עובד, פה הם אחראים לזה וטענתם היא כי זו הארכיטקטורה עצמה. ואין צורך לדאוג לניהול פיסי של בסיס הנתונים.
מה קורה כאשר primary נופל?
מה קורה כאשרsecondary נופל?... מיד מוצא לו בסיס נתונים חליפי לרפליקציה.
Comments
Post a Comment