ارکستراتور برای MySQL: چرا بدون آن نمی توانید یک پروژه مقاوم در برابر خطا بسازید

هر پروژه بزرگی با چند سرور شروع شد. در ابتدا یک سرور DB وجود داشت، سپس بردهایی به آن اضافه شدند تا میزان خواندن را افزایش دهند. و سپس - متوقف شوید! یک ارباب وجود دارد، اما برده های زیادی وجود دارد. اگر یکی از Slave ها را ترک کند، همه چیز خوب خواهد بود، اما اگر استاد ترک کند، بد خواهد بود: خرابی، ادمین ها سعی می کنند سرور را بالا ببرند. چه باید کرد؟ یک استاد رزرو کنید همکار من پاول قبلاً در این مورد نوشته بود یک مقاله، من آن را تکرار نمی کنم. در عوض، من به شما خواهم گفت که چرا شما قطعاً به Orchestrator برای MySQL نیاز دارید!

بیایید با سوال اصلی شروع کنیم: "وقتی استاد کار را ترک کرد چگونه کد را به یک ماشین جدید تغییر دهیم؟"

• من طرح با VIP (IP مجازی) را بیشتر دوست دارم، در زیر در مورد آن صحبت خواهیم کرد. این ساده ترین و واضح ترین است، اگرچه یک محدودیت آشکار دارد: استادی که رزرو خواهیم کرد باید در بخش L2 با دستگاه جدید باشد، یعنی می توانیم DC دوم را فراموش کنیم. و به روشی دوستانه، اگر از قانون پیروی کنید که L2 بزرگ شر است، زیرا L2 فقط در هر رک است و L3 بین رک ها است و چنین طرحی محدودیت های بیشتری دارد.
• می توانید یک نام DNS در کد بنویسید و آن را از طریق /etc/hosts حل کنید. در واقع هیچ قطعنامه ای وجود نخواهد داشت. مزیت طرح: هیچ ویژگی محدودیتی برای روش اول وجود ندارد، یعنی امکان سازماندهی یک متقاطع DC وجود دارد. اما پس از آن این سوال واضح مطرح می شود: چقدر سریع می توانیم تغییر را از طریق Puppet-Ansible به /etc/hosts تحویل دهیم؟
• می توانید روش دوم را کمی تغییر دهید: DNS کش را روی همه سرورهای وب نصب کنید که از طریق آن کد به پایگاه داده اصلی می رود. می توانید TTL 60 را برای این ورودی در DNS تنظیم کنید. به نظر می رسد اگر به درستی اجرا شود، روش خوبی است.
• طرحی با کشف خدمات، مستلزم استفاده از کنسول و غیره.
• یک گزینه جالب با ProxySQL. شما باید تمام ترافیک را از طریق ProxySQL به MySQL هدایت کنید؛ خود ProxySQL می تواند تعیین کند که چه کسی استاد است. به هر حال، یکی از گزینه های استفاده از این محصول را می توانید در من بخوانید مقاله.

نویسنده ارکستراتور که در Github کار می کرد، ابتدا اولین طرح را با VIP پیاده سازی کرد و سپس آن را به یک طرح با کنسول تبدیل کرد.

طرح زیرساخت معمولی:

من فوراً موقعیت های واضحی را که باید در نظر گرفته شوند شرح خواهم داد:

• آدرس VIP نباید در پیکربندی هیچ یک از سرورها ثبت شود. بیایید یک موقعیت را تصور کنیم: استاد راه‌اندازی مجدد شد، و در حین لود شدن، ارکستراتور به حالت Failover رفت و یکی از برده‌ها را استاد کرد. سپس استاد قدیمی برخاست، و اکنون VIP روی دو ماشین است. این بد است.
• برای ارکستراتور، باید یک فیلمنامه برای فراخوانی استاد قدیمی و استاد جدید بنویسید. در مستر قدیمی باید ifdown را اجرا کنید و در مستر جدید ifup vip. خوب است که در این اسکریپت نیز گنجانده شود که در صورت خرابی، پورت سوئیچ اصلی قدیمی به سادگی خاموش می شود تا از هر گونه تقسیم مغزی جلوگیری شود.
• پس از اینکه ارکستراتور اسکریپت شما را فراخوانی کرد تا ابتدا VIP را حذف کند و/یا پورت سوئیچ را خاموش کند و سپس اسکریپت افزایش دهنده VIP را در استاد جدید فراخواند، فراموش نکنید که از دستور arping استفاده کنید تا به همه بگویید که VIP جدید اکنون است. اینجا.
• همه Slave باید read_only=1 باشند و به محض اینکه Slave را به master ارتقا دهید باید read_only=0 باشد.
• فراموش نکنید که هر برده ای که ما برای این کار انتخاب کرده ایم می تواند استاد شود (ارکستراتور یک مکانیسم ترجیحی کامل دارد که کدام برده را در وهله اول به عنوان کاندیدای ارباب جدید در نظر بگیرد، در وهله دوم کدام، و کدام برده باید اصلاً تحت هیچ شرایطی انتخاب نشود استاد). اگر بنده استاد شد، بار غلام روی آن می ماند و بار ارباب اضافه می شود، این باید در نظر گرفته شود.

اگر ارکستراتور ندارید، چرا به ارکستراتور نیاز دارید؟

• ارکستراتور دارای یک رابط گرافیکی بسیار کاربرپسند است که کل توپولوژی را نمایش می دهد (عکس زیر را ببینید).
• ارکستراتور می‌تواند ردیابی کند که کدام بردگان عقب مانده‌اند، و در کجای تکرار به طور کلی شکسته شده است (ما اسکریپت‌هایی را برای ارسال پیامک به ارکستراتور متصل کرده‌ایم).
• ارکستراتور به شما می گوید کدام بردگان دارای خطای GTID هستند.

