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

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

פתרון HA מבוסס על VIP

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

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

שכפול מבוצע במצב חצי סינכרוני מבוסס על GTID. המשמעות היא שלפחות עותק אחד חייב לרשום עסקה לפני שהיא תיחשב מוצלחת. מצב שכפול זה מספק איזון אופטימלי בין ביצועים ובטיחות נתונים במקרה של כשל בצומת מאסטר. בעצם כל השינויים מועברים מהמאסטר לעותקים העתקים באמצעות Row Based Replication (RBR), אך ייתכן שיש צמתים מסוימים mixed binlog format.

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

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

מה שאתה צריך לדעת על הפתרון הזה לפני שמתקדמים קדימה:

VIP היא כתובת IP שאינה משויכת לממשק רשת פיזי ספציפי. אם צומת נכשל או במהלך תחזוקה מתוזמנת, נוכל להעביר את ה-VIP למשאב אחר עם זמן השבתה מינימלי.
שחרור והנפקת כתובת IP וירטואלית היא פעולה זולה ומהירה.
כדי לעבוד עם VIP, אתה צריך גישה לשרת באמצעות SSH, או שימוש בכלי שירות מיוחדים, למשל, keepalived.

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

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

המתזמר מעדכן את טופולוגיית האשכולות, כל העתק מדווח שהמאסטר אינו זמין. המתזמר מתחיל בתהליך בחירת העתק המתאים לתפקיד המאסטר החדש ומתחיל התאוששות.
אנחנו מנסים להסיר את ה-VIP מהמאסטר הישן - ללא הצלחה.
העתק עובר לתפקיד המאסטר. הטופולוגיה נבנית מחדש.
הוספת ממשק רשת חדש עם VIP. מכיוון שלא ניתן היה להסיר את ה-VIP, אנו מתחילים לשלוח בקשה מעת לעת ברקע ARP ללא תשלום. סוג זה של בקשה/תשובה מאפשר לך לעדכן את טבלת מיפוי כתובות ה-IP וה-MAC במתגים המחוברים, ובכך להודיע לך שה-VIP שלנו עבר. זה ממזער את הסבירות split brain כאשר מחזירים את המאסטר הישן.
כל החיבורים החדשים מנותבים מיד למאסטר החדש. חיבורים ישנים נכשלים וקריאות חוזרות למסד הנתונים מתבצעות ברמת האפליקציה.

השרת פועל במצב רגיל, אירעה כשל ברמת DBMS

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

בעיות אחרות

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

ממשק רשת וירטואלי מתווסף תמיד באופן זמני, כלומר, לאחר אתחול מחדש של השרת, ה-VIP לא מוקצה אוטומטית. כל מופע מסד נתונים מתחיל במצב קריאה בלבד כברירת מחדל, המתזמר מחליף אוטומטית את המאסטר החדש לכתוב ומנסה להתקין read only על המאסטר הזקן. פעולות אלו מכוונות לצמצם את הסבירות split brain.

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

התרשים הכללי של פתרון HA מוצג להלן.

בחירת מאסטר חדש

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

העתק משתרך מאחורי המאסטר;
גרסת MySQL של מאסטר והעתק;
סוג שכפול (RBR, SBR או מעורב);
מיקום במרכזי נתונים זהים או שונים;
הזמינות errant GTID - עסקאות שבוצעו על העתק ואינן על המאסטר;
גם כללי בחירה מותאמים אישית נלקחים בחשבון.

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

זמן תגובה וזמן החלמה

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

slave_net_timeout - מספר השניות שבמהלכן העתק ממתין לנתונים חדשים או אות פעימות לב שיגיעו מהמאסטר לפני שהחיבור יזוהה כאבד ומתחבר מחדש. ככל שהערך נמוך יותר, כך ההעתק יכול לקבוע מהר יותר שהתקשורת עם המאסטר נשברת. הגדרנו את הערך הזה ל-5 שניות.
MASTER_CONNECT_RETRY - מספר שניות בין ניסיונות חיבור מחדש. במקרה של בעיות רשת, ערך נמוך לפרמטר זה יאפשר חיבור מהיר מחדש וימנע את תחילת תהליך שחזור האשכולות. הערך המומלץ הוא שנייה אחת.
MASTER_RETRY_COUNT - המספר המרבי של ניסיונות חיבור מחדש.
MASTER_HEARTBEAT_PERIOD - מרווח בשניות שלאחריו המאסטר שולח אות דופק. ברירת המחדל היא מחצית מהערך slave_net_timeout.

