در Citymobil ما از پایگاه داده MySQL به عنوان ذخیره اصلی داده های دائمی خود استفاده می کنیم. ما چندین کلاستر پایگاه داده برای خدمات و اهداف مختلف داریم.

در دسترس بودن ثابت استاد یک شاخص حیاتی از عملکرد کل سیستم و بخش های جداگانه آن است. بازیابی خودکار خوشه در صورت خرابی اصلی، زمان پاسخ حادثه و زمان خرابی سیستم را تا حد زیادی کاهش می دهد. در این مقاله، من به طراحی با دسترسی بالا (HA) برای یک خوشه MySQL بر اساس MySQL Orchestrator و آدرس های IP مجازی (VIP).

راه حل HA بر اساس VIP

ابتدا به طور خلاصه به شما می گویم که سیستم ذخیره سازی داده ما چیست.

ما از یک طرح تکرار کلاسیک با یک استاد قابل دسترسی برای نوشتن و چند کپی فقط خواندنی استفاده می کنیم. یک خوشه می‌تواند شامل یک استاد میانی باشد - گره‌ای که هم کپی و هم یک استاد برای دیگران است. مشتریان از طریق HAProxy به کپی ها دسترسی دارند که امکان توزیع یکنواخت بار و مقیاس بندی آسان را فراهم می کند. استفاده از HAProxy به دلایل تاریخی است و ما در حال حاضر در حال مهاجرت به ProxySQL هستیم.

همانندسازی در حالت نیمه سنکرون بر اساس انجام می شود GTID. این بدان معنی است که حداقل یک ماکت باید قبل از موفقیت آمیز بودن تراکنش ثبت شود. این حالت تکرار تعادل بهینه بین عملکرد و ایمنی داده ها را در صورت خرابی گره اصلی فراهم می کند. اساساً تمام تغییرات با استفاده از Master به Replica ها منتقل می شوند Row Based Replication (RBR)، اما برخی از گره ها ممکن است داشته باشند mixed binlog format.

ارکستراتور به طور دوره ای وضعیت توپولوژی خوشه را به روز می کند، اطلاعات دریافتی را تجزیه و تحلیل می کند و در صورت بروز مشکل، می تواند یک روش بازیابی خودکار را راه اندازی کند. توسعه دهنده مسئول خود این روش است، زیرا می توان آن را به روش های مختلف پیاده سازی کرد: بر اساس VIP، DNS، با استفاده از خدمات کشف سرویس یا مکانیسم های خودنویس.

یکی از راه‌های ساده برای بازیابی Master در صورت عدم موفقیت، استفاده از آدرس‌های VIP شناور است.

آنچه باید در مورد این راه حل قبل از حرکت به جلو بدانید:

• VIP یک آدرس IP است که با یک رابط فیزیکی خاص شبکه مرتبط نیست. اگر یک گره از کار بیفتد یا در طول تعمیر و نگهداری برنامه ریزی شده، ما می توانیم VIP را به منبع دیگری با حداقل خرابی تغییر دهیم.
• آزادسازی و صدور یک آدرس IP مجازی یک عملیات ارزان و سریع است.
• برای کار با VIP، شما نیاز به دسترسی به سرور از طریق SSH یا استفاده از ابزارهای ویژه دارید، به عنوان مثال، keepalived.

بیایید به مشکلات احتمالی ویزارد خود نگاه کنیم و تصور کنیم که مکانیسم بازیابی خودکار چگونه باید کار کند.

اتصال شبکه به Master ناپدید شده است، یا مشکلی در سطح سخت افزار ایجاد شده است و سرور در دسترس نیست

1. ارکستراتور توپولوژی خوشه را به روز می کند، هر ماکت گزارش می دهد که استاد در دسترس نیست. ارکستراتور فرآیند انتخاب یک ماکت مناسب برای نقش استاد جدید را شروع می کند و شروع به بهبود می کند.
2. ما در حال تلاش برای حذف VIP از استاد قدیمی هستیم - بدون موفقیت.
3. ماکت به نقش استاد تبدیل می شود. توپولوژی در حال بازسازی است.
4. افزودن یک رابط شبکه جدید با VIP. از آنجایی که امکان حذف VIP وجود نداشت، ما به صورت دوره ای درخواست را در پس زمینه ارسال می کنیم ARP رایگان. این نوع درخواست/پاسخ به شما اجازه می‌دهد تا جدول نقشه‌برداری آدرس IP و MAC را روی سوئیچ‌های متصل به‌روزرسانی کنید، بنابراین به شما اطلاع می‌دهد که VIP ما جابه‌جا شده است. این احتمال را به حداقل می رساند split brain هنگام بازگشت استاد قدیمی
5. تمام اتصالات جدید فوراً به اصلی جدید هدایت می شوند. اتصالات قدیمی با شکست مواجه می شوند و تماس های مکرر با پایگاه داده در سطح برنامه انجام می شود.

سرور در حالت عادی کار می کند، یک نقص در سطح DBMS رخ داده است