رابط ارکستراتور:

خطای GTID چیست؟

دو شرط اصلی برای کار ارکستراتور وجود دارد:

• لازم است که شبه GTID در همه ماشین‌های خوشه MySQL فعال باشد؛ ما GTID را فعال کرده‌ایم.
• لازم است که همه جا یک نوع binlog وجود داشته باشد، می توانید از دستور استفاده کنید. ما یک پیکربندی داشتیم که در آن master و اکثر Slave دارای Row بودند و دو نفر از نظر تاریخی در حالت Mixed باقی می‌ماندند. در نتیجه، ارکستراتور به سادگی نمی خواست این بردگان را به استاد جدید متصل کند.

به یاد داشته باشید که مهمترین چیز در یک برده تولید، سازگاری آن با استاد است! اگر شناسه تراکنش جهانی (GTID) را هم در master و هم در slave فعال کرده اید، می توانید از تابع gtid_subset استفاده کنید تا بفهمید که آیا همان درخواست ها برای تغییرات داده ها واقعاً در این ماشین ها اجرا شده است یا خیر. می توانید در این مورد بیشتر بخوانید اینجا.

بنابراین، Orchestrator از طریق خطای GTID به شما نشان می‌دهد که تراکنش‌هایی روی Slave وجود دارد که روی master نیستند. چرا این اتفاق می افتد؟

• Read_only=1 در Slave فعال نیست، شخصی متصل شده و درخواست تغییر داده را تکمیل کرده است.
• Super_read_only=1 در Slave فعال نیست، سپس ادمین که سرور را گیج کرده بود، وارد شد و درخواست را در آنجا اجرا کرد.
• اگر هر دو نکته قبلی را در نظر گرفتید، پس یک ترفند دیگر وجود دارد: در MySQL، یک درخواست برای flush binlogs نیز به binlog می رود، بنابراین در اولین flush، خطای GTID روی master و همه Slave ظاهر می شود. چگونه از این امر اجتناب کنیم؟ Perona-5.7.25-28 تنظیم binlog_skip_flush_commands=1 را معرفی کرد که نوشتن flush در binlog را ممنوع می کند. در وب سایت mysql.com یکی وجود دارد حشره.

بگذارید همه موارد فوق را خلاصه کنم. اگر هنوز نمی خواهید از Orchestrator در حالت Failover استفاده کنید، آن را در حالت مشاهده قرار دهید. سپس شما همیشه نقشه ای از تعامل ماشین های MySQL و اطلاعات بصری در مورد اینکه چه نوع تکراری در هر ماشین وجود دارد، اینکه آیا Slave ها عقب مانده اند و مهمتر از همه اینکه چقدر با master سازگار هستند، در مقابل چشمان خود خواهید داشت!

سوال واضح این است: "ارکستراتور چگونه باید کار کند؟" او باید یک Master جدید از Slave های فعلی انتخاب کند، و سپس همه Slave ها را دوباره به آن متصل کند (این همان چیزی است که GTID برای آن مورد نیاز است؛ اگر از مکانیسم قدیمی با binlog_name و binlog_pos استفاده می کنید، سپس Slave را از master فعلی به یک Slave تغییر دهید. به سادگی غیرممکن است!). قبل از اینکه ارکستراتور داشته باشیم، یک بار مجبور شدم همه این کارها را به صورت دستی انجام دهم. استاد قدیمی به دلیل یک کنترلر حشره دار Adaptec آویزان بود؛ حدود 10 برده داشت. من نیاز داشتم که VIP را از Master به یکی از Slave منتقل کنم و همه Slave های دیگر را دوباره به آن وصل کنم. چند تا کنسول باید باز کنم، چند دستور همزمان وارد کردم... باید تا ساعت 3 صبح صبر میکردم، بار را از روی همه slave ها به جز دو تا، برمیداشتم، ماشین اول را از دو master درست میکردم، بلافاصله ماشین دوم را وصل میکردم. به آن، بنابراین تمام بردگان دیگر را به استاد جدید وصل کنید و بار را برگردانید. در کل وحشتناکه...

وقتی ارکستراتور به حالت Failover می رود چگونه کار می کند؟ این به راحتی با مثالی از موقعیتی نشان داده می شود که در آن ما می خواهیم از یک استاد ماشینی قدرتمندتر و مدرن تر از آنچه اکنون داریم بسازیم.

شکل وسط فرآیند را نشان می دهد. تا به حال چه کاری انجام شده است؟ گفتیم که می‌خواهیم برده‌ای را به استاد جدید تبدیل کنیم، ارکستراتور به سادگی شروع به اتصال همه برده‌های دیگر به آن کرد و استاد جدید به عنوان یک ماشین ترانزیت عمل می‌کرد. با این طرح، هیچ خطایی رخ نمی دهد، همه برده ها کار می کنند، ارکستراتور VIP را از استاد قدیمی حذف می کند، آن را به جدید منتقل می کند، read_only=0 را می سازد و استاد قدیمی را فراموش می کند. همه! زمان از کار افتادن سرویس ما زمان انتقال VIP است که 2-3 ثانیه است.

این همه برای امروز است، از همه شما متشکرم. به زودی مقاله دوم درباره ارکستراتور منتشر خواهد شد. در فیلم معروف شوروی "گاراژ"، یکی از شخصیت ها گفت: "من با او به شناسایی نمی روم!" بنابراین، ارکستراتور، من با شما برای شناسایی می روم!

منبع: www.habr.com