אפשרויות תזמורת:

DelayMasterPromotionIfSQLThreadNotUpToDate - אם שווה true, אז תפקיד המאסטר לא יוחל על העתק המועמד עד שהשרשור SQL של העתק ישלים את כל העסקאות שלא יושמו מיומן הממסר. אנו משתמשים באפשרות זו כדי למנוע אובדן עסקאות כאשר כל ההעתקים המועמדים מפגרים.
InstancePollSeconds - תדירות בנייה ועדכון של הטופולוגיה.
RecoveryPollSeconds - תדירות ניתוח טופולוגיה. אם מזוהה בעיה, שחזור טופולוגיה מתחיל. זֶה קבוע, שווה לשנייה אחת.

כל צומת אשכול נשאל על ידי המתזמר פעם אחת InstancePollSeconds שניות כאשר מתגלה בעיה, מצב האשכול נאלץ מְעוּדכָּן, ולאחר מכן מתקבלת ההחלטה הסופית לבצע שחזור. על ידי ניסוי עם פרמטרים שונים של מסד נתונים ותזמר, הצלחנו לצמצם את זמן התגובה וההתאוששות ל-30 שניות.

עמדת מבחן

התחלנו לבדוק את ערכת ה-HA עם פיתוח של מקומי מבחן ביצועים והטמעה נוספת בסביבות בדיקה וייצור. העמדה המקומית אוטומטית לחלוטין על בסיס Docker ומאפשרת להתנסות בתצורת התזמר והרשת, להגדיל את האשכול מ-2-3 שרתים לכמה עשרות ולערוך תרגילים בסביבה בטוחה.

במהלך התרגילים, אנו בוחרים באחת משיטות הדמיית הבעיה: צלם באופן מיידי את המאסטר באמצעות kill -9, סיים בעדינות את התהליך ועצור את השרת (docker-compose stop), לדמות בעיות רשת באמצעות iptables -j REJECT או iptables -j DROP. אנו מצפים לתוצאות הבאות:

המתזמר יזהה בעיות עם המאסטר ויעדכן את הטופולוגיה תוך לא יותר מ-10 שניות;
הליך השחזור יתחיל אוטומטית: תצורת הרשת תשתנה, תפקידו של המאסטר יעבור לעתק, הטופולוגיה תיבנה מחדש;
המאסטר החדש יהפוך לכתיבה, העתקים חיים לא יאבדו במהלך תהליך הבנייה מחדש;
נתונים יתחילו להיכתב למאסטר החדש ולשוכפל;
זמן ההחלמה הכולל לא יעלה על 30 שניות.

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

ממצאים

תקינותו של צומת מערכת האחסון הראשית היא אחת המשימות העיקריות של צוות SRE ומבצעים. הטמעת פתרון התזמורת וה-HA המבוסס על VIP אפשרה לנו להשיג את התוצאות הבאות:

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

עם זאת, לפתרון יש מגבלות וחסרונות:

קנה המידה של סכימת ה-HA למספר מרכזי נתונים ידרוש רשת L2 אחת ביניהם;
לפני שמקצים VIP על המאסטר החדש, עלינו לשחרר אותו על הישן. התהליך הוא רציף, מה שמגדיל את זמן ההחלמה;
שחרור ה-VIP דורש גישת SSH לשרת, או כל שיטה אחרת של קריאה לפרוצדורות מרוחקות. מכיוון שהשרת או מסד הנתונים נתקלים בבעיות שגרמו לתהליך השחזור, איננו יכולים להיות בטוחים שהסרת ה-VIP תסתיים בהצלחה. וזה יכול להוביל להופעה של שני שרתים עם אותה כתובת IP וירטואלית ובעיה split brain.

להתחמק split brain, אתה יכול להשתמש בשיטה סטונית ("Shoot The Other Node In The Head"), המבודד או משבית לחלוטין את הצומת הבעייתי. ישנן דרכים נוספות ליישם זמינות גבוהה של אשכולות: שילוב של VIP ו-DNS, שירותי גילוי שירות ופרוקסי, שכפול סינכרוני ושיטות אחרות שיש להן חסרונות ויתרונות משלהן.

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

מקור: www.habr.com

תזמורת ו-VIP כפתרון HA לאשכול MySQL