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

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

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

• אני הכי אוהב את התוכנית עם VIP (Virtual IP), נדבר עליה למטה. זה הפשוט והברור ביותר, למרות שיש לו מגבלה ברורה: המאסטר שנשמור חייב להיות בקטע L2 עם המכונה החדשה, כלומר, אנחנו יכולים לשכוח מה-DC השני. ובאופן ידידותי, אם אתה פועל לפי הכלל ש-L2 גדול הוא רע, כי L2 הוא רק לכל מתלה, ו-L3 נמצא בין המתלים, ולתוכנית כזו יש הגבלות אפילו יותר.
• אתה יכול לכתוב שם DNS בקוד ולפתור אותו דרך /etc/hosts. למעשה, לא תהיה פתרון. היתרון של הסכימה: אין מגבלה האופיינית לשיטה הראשונה, כלומר, ניתן לארגן חוצה DC. אבל אז מתעוררת השאלה המתבקשת: באיזו מהירות אנחנו יכולים להעביר את השינוי ל-/etc/hosts דרך Puppet-Ansible?
• אתה יכול לשנות מעט את השיטה השנייה: התקן מטמון DNS בכל שרתי האינטרנט, שדרכו הקוד יעבור למסד הנתונים הראשי. אתה יכול להגדיר TTL 60 עבור ערך זה ב-DNS. נראה שאם מיושמת נכון, השיטה טובה.
• תוכנית עם גילוי שירות, המרמזת על השימוש בקונסול וכו'.
• אפשרות מעניינת עם ProxySQL. אתה צריך לנתב את כל התעבורה ל-MySQL דרך ProxySQL; ProxySQL עצמו יכול לקבוע מי הוא המאסטר. אגב, תוכל לקרוא על אחת האפשרויות לשימוש במוצר זה ב- my статье.

המחבר של Orchestrator, שעבד ב-Github, יישם תחילה את התכנית הראשונה עם VIP, ולאחר מכן המיר אותה לתכנית עם קונסול.

פריסת תשתית אופיינית:

מיד אתאר את המצבים הברורים שיש לקחת בחשבון:

• אין לרשום את כתובת ה-VIP בתצורה באף אחד מהשרתים. בואו נדמיין מצב: המאסטר אתחל מחדש, ובזמן שהוא נטען, Orchestrator נכנס למצב כשל והפך את אחד העבדים למאסטר; ואז המאסטר הזקן קם, ועכשיו ה-VIP על שתי מכוניות. זה רע.
• עבור המתזמר, תצטרך לכתוב תסריט לקריאה למאסטר הישן ולמאסטר החדש. במאסטר הישן צריך להריץ ifdown, ובמאסטר החדש - ifup vip. זה יהיה נחמד לכלול בסקריפט הזה גם שבמקרה של תקלה, היציאה במתג של המאסטר הישן פשוט כבויה כדי למנוע כל מוח מפוצל.
• לאחר ש-Orchestertor התקשר לסקריפט שלך כדי להסיר תחילה את ה-VIP ו/או לכבות את היציאה על המתג, ולאחר מכן קרא לסקריפט העלאת VIP במאסטר החדש, אל תשכח להשתמש בפקודת arping כדי לומר לכולם שה-VIP החדש נמצא כעת כאן.
• כל העבדים צריכים להיות read_only=1, וברגע שאתה מקדם את העבד לאדון, הוא צריך להיות read_only=0.
• אל תשכח שכל עבד שבחרנו בשביל זה יכול להפוך לאדון (לתזמר יש מנגנון העדפה שלם עבור איזה עבד לשקול כמועמד לאדון חדש מלכתחילה, איזה מלכתחילה, ואיזה עבד צריך לשקול. לא ייבחר בכלל בשום פנים ואופן מאסטר). אם העבד הופך לאדון, אז העומס של העבד יישאר עליו ויתווסף עומס האדון, יש לקחת זאת בחשבון.

למה אתה צריך תזמורת אם אין לך?

• ל- Orchestrator יש ממשק גרפי ידידותי מאוד שמציג את כל הטופולוגיה (ראה צילום מסך למטה).
• Orchestrator יכול לעקוב אחר העבדים שנמצאים מאחור, והיכן השכפול התקלקל בדרך כלל (יש לנו סקריפטים המצורפים ל-Orchestertor לשליחת SMS).
• תזמורת אומר לך לאילו עבדים יש טעות GTID.