الگوریتم مشابه مورد قبلی است: به روز رسانی توپولوژی و شروع فرآیند بازیابی. از آنجایی که سرور در دسترس است، ما با موفقیت VIP را در مستر قدیمی آزاد می کنیم، آن را به سرور جدید منتقل می کنیم و چندین درخواست ARP ارسال می کنیم. بازگشت احتمالی استاد قدیمی نباید بر خوشه بازسازی شده و عملکرد برنامه تأثیر بگذارد.

مشکلات دیگر

شکست ماکت یا استادهای متوسط منجر نمی شود به اقدامات خودکار و نیاز به مداخله دستی است.

یک رابط شبکه مجازی همیشه به طور موقت اضافه می شود، یعنی پس از راه اندازی مجدد سرور، VIP به طور خودکار اختصاص داده نمی شود. هر نمونه پایگاه داده به طور پیش فرض در حالت فقط خواندنی شروع می شود، ارکستراتور به طور خودکار استاد جدید را برای نوشتن تغییر می دهد و سعی می کند نصب کند. read only بر استاد قدیمی این اقدامات با هدف کاهش احتمال انجام می شود split brain.

ممکن است مشکلاتی در طول فرآیند بازیابی به وجود بیاید که علاوه بر ابزارهای نظارت استاندارد، باید از طریق رابط کاربری ارکستراتور نیز اطلاع داده شود. ما REST API را با افزودن این ویژگی (PR در حال حاضر در دست بررسی).

نمودار کلی محلول HA در زیر ارائه شده است.

انتخاب استاد جدید

ارکستراتور به اندازه کافی باهوش است و سعی می کند انتخاب کند مناسب ترین ماکت به عنوان استاد جدید با توجه به معیارهای زیر:

• ماکت از استاد عقب می ماند.
• نسخه MySQL Master و Replica.
• نوع تکرار (RBR، SBR یا مخلوط)؛
• مکان در مراکز داده یکسان یا متفاوت؛
• در دسترس بودن errant GTID - تراکنش‌هایی که روی ماکت انجام شده‌اند و روی Master نیستند.
• قوانین انتخاب سفارشی نیز در نظر گرفته شده است.

هر نشانه ای کاندیدای ایده آل برای استاد نیست. برای مثال، می‌توان از یک ماکت برای پشتیبان‌گیری از داده‌ها استفاده کرد، یا سرور پیکربندی سخت‌افزاری ضعیف‌تری دارد. ارکستراتور پشتیبانی می کند قوانین دستی که با استفاده از آنها می توانید اولویت های انتخاب نامزد خود را از ترجیح داده شده به نادیده گرفته شده سفارشی کنید.

زمان پاسخ و ریکاوری

در صورت بروز حادثه، به حداقل رساندن خرابی سیستم مهم است، بنابراین بیایید پارامترهای MySQL را که بر ایجاد و به روز رسانی توپولوژی خوشه توسط ارکستراتور تأثیر می‌گذارند، در نظر بگیریم:

• slave_net_timeout — تعداد ثانیه هایی که در طی آن ماکت منتظر می ماند تا داده های جدید یا سیگنال ضربان قلب از استاد برسد، قبل از اینکه اتصال به عنوان قطع شده تشخیص داده شود و دوباره وصل شود. هرچه مقدار کمتر باشد، ماکت سریعتر می تواند تشخیص دهد که ارتباط با استاد قطع شده است. این مقدار را روی 5 ثانیه قرار دادیم.
• MASTER_CONNECT_RETRY - تعداد ثانیه بین تلاش های اتصال مجدد. در صورت بروز مشکلات شبکه، مقدار کم این پارامتر امکان اتصال مجدد سریع را فراهم می کند و از شروع فرآیند بازیابی خوشه جلوگیری می کند. مقدار توصیه شده 1 ثانیه است.
• MASTER_RETRY_COUNT - حداکثر تعداد تلاش برای اتصال مجدد
• MASTER_HEARTBEAT_PERIOD - فاصله زمانی در ثانیه که پس از آن استاد سیگنال ضربان قلب را ارسال می کند. پیش‌فرض به نصف مقدار می‌رسد slave_net_timeout.

گزینه های ارکستراتور:

• DelayMasterPromotionIfSQLThreadNotUpToDate - اگر برابر باشد true، سپس نقش اصلی بر روی کپی کاندید اعمال نمی شود تا زمانی که رشته SQL ماکت تمام تراکنش های اعمال نشده را از Relay Log تکمیل کند. ما از این گزینه برای جلوگیری از از دست دادن تراکنش ها زمانی که همه کپی های کاندید عقب می مانند، استفاده می کنیم.
• InstancePollSeconds - فرکانس ساخت و به روز رسانی توپولوژی.
• RecoveryPollSeconds - فراوانی تحلیل توپولوژی اگر مشکلی شناسایی شود، بازیابی توپولوژی آغاز می شود. این مقدار ثابت، برابر با 1 ثانیه.

هر گره خوشه ای هر یک بار توسط ارکستراتور نظرسنجی می شود 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 صحبت کردم. پیاده سازی آن آسان است و سطح قابل قبولی از قابلیت اطمینان را در شرایط فعلی فراهم می کند. همانطور که کل سیستم به طور کلی و زیرساخت به طور خاص توسعه می یابد، این رویکرد بدون شک تکامل خواهد یافت.

منبع: www.habr.com