בגרסה החדשה של אורקל (12c) נעשו כמה שינויים מעניינים במנגנון הותיק של ה-data guard. אחד הפיצ'רים שנוספו למנגנון הוא ה-FarSync – מנגנון שבא לעזור למערכות להעלות את רמת ההגנה שיש על המידע (Zero-Data-Loss) מבלי להשפיע על זמני התגובה של המערכת.

רמות ההגנה של dataguard

כדי להסביר את התכונה החדשה הזו, נעשה שיעור קצר בעולם ה-Data Guard וה-Protection modes שלו.

לאורקל Data Guard יש 3 רמות שונות של הגנה:

1.       Maximum Performance – מידע ה-Redo עובר (הן מה-redo logs או מ-archive logs) באיזושהי נקודת זמן. זה יכול לקרות ברגע של ה-commit אבל זה יכול לקרות במועד מאוחר יותר, לדוגמה אם אין רשת בין בסיסי הנתונים באותו הזמן.
   מבחינת ביצועים – העובדה שהמידע עובר בצורה א-סינכרונית מאפשר ביצועים מקסימליים (שהרי ביצוע ה-archiving מתבצע בכל מקרה) אבל מבחינת הגנה על המידע, מדובר בהגנה מינימלית ביותר כי לא מובטח לנו שהמידע יגיע אל ה-standby.
2.       Maximum Availability – ברמה הזו כבר יש לנו הגנה יותר רצינית: כאשר נכתבת טרנזאקציה באופן סדיר, היא לא תבצע commit עד שהמידע יגיע לקבצי ה-redo log והמידע ישלח ל-standby ויעשה אחת משתי הפעולות הבאות:
   1.        הטרנזאקציה תרשם לקבצי ה-standby redo logsשל סביבת standby אחת לפחות ויחזיר אישור (acknowledgment) שזה בוצע (affirm)
   2.       תתחיל כתיבה של הטרנזאקציה לקבצי ה-standby redo logs של סביבת standby אחת לפחות ויחזור אישור שהכתיבה התחילה (noaffirm). ברור כמובן שהאופציה הזו יותר מהירה אבל קצת פחות בטוחה.

   כאשר ה-primary לא מקבל אישור מה-standby הוא הופך לעבוד במצב של maximum performance.

   הרעיון פה הוא שכל עוד יש קשר בין השרתים כל טרנזאקציה שנכתבת לבסיס הנתונים מוגנת ויש לנו Zero Data Loss במקרה של קריסה של בסיס הנתונים הראשי. במידה ויש double fault אז אין הגנה.

3.       Maximum Performance – הפתרון הזה מאוד דומה לפתרון של Maximum Availability אבל ברמה הזו יש לנו הגנה מקסימלית: כל טרנזאקציה לא מסתיימת עד שהיא לא נרשמת בלפחות אחד מה-standby-ים האחרים ואם לא מגיע ack תוך זמן מסוים, בסיס הנתונים יורד כדי להגן על המידע (ה-Primary!). מסיבה זו לא מומלץ שבסביבה כזו יהיו פחות מ-3 בסיסי נתונים.

אוקיי, אז הבנו איזה רמות הגנה ניתן לתת לנתונים שלנו – אז איפה הבעיה?

מה הבעיה?

הבעיה מתחילה כשאנחנו עובדים בין שני אתרים מרוחקים מאוד ביניהם ורוצים להבטיח Zero Data Loss בין בסיסי הנתונים שלנו. כאשר אנחנו שמים שני בסיסי נתונים בשני צדדי האוקיינוס אנחנו מעלים מאוד את ה-latency של הרשת ופוגעים מאוד בביצועים של ה-commit. אנחנו רוצים מצד אחד שהביצועים לא יפגעו יתר על המידה למרות המרחק בין האתרים ומצד שני אנחנו רוצים הגנה על המידע.

עד גרסה 12, הפתרון היה לבנות פתרון המבוסס Maximum Availability ושלושה בסיסי נתונים: primary, standby קרוב ו-standby  מרוחק. הרעיון היה שה-primary יקבל אישור על הכתיבה המוגנת מבסיס הנתונים הקרוב ואז יעביר את המידע גם לבסיס הנתונים המרוחק בצורה א-סינכרונית. הפתרון הזה עבד ועבד טוב אבל ככל שבסיס הנתונים היה גדול יותר הדבר דרש יותר משאבים: שרת נוסף, דיסקים נוספים, רישיונות נוספים וכן הלאה.

Far Sync Instance

החל מגרסה 12c ישנו סוג נוסף של Instance שבא לעזור לנו לפתור את הבעיה: Far Sync Instance – מעין חיית ביניים שבין Standby ובין instance דמה. מדובר ב-instance שכל תפקידו הוא הוא להיות מתווך בין ה-primary לבין ה-standby-ים שלו.

כאשר ה-primary כותב טרנזאקציה, הוא יעביר את המידע redo ל-instance הזה והמידע ירשם בתוך standby redo logs. ברור שאנחנו צריכים שה-standby redo logs האלה לא יהיו באותו מקום כמו ה-primary כי זו בעצם הרמה הראשונה של ההגנה על המידע שלנו. לאחר מכן ה-Instance הזה כבר ידאג להעביר את המידע לבסיסי הנתונים המרוחקים מבלי להשפיע על הביצועים של השרת הראשי (בצורה א-סינכרונית) ומבלי לבזבז את משאבים מיותרים (שרת, זיכרון, מקום בדיסק או רישיון). ה-instance הזה יכיל control file, standby redo logs ו… זהו בעצם. שום מידע של המשתמשים לא ירשם אצלו והוא לא יהיה סביבה תקינה כדי לעשות עליה failover.

כאשר בסיס הנתונים הראשי נופל, ה-standby וה-Far Sync ידאגו לסנכרן ביניהם את קבצי ה-redo log שעדיין לא עברו לאתר המרוחק ואנחנו נקבל Zero Data Loss בשרת בצד השני של האוקיינוס.

הפתרון הזה הוא פתרון נהדר למי שהשתמש בפתרון הקודם (של שלושה בסיסי נתונים) והוא מאפשר לנו במחיר של רישיון Active Data Guard לבצע את מה שעשינו קודם עם רישיון enterprise מיותר. עוד דבר נחמד ש-Far Sync יודע לבצע זה Compression של ה-Archive-ים לפני שהוא מעביר אותם לאתר המרוחק (דורש רישיון של Advanced Compression).

דברים שכדאי לשים לב אליהם, גם בפתרון הזה:

1.       לא כדאי לשים את ה-Far Sync באותו שרת או על אותם הדיסקים כמו ה-primary – בכך נאבד לחלוטין את רמת ההגנה שלנו.
2.       כדאי גם לא לשים את ה-Far Sync באתר מרוחק מאוד (הטווח המקסימלי של Sync בלי בעיות latency יכול לנוע בין 50-200 קילומטר בערך, תלוי בטכנולוגיה).
3.       ההגנה שלנו היא יחסית לשרת ה-Far Sync – זאת אומרת שהם הוא לא זמין אנחנו נמצאים במצב של Maximum Performance ואם אין קשר בינו לבין ה-Standby האמיתי אז לא יהיה לנו Zero Data Loss בשרת המרוחק עד שזה יפתר (כי לא יהיה סינכרון של הטנזאקציה האחרונה לשם).

בפעם אחרת אני אתן Step-by-Step לאיך יוצרים כזו סביבה.