ממשק תזמורת:

מה זה GTID שגוי?

ישנן שתי דרישות עיקריות עבור תזמורת לעבודה:

• זה הכרחי ש-pseudo GTID יהיה מופעל בכל המכונות באשכול MySQL; GTID מופעל.
• זה הכרחי שיהיה סוג אחד של binlogs בכל מקום, אתה יכול להשתמש בהצהרה. הייתה לנו תצורה שבה לאדון ולרוב העבדים הייתה שורה, ושניים נשארו היסטורית במצב מעורב. כתוצאה מכך, Orchestrator פשוט לא רצה לחבר את העבדים האלה למאסטר החדש.

זכור שהדבר החשוב ביותר בעבד ייצור הוא העקביות שלו עם המאסטר! אם הפעלת מזהה טרנזקציה גלובלי (GTID) הן במאסטר והן בעבד, אז אתה יכול להשתמש בפונקציה gtid_subset כדי לברר אם אותן בקשות לשינויי נתונים אכן בוצעו במכונות אלו. אתה יכול לקרוא עוד על זה כאן.

לפיכך, Orchestrator מראה לך דרך תגובת ה-GTID שיש עסקאות על העבד שאינן על המאסטר. למה זה קורה?

• Read_only=1 אינו מופעל ב-slave, מישהו התחבר והשלים בקשה לשנות נתונים.
• Super_read_only=1 אינו מופעל ב-slave, ואז המנהל, לאחר שבלבל את השרת, נכנס וביצע את הבקשה שם.
• אם לקחתם בחשבון את שתי הנקודות הקודמות, אז יש עוד טריק אחד: ב-MySQL, בקשה לשטוף בינלוגים עוברת גם ל-binlog, כך שבשטיקה הראשונה, תופיע שגיאת GTID על המאסטר ועל כל העבדים. איך להימנע מכך? Perona-5.7.25-28 הציגה את ההגדרה binlog_skip_flush_commands=1, האוסרת כתיבת שטיפה ל-binlogs. יש אחד מבוסס באתר mysql.com חרק.

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

השאלה המתבקשת היא: "איך תזמורת אמור לעבוד?" עליו לבחור מאסטר חדש מהעבדים הנוכחיים, ולאחר מכן לחבר אליו מחדש את כל העבדים (בשביל זה דרוש GTID; אם אתה משתמש במנגנון הישן עם binlog_name ו-binlog_pos, אז העברת עבד מהמאסטר הנוכחי לחדש זה פשוט בלתי אפשרי!). לפני שהיה לנו Orchestrator, פעם הייתי צריך לעשות את כל זה באופן ידני. המאסטר הישן היה תלוי בגלל בקר Adaptec באגי; היו לו בערך 10 עבדים. הייתי צריך להעביר VIP מהמאסטר לאחד העבדים ולחבר אליו מחדש את כל שאר העבדים. כמה קונסולות הייתי צריך לפתוח, כמה פקודות בו-זמנית נכנסתי... הייתי צריך לחכות עד 3 לפנות בוקר, להסיר את העומס מכל העבדים מלבד שניים, לעשות את המכונה הראשונה משני מאסטרים, מיד לחבר את המכונה השנייה אליו, אז צרפו את כל שאר העבדים לאדון החדש והחזירו את המטען. בסך הכל, נורא...

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

האיור מציג את אמצע התהליך. מה כבר נעשה עד שלב זה? אמרנו שאנחנו רוצים להפוך איזה עבד למאסטר החדש, Orchestrator התחיל פשוט לחבר אליו מחדש את כל העבדים האחרים, כשהמאסטר החדש משמש כמכונת מעבר. עם סכימה זו, לא מתרחשות שגיאות, כל העבדים עובדים, Orchestrator מסיר את ה-VIP מהמאסטר הישן, מעביר אותו לחדש, עושה read_only=0 ושוכח מהמאסטר הישן. את כל! זמן ההשבתה של השירות שלנו הוא זמן העברת ה-VIP, שהוא 2-3 שניות.

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

מקור: www.habr.com