לאחר החלק הראשון בסדרה בנושא רפליקציה של MySQL, חלק זה לוקח צעד אחד קדימה את האופטימיזציה ושיפור הביצועים של MySQL ומסביר על חלוקת עומסים, אל כשל והתאוששות מנפילה.
הרכיב שבו נשתמש לחלוקת עומסים הינו MySQL-Proxy. רכיב זה משמש בעיקר לחלוקת עומסים בארכיטקטורת Master-Master או Master-Slave, אך לא רק.
MySQL Proxy הינו רכיב פשוט אך מתוחכם של MySQL, שיושב בין הקליינט לשרת(ים) המסוגל לנטר, לנתח, ולחלק את התקשורת של MySQL לכמה שרתים שונים. מכיוון שהרכיב גמיש מאוד ניתן באמצעותו:
- חלוקת עומסים
- אל-כשל
- ניתוח שאילתות
- עדכון וסינון שאילתות
- ועוד הרבה (מכיוון שהרכיב מבוסס שפת Lua ניתן בקלות להרחיבו).
שימו לב כי בניגוד למקרה שלנו, ניתן אף להתקין את הרכיב גם על שרת שיושב עליו MySQL. הפרוקסי פשוט יפעל על פורט אחר.
# on gentooemerge mysql-proxy# on fedorarpm -i mysql-proxy
# MySQL Proxy's configuration file (mysql-proxy.cnf)
# This file must be 0660 or more restrictive
# otherwise mysql-proxy will refuse to load
[mysql-proxy]
keepalive = true
log-backtrace-on-crash = true
plugins = proxy
proxy-address = :4040
proxy-backend-addresses = 192.168.0.100:3306,192.168.0.110:3306
proxy-read-only-backend-addresses=192.168.0.110:3306,192.168.0.100:3306
proxy-fix-bug-25371 = false
proxy-skip-profiling = false
log-level = message
log-file = /var/log/mysql/mysql-proxy.log
pid-file = /var/run/mysql-proxy.pid
- הראשון הינו proxy-backend-addresses. משתנה זה מגדיר את שרתי ה-Master שביניהם ינותבו שאילתות העדכון (insert, delete וכו').
- מכיוון שבארכיטקטורה בדוגמא שלנו לא מעורב שרת Slave טהור (שאינו גם Master), הגדרנו את שרתי ה-Master כשרתי ה-Slave בסדר הפוך (proxy-read-only-backend-addresses).
- רמת תיעוד לוג - ניתן להגדיר רמת התיעוד בלוג של הרכיב. במידה וישנן תקלות נוכל להגדיר תיעוד לוג ברמת debug.
- proxy-address - באיזה פורט יעבוד הפרוקסי.
- keepalive מגדיר שאם תהיה נפילה לרכיב עצמו הוא יבצע התאוששות אוטומטית.
/etc/init.d/mysql-proxy startrc-update add mysql-proxy default
אז מה הפתרון שקיבלנו?
דבר ראשון, ניתן בקלות להגדיר רפליקציה ללא שינוי קוד של אפליקציה. חוץ מזה, בטח שאלתם מה עוד מגניב??
חלוקת עומסים
דבר ראשון, כל אפליקציה שתפנה לשרת הפרוקסי תופנה לשרת ה-Master הפחות עמוס. החלוקה מתבצעת בהתאם ל-round-robin. לדוגמא אם שרת x פונה לפרוקסי הוא יופנה ל-server1, שרת y פונה לפרוקסי הוא יופנה ל-server2 וכך הלאה. שימו לב כי הרכיב יודע מתי הפניה מסתיימת בכל אחד מפניות, ולכן הוא גם יודע אם אחד השרתים עמוסים בפניות כבדות, זאת כדי להפנות לשרת הפחות עמוס.
אל-כשל
אז חלוקת עומסים יש, מה לגבי אל-כשל? MySQL-Proxy יודע לזהות אוטומטית אם אחד מהשרתים לא זמין (נפל מאיזושהי סיבה), ולנתב את כל השאילתות לשרת שעדיין "נושם". כך נוכל לטפל בינתיים בשרת שנפל בלי Downtime של שנייה אחת. ה-Master שעדיין "חי" יוכל להתעדכן בלי שהאפליקציות יודעות בכלל שהיתה נפילה לאחד השרתים.
התאוששות
יש גם אל-כשל... מגניב! איך מתאוששים ומסנכרנים שרת שנפל??
ופה טמון כל היופי של Master-Master, מכיוון שכל שרת מעדכן את השני בצורה רציפה, ברגע שהשרת שנפל מתאושש, הוא "יתשאל" את השרת שעדיין "חי" מה המצב שלו ואם יש עדכונים מהרגע שהוא נפל (איך בדיוק? קראו על לוג בינארי בחלק הקודם). השרת המתאושש יסתנכרן אוטומטית ללא התערבות המשתמש למצב מדויק שבו נמצא השרת שלא נפל וכך כל הארכיטקטורה תמשיך לעבוד ללא התערבות חיצונית (חוץ מהתאוששות עצמה).
במידה ומדובר ב-Master-Slave ניתן להשיג התאוששות כזו רק במידה ואחד הסלאבים (Slaves) נפל. במידה וישנו Master יחיד והוא נפל המערכת לא תוכל להתעדכן אלא לבצע שאילתות קריאה בלבד עד שה-Master יתאושש.
שארית דבר
למעשה, השרידות של ארכיטקטורה זו - Master-Master replication עם MySQL מאחוריהם - הינה בעלת שרידות גבוהה מאוד (99%). שרידות גבוהה מזו מושגת אך ורק ע"י MySQL Cluster והיא נדרשת רק כאשר מדובר על נפחים הרבה יותר גדולים. כמה גדולים? כאשר מדובר על טארהבייטים (פייסבוק, גוגל ועוד משתמשים בקלסטרים).
בכל אופן, MySQL Cluster יוסבר במאמר הבא בסדרה.
אל תשכחו לתת בתגובות :-)
הוספת תגובה