הדפסה
כניסות: 6196

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

הרכיב שבו נשתמש לחלוקת עומסים הינו MySQL-Proxy. רכיב זה משמש בעיקר לחלוקת עומסים בארכיטקטורת Master-Master או Master-Slave, אך לא רק.

 

MySQL Proxy הינו רכיב פשוט אך מתוחכם של MySQL, שיושב בין הקליינט לשרת(ים) המסוגל לנטר, לנתח, ולחלק את התקשורת של MySQL לכמה שרתים שונים. מכיוון שהרכיב גמיש מאוד ניתן באמצעותו:

מכיוון שאנחנו בהמשך למאמר המקורי שבו הוגדר רפליקציה Master-Master אנחנו נראה כיצד הרכיב משתלב בארכיטקורה זו. הרכיב עצמו יותקן על שרת נפרד משני שרתי ה-Master שהוגדרו במדריך הקודם. שם השרת הינו mango וה-IP שלו יהיה 192.168.0.200.
שימו לב כי בניגוד למקרה שלנו, ניתן אף להתקין את הרכיב גם על שרת שיושב עליו MySQL. הפרוקסי פשוט יפעל על פורט אחר.
נתקין את הרכיב בקלות (רוב ההפצות מכילות אותו כחבילה רגילה):
# on gentoo
emerge mysql-proxy
# on fedora
rpm -i mysql-proxy
ניתן להפעיל את הפרוקסי ישירות משורת הפקודה אבל ברוב ההפצות הוא מגיע כ-service ואנו נשתמש ב-service זה (הרבה יותר נוח).
נצטרך לערוך את קובץ ההגדרות שלו (mysql-proxy.cnf) שיושב בד"כ היכן שיושב קובץ ההגדרות של MySQL (שהוא my.cnf):

# 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

שימו לב למספר משתנים:
  1. הראשון הינו proxy-backend-addresses. משתנה זה מגדיר את שרתי ה-Master שביניהם ינותבו שאילתות העדכון (insert, delete וכו').
  2. מכיוון שבארכיטקטורה בדוגמא שלנו לא מעורב שרת Slave טהור (שאינו גם Master), הגדרנו את שרתי ה-Master כשרתי ה-Slave בסדר הפוך (proxy-read-only-backend-addresses).
  3. רמת תיעוד לוג - ניתן להגדיר רמת התיעוד בלוג של הרכיב. במידה וישנן תקלות נוכל להגדיר תיעוד לוג ברמת debug.
  4. proxy-address - באיזה פורט יעבוד הפרוקסי.
  5. keepalive מגדיר שאם תהיה נפילה לרכיב עצמו הוא יבצע התאוששות אוטומטית.
נפעיל את הרכיב באמצעות הפעלת הרכיב ונגדיר אותו שיפעל בעליית המערכת (בהפצת ג'נטו):
/etc/init.d/mysql-proxy start
rc-update add mysql-proxy default
עכשיו נגדיר לכל אפליקציה שתשתמש בשרת הפרוקסי (192.168.0.200 במקרה שלנו) עם הפורט המתאים (4040) במקום אחד מהמסטרים שהיו מוגדרים עד עתה.

אז מה הפתרון שקיבלנו?

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

חלוקת עומסים

דבר ראשון, כל אפליקציה שתפנה לשרת הפרוקסי תופנה לשרת ה-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 יוסבר במאמר הבא בסדרה.

אל תשכחו לתת בתגובות :-)

הוספת תגובה

0
  • לא נמצאו תגובות
Powered by Komento