معرفی

مدتی پیش به من وظیفه ایجاد یک خوشه شکست خورده برای PostgreSQL و، در چندین مرکز داده که توسط فیبر در یک شهر به هم متصل هستند کار می کنند و می توانند در برابر خرابی (مثلاً خاموشی) یک مرکز داده مقاومت کنند. به عنوان نرم افزاری که مسئولیت تحمل خطا را بر عهده دارد، آن را انتخاب کردم دستگاه تنظیم کننده ضربان قلبزیرا این راه حل رسمی از RedHat برای ایجاد کلاسترهای failover است. این خوب است زیرا RedHat از آن پشتیبانی می کند و به دلیل اینکه این راه حل جهانی (مژولار) است. با کمک آن، می توان از تحمل خطا نه تنها PostgreSQL، بلکه سایر سرویس ها، یا با استفاده از ماژول های استاندارد یا ایجاد آنها برای نیازهای خاص، اطمینان حاصل کرد.

برای این تصمیم، یک سوال منطقی مطرح شد: یک خوشه شکست تا چه حد تحمل خطا خواهد داشت؟ برای بررسی این موضوع، من یک میز تست ایجاد کردم که خرابی‌های مختلف را در گره‌های خوشه شبیه‌سازی می‌کند، منتظر بازیابی می‌شود، گره شکست خورده را بازیابی می‌کند و به آزمایش در یک حلقه ادامه می‌دهد. در ابتدا این پروژه hapgsql نام داشت، اما به مرور زمان از این نام که فقط یک مصوت دارد خسته شدم. بنابراین، من شروع به نام‌گذاری پایگاه‌های اطلاعاتی مقاوم به خطا (و IPهای شناور که به آنها اشاره می‌کنند) کردم. کروگان (شخصیتی از یک بازی کامپیوتری که در آن همه اندام های مهم کپی شده اند) و گره ها، خوشه ها و خود پروژه هستند. توچانکا (سیاره ای که کروگان ها در آن زندگی می کنند).

اکنون مدیریت تایید کرده است پروژه ای را برای جامعه منبع باز تحت مجوز MIT باز کنید. README به زودی به انگلیسی ترجمه می شود (زیرا انتظار می رود توسعه دهندگان ضربان ساز و PostgreSQL مصرف کنندگان اصلی باشند)، و من تصمیم گرفتم نسخه روسی قدیمی README (تا حدی) را در قالب این مقاله منتشر کنم.

خوشه ها بر روی ماشین های مجازی مستقر می شوند نرم افزار VirtualBox. در مجموع، 12 ماشین مجازی (در مجموع 36 گیگا بایت) مستقر خواهند شد که 4 خوشه شکست (گزینه های مختلف) را تشکیل می دهند. دو خوشه اول شامل دو سرور PostgreSQL هستند که در مراکز داده مختلف و یک سرور مشترک قرار دارند شاهد c دستگاه حد نصاب (میزبانی بر روی یک ماشین مجازی ارزان قیمت در مرکز داده سوم)، که عدم قطعیت را برطرف می کند 50٪ /٪ 50، رای خود را به یکی از طرفین بدهید. خوشه سوم در سه مرکز داده: یک Master، دو Slave، نه دستگاه حد نصاب. خوشه چهارم از چهار سرور PostgreSQL تشکیل شده است، دو سرور در هر مرکز داده: یک استاد، بقیه کپی هستند و همچنین از آنها استفاده می کند. شاهد c دستگاه حد نصاب. چهارمی از خرابی دو سرور یا یک مرکز داده جان سالم به در می‌برد. در صورت لزوم می توان این راه حل را به تعداد بیشتری کپی تغییر داد.

سرویس زمان ntpd همچنین برای تحمل خطا مجدداً پیکربندی شده است، اما از خود روش استفاده می کند ntpd (حالت یتیم). سرور اشتراکی شاهد به عنوان یک سرور NTP مرکزی عمل می کند و زمان خود را به همه خوشه ها تقسیم می کند و در نتیجه همه سرورها را با یکدیگر همگام می کند. اگر شاهد از کار می افتد یا مشخص می شود که ایزوله شده است، سپس یکی از سرورهای کلاستر (در داخل خوشه) شروع به توزیع زمان خود می کند. ذخیره کمکی پروکسی HTTP نیز مطرح شده است شاهدبا کمک آن، ماشین های مجازی دیگر به مخازن Yum دسترسی دارند. در واقع، خدماتی مانند زمان دقیق و پروکسی به احتمال زیاد بر روی سرورهای اختصاصی میزبانی می شوند و در غرفه ای که در آن میزبانی می شوند. شاهد فقط برای صرفه جویی در تعداد ماشین های مجازی و فضا.

نسخه ها

v0. با CentOS 7 و PostgreSQL 11 در VirtualBox 6.1 کار می کند.

ساختار خوشه ای

همه خوشه‌ها به گونه‌ای طراحی شده‌اند که در چندین مرکز داده قرار گرفته و در یک شبکه مسطح ترکیب شده‌اند و باید در برابر شکست یا جداسازی شبکه از یک مرکز داده واحد مقاومت کنند. از همین رو غیرممکن است استفاده برای محافظت در برابر فکر نامتمرکز فن آوری ضربان ساز استاندارد نامیده می شود استونیت (به گره دیگر در سر شلیک کنید) یا نرده. ماهیت آن: اگر گره‌های خوشه شروع به مشکوک شدن به اینکه چیزی در برخی از گره‌ها اشتباه است، پاسخ نمی‌دهد یا اشتباه رفتار می‌کند، آن‌ها به زور آن را از طریق دستگاه‌های "خارجی" خاموش می‌کنند، به عنوان مثال، کارت کنترل IPMI یا UPS. . اما این فقط در مواردی کار می کند که در صورت یک شکست، سرور IPMI یا UPS به کار خود ادامه دهد. در اینجا ما قصد داریم در برابر یک خرابی فاجعه بارتر، زمانی که کل مرکز داده از کار می افتد (به عنوان مثال، برق را از دست می دهد) محافظت کنیم. و با چنین امتناع، همه چیز استونیث-دستگاه ها (IPMI، UPS، و غیره) نیز کار نمی کنند.

در عوض، سیستم مبتنی بر ایده حد نصاب است. همه گره ها صدا دارند و فقط آنهایی که بیش از نیمی از گره ها را می بینند می توانند کار کنند. این عدد "نیم + 1" نامیده می شود حد نصاب. اگر حد نصاب حاصل نشد، آنگاه گره تصمیم می گیرد که در ایزوله شبکه است و باید منابع خود را خاموش کند، یعنی. همین است که هست حفاظت از تقسیم مغز. اگر نرم‌افزاری که مسئول این رفتار است کار نمی‌کند، به عنوان مثال، یک نگهبان، بر اساس IPMI، باید کار کند.

اگر تعداد گره ها زوج باشد (یک خوشه در دو مرکز داده)، به اصطلاح ممکن است عدم قطعیت ایجاد شود. 50٪ /٪ 50 (پنجاه پنجاه) زمانی که جداسازی شبکه، خوشه را دقیقاً به نصف تقسیم می کند. بنابراین، برای تعداد زوج گره، اضافه می شود دستگاه حد نصاب - یک دیمون غیرمجاز که می تواند بر روی ارزان ترین ماشین مجازی در مرکز داده سوم اجرا شود. او رای خود را به یکی از بخش ها (که می بیند) می دهد و بدین وسیله عدم قطعیت 50/50 درصد را حل می کند. سروری که دستگاه حد نصاب روی آن اجرا خواهد شد، تماس گرفتم شاهد (اصطلاحات از repmgr، من آن را دوست داشتم).

منابع را می توان از مکانی به مکان دیگر منتقل کرد، به عنوان مثال، از سرورهای معیوب به سرورهای سالم یا به دستور مدیران سیستم. به طوری که مشتریان بدانند منابع مورد نیاز در کجا قرار دارند (کجا باید متصل شوند؟)، IP شناور (آی پی شناور). اینها IPهایی هستند که Pacemaker می تواند در اطراف گره ها حرکت کند (همه چیز در یک شبکه مسطح است). هر یک از آنها نماد یک منبع (سرویس) هستند و در جایی قرار می گیرند که برای دسترسی به این سرویس (در مورد ما، یک پایگاه داده) نیاز به اتصال دارید.

Tuchanka1 (مدار با تراکم)

ساختار

ایده این بود که ما پایگاه‌های داده کوچک زیادی با بار کم داریم که برای آن‌ها نگهداری سرور اختصاصی در حالت آماده به کار برای تراکنش‌های فقط خواندنی سودآور نیست (نیازی به چنین اتلاف منابع نیست).

هر مرکز داده یک سرور دارد. هر سرور دارای دو نمونه PostgreSQL است (در اصطلاح PostgreSQL به آنها خوشه گفته می شود، اما برای جلوگیری از سردرگمی آنها را نمونه می نامم (بر اساس قیاس با سایر پایگاه های داده)، و من فقط خوشه های Pacemaker را کلاستر می نامم. یک نمونه در حالت اصلی کار می کند و فقط خدمات ارائه می دهد (فقط IP شناور به آن منتهی می شود). نمونه دوم به عنوان یک برده برای مرکز داده دوم کار می کند و تنها در صورتی خدمات ارائه می دهد که master آن از کار بیفتد. از آنجایی که در اکثر مواقع تنها یک نمونه از دو (مستر) خدمات ارائه می دهد (انجام درخواست ها)، تمام منابع سرور برای اصلی بهینه سازی می شوند (حافظه برای کش shared_buffers و غیره تخصیص داده می شود)، اما به طوری که نمونه دوم همچنین دارای منابع کافی (البته برای عملیات کمتر از حد مطلوب از طریق کش سیستم فایل) در صورت خرابی یکی از مراکز داده. Slave در طول عملکرد عادی خوشه خدماتی ارائه نمی دهد (درخواست های فقط خواندنی را انجام نمی دهد) به طوری که هیچ جنگی برای منابع با master در همان ماشین وجود ندارد.

در مورد دو گره، تحمل خطا فقط با همانندسازی ناهمزمان امکان پذیر است، زیرا با تکرار همزمان، شکست Slave منجر به توقف master می شود.

عدم شهادت

عدم شهادت (دستگاه حد نصاب) من فقط برای خوشه Tuchanka1 در نظر خواهم گرفت، داستان مشابه با بقیه خواهد بود. اگر شاهد شکست بخورد، هیچ چیز در ساختار خوشه تغییر نخواهد کرد، همه چیز به همان روشی که کار می کرد به کار خود ادامه می دهد. اما حد نصاب 2 از 3 خواهد شد و بنابراین هر شکست بعدی برای خوشه کشنده خواهد بود. هنوز باید فوری انجام شود.

امتناع Tuchanka1

خرابی یکی از مراکز داده برای Tuchanka1. در این مورد شاهد رای خود را به گره دوم در مرکز داده دوم می اندازد. در آنجا Slave سابق به Master تبدیل می شود، در نتیجه هر دو Master روی یک سرور کار می کنند و هر دو IP float آنها به آنها اشاره می کنند.

Tuchanka2 (کلاسیک)

ساختار

طرح کلاسیک دو گره. ارباب روی یکی کار می کند، برده روی دومی. هر دو می توانند درخواست ها را اجرا کنند (برده فقط خواندنی است)، بنابراین هر دو با IP شناور نشان داده می شوند: krogan2 master است، krogan2s1 برده است. هم ارباب و هم برده تحمل خطا خواهند داشت.

در مورد دو گره، تحمل خطا فقط با همانندسازی ناهمزمان امکان پذیر است، زیرا با تکرار همزمان، شکست Slave منجر به توقف master می شود.

امتناع Tuchanka2

اگر یکی از مراکز داده از کار بیفتد شاهد به دومی رای دهید در تنها مرکز داده فعال، Master بالا می‌رود و هر دو IP شناور به آن اشاره می‌کنند: master و slave. البته نمونه باید به گونه ای پیکربندی شود که دارای منابع کافی (محدودیت های اتصال و غیره) باشد تا به طور همزمان کلیه اتصالات و درخواست های IP float master و slave را بپذیرد. یعنی در حین کارکرد عادی باید حاشیه کافی برای محدودیت ها داشته باشد.

توچانکا4 (بسیاری از بردگان)

ساختار

در حال حاضر یک افراط دیگر. پایگاه‌های داده‌ای هستند که درخواست‌های فقط خواندنی زیادی دارند (یک مورد معمول از یک سایت با بارگذاری بالا). Tuchanka4 وضعیتی است که در آن ممکن است سه یا چند برده برای رسیدگی به چنین درخواست‌هایی وجود داشته باشد، اما هنوز هم زیاد نیست. با تعداد بسیار زیاد بردگان، اختراع یک سیستم تکرار سلسله مراتبی ضروری خواهد بود. در حداقل حالت (در تصویر)، هر یک از دو مرکز داده دارای دو سرور است که هر کدام دارای یک نمونه PostgreSQL هستند.

یکی دیگر از ویژگی های این طرح این است که از قبل امکان سازماندهی یک تکرار همزمان وجود دارد. پیکربندی شده است تا در صورت امکان، به‌جای یک کپی در همان مرکز داده اصلی، در مرکز داده دیگری کپی شود. Master و هر slave با یک IP شناور نشان داده می شوند. خوشبختانه، بین بردگان لازم است به نحوی بین درخواست ها تعادل برقرار شود پروکسی sqlبه عنوان مثال، در سمت مشتری. انواع مختلف مشتریان ممکن است به انواع مختلفی نیاز داشته باشند پروکسی sql، و فقط توسعه دهندگان مشتری می دانند که چه کسی به کدام نیاز دارد. این قابلیت می تواند توسط یک شبح خارجی یا توسط یک کتابخانه مشتری (پول اتصال) و غیره پیاده سازی شود. همه اینها فراتر از موضوع یک خوشه پایگاه داده failover (failover پروکسی SQL می تواند به طور مستقل، همراه با failover کلاینت اجرا شود).

امتناع Tuchanka4

اگر یک مرکز داده (یعنی دو سرور) از کار بیفتد، شاهد رای به دومی هستید. در نتیجه، دو سرور در مرکز داده دوم کار می‌کنند: سرور اصلی روی یکی کار می‌کند و IP شناور اصلی به آن اشاره می‌کند (برای دریافت درخواست‌های خواندن و نوشتن). و یک Slave با Replication همزمان در سرور دوم در حال اجرا است و یکی از IP های شناور Slave به آن اشاره می کند (برای درخواست های فقط خواندنی).

اولین چیزی که باید به آن توجه کنید: همه IP های شناور برده کار نمی کنند، اما فقط یک مورد. و برای کار صحیح با آن لازم است که پروکسی sql همه درخواست ها را به تنها IP شناور باقی مانده هدایت کرد. و اگر پروکسی sql نه، شما می توانید تمام بردهای IP شناور را که با کاما از هم جدا شده اند در URL اتصال فهرست کنید. در آن صورت، با libpq اتصال به اولین IP کار خواهد بود، این در سیستم تست خودکار انجام می شود. شاید در کتابخانه های دیگر، به عنوان مثال، JDBC، این کار نمی کند و ضروری است پروکسی sql. این کار به این دلیل انجام می شود که IP شناور برای Slave از بالا رفتن همزمان روی یک سرور ممنوع است، به طوری که در صورت وجود چندین سرور، آنها به طور مساوی بین سرورهای برده توزیع می شوند.

دوم: حتی در صورت خرابی مرکز داده، تکرار همزمان حفظ خواهد شد. و حتی اگر یک خرابی ثانویه رخ دهد، یعنی یکی از دو سرور در مرکز داده باقیمانده از کار بیفتد، خوشه، اگرچه ارائه خدمات را متوقف می کند، اما همچنان اطلاعات مربوط به تمام تراکنش های متعهد را که برای آنها تأیید کرده است، حفظ می کند. (در صورت خرابی ثانویه هیچ اطلاعاتی از دست نخواهد داد).

Tuchanka3 (3 مرکز داده)

ساختار

این یک خوشه برای موقعیتی است که در آن سه مرکز داده کاملاً کارآمد وجود دارد که هر کدام یک سرور پایگاه داده کاملاً کارآمد دارند. در این مورد دستگاه حد نصاب نیاز نیست. یک Master در یک مرکز داده کار می کند و Slave در دو مرکز دیگر کار می کند. Replication همزمان است، نوع ANY (slave1, slave2) است، یعنی زمانی که کلاینت تأییدیه commit را دریافت می کند که هر یک از Slave اولین پاسخی باشد که او commit را پذیرفته است. منابع توسط یک IP شناور برای master و دو برای Slave به آنها اشاره می شود. برخلاف Tuchanka4، هر سه IP float تحمل خطا دارند. برای ایجاد تعادل در پرس و جوهای SQL فقط خواندنی، می توانید استفاده کنید پروکسی sql (با تحمل خطای جداگانه)، یا یک شناور IP برده را به نیمی از کلاینت ها و دومی را به نیم دیگر اختصاص دهید.

امتناع Tuchanka3

اگر یکی از مراکز داده خراب شود، دو مرکز باقی می مانند. در یکی، IP اصلی و شناور از master بالا می‌رود، در دومی، آی‌پی‌های Slave و هر دو Slave float (نمونه باید دارای یک حاشیه منبع مضاعف برای پذیرش همه اتصالات از هر دو IP slave float باشد). همانندسازی همزمان بین ارباب و بردگان. همچنین، خوشه اطلاعات مربوط به تراکنش های متعهد و تایید شده (هیچ اطلاعاتی را از دست نخواهد داد) در صورت از بین رفتن دو مرکز داده (در صورت عدم تخریب همزمان) ذخیره می کند.

من تصمیم گرفتم که شرح مفصلی از ساختار فایل و استقرار آن درج نکنم. هرکسی که می‌خواهد بازی کند می‌تواند همه آن را در README بخواند. من فقط شرحی از تست خودکار ارائه می کنم.

سیستم تست اتوماتیک

برای بررسی تحمل خطای خوشه ها با تقلید از عیوب مختلف، یک سیستم تست خودکار ساخته شد. توسط اسکریپت راه اندازی شد test/failure. اسکریپت می‌تواند تعداد خوشه‌هایی را که می‌خواهید آزمایش کنید، به عنوان پارامتر در نظر بگیرد. برای مثال این دستور:

test/failure 2 3

فقط خوشه دوم و سوم را آزمایش خواهد کرد. اگر پارامترها مشخص نشده باشند، تمام خوشه ها آزمایش خواهند شد. همه خوشه ها به صورت موازی آزمایش می شوند و نتیجه در پنل tmux نمایش داده می شود. Tmux از یک سرور اختصاصی tmux استفاده می کند، بنابراین اسکریپت را می توان از زیر tmux پیش فرض اجرا کرد و در نتیجه یک tmux تودرتو ایجاد می شود. توصیه می کنم از ترمینال در یک پنجره بزرگ و با فونت کوچک استفاده کنید. قبل از شروع آزمایش، تمام ماشین‌های مجازی در زمان تکمیل اسکریپت به یک عکس فوری بازگردانده می‌شوند. setup.

ترمینال با توجه به تعداد خوشه های آزمایش شده به ستون ها تقسیم می شود، به طور پیش فرض (در تصویر) چهار مورد از آنها وجود دارد. من محتویات ستون ها را با استفاده از مثال Tuchanka2 شرح خواهم داد. پانل های موجود در اسکرین شات شماره گذاری شده اند:

1. اینجاست که آمار تست نمایش داده می شود. سخنرانان:
   • شکست - نام آزمون (عملکرد در اسکریپت) که شکست را تقلید می کند.
   • واکنش - زمان میانگین حسابی بر حسب ثانیه که خوشه عملکرد خود را بازیابی کرده است. از ابتدای اسکریپت که شکست را تقلید می کند و تا لحظه ای که خوشه سلامت خود را بازیابی می کند و می تواند به ارائه خدمات ادامه دهد اندازه گیری می شود. اگر زمان بسیار کوتاه باشد، به عنوان مثال، شش ثانیه (این اتفاق در خوشه‌هایی با چندین برده (Tuchanka3 و Tuchanka4) رخ می‌دهد)، این بدان معناست که نقص به یک برده ناهمزمان ختم شده و به هیچ وجه بر عملکرد تأثیری نداشته است، وجود ندارد. سوئیچ های حالت خوشه ای
   • انحراف - گسترش (دقت) مقدار را نشان می دهد واکنش با استفاده از روش انحراف معیار
   • تعداد دفعات مشاهده - این آزمایش چند بار انجام شده است.
2. گزارش کوتاه به شما این امکان را می دهد که آنچه را که خوشه در حال حاضر انجام می دهد ارزیابی کنید. شماره تکرار (تست)، مهر زمانی و نام عملیات نمایش داده می شود. اجرای بیش از حد طولانی (> 5 دقیقه) نشان دهنده نوعی مشکل است.
3. قلب (قلب) - زمان فعلی. برای ارزیابی بصری عملکرد استاد زمان جاری به طور مداوم در جدول آن با استفاده از float IP master نوشته می شود. در صورت موفقیت آمیز بودن، نتیجه در این پنل نمایش داده می شود.
4. ضرب (نبض) - "زمان فعلی" که قبلاً توسط فیلمنامه ضبط شده بود قلب برای استاد شدن، اکنون از برده از طریق IP شناور آن. به شما امکان می دهد عملکرد Slave و Replication را به صورت بصری ارزیابی کنید. هیچ برده ای با IP شناور در Tuchanka1 وجود ندارد (هیچ برده ای خدمات ارائه می دهد)، اما دو نمونه وجود دارد (DB)، بنابراین در اینجا نشان داده نخواهد شد. ضربو قلب نمونه دوم
5. نظارت بر سلامت خوشه با استفاده از ابزار pcs mon. ساختار، توزیع منابع توسط گره ها و سایر اطلاعات مفید را نشان می دهد.
6. نظارت سیستم از هر ماشین مجازی در خوشه در اینجا نمایش داده می شود. بسته به تعداد ماشین های مجازی خوشه ممکن است تعداد بیشتری از این پنل ها وجود داشته باشد. دو نمودار بار CPU (دو پردازنده در ماشین های مجازی)، نام ماشین مجازی، بار سیستم (میانگین بار نامگذاری شد زیرا میانگین آن بیش از 5، 10 و 15 دقیقه بود)، داده های پردازش و تخصیص حافظه.
7. ردیابی اسکریپتی که تست ها را انجام می دهد. در صورت بروز نقص - وقفه ناگهانی در عملکرد یا چرخه انتظار بی پایان - در اینجا می توانید دلیل این رفتار را ببینید.

تست در دو مرحله انجام می شود. ابتدا، اسکریپت انواع تست‌ها را طی می‌کند و به‌طور تصادفی ماشین مجازی را انتخاب می‌کند که این تست روی آن اعمال می‌شود. سپس یک چرخه تست بی پایان انجام می شود، ماشین های مجازی و هر بار یک نقص به طور تصادفی انتخاب می شوند. خاتمه ناگهانی اسکریپت تست (پانل پایین) یا یک حلقه انتظار بی پایان برای چیزی (بیشتر از 5 دقیقه زمان برای تکمیل یک عملیات، این را می توان در ردیابی مشاهده کرد) نشان می دهد که برخی از تست های این خوشه شکست خورده اند.

هر آزمون شامل عملیات زیر است:

1. راه اندازی تابعی که یک خطا را شبیه سازی می کند.
2. آماده؟ - انتظار برای بازیابی سلامت خوشه (زمانی که همه خدمات ارائه می شود).
3. زمان بازیابی خوشه نشان داده شده است (واکنش).
4. رفع - خوشه در حال "تعمیر" است. پس از آن باید به حالت کاملاً عملیاتی برگردد و برای نقص بعدی آماده شود.

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

• چنگال بمب: با استفاده از بمب چنگال "Out of memory" را ایجاد می کند.
• خارج از فضا: هارد پر است. اما تست نسبتاً نمادین است؛ با بار ناچیزی که در طول آزمایش ایجاد می‌شود، PostgreSQL معمولاً وقتی هارد دیسک پر است شکست نمی‌خورد.
• Postgres-KILL: PostgreSQL را با دستور می کشد killall -KILL postgres.
• postgres-STOP: دستور PostgreSQL را آویزان می کند killall -STOP postgres.
• خاموش: با دستور ماشین مجازی را «دیگر انرژی می‌کند». VBoxManage controlvm "виртуалка" poweroff.
• تنظیم مجدد: ماشین مجازی را با دستور بارگذاری مجدد می کند VBoxManage controlvm "виртуалка" reset.
• SBD STOP: شیطان SBD را با دستور معلق می کند killall -STOP sbd.
• خاموش کردن: از طریق SSH دستوری را به ماشین مجازی ارسال می کند systemctl poweroff، سیستم به آرامی خاموش می شود.
• لغو پیوند: جداسازی شبکه، فرمان VBoxManage controlvm "виртуалка" setlinkstate1 off.

پایان دادن به آزمایش یا با دستور استاندارد tmux "kill-window" ctrl-b&، یا با دستور "detach-client" ctrl-bd: در این مرحله تست به پایان می رسد، tmux بسته می شود، ماشین های مجازی خاموش می شوند.

مشکلات شناسایی شده در طول آزمایش

• در حال حاضر دایمون نگهبان sbd روی متوقف کردن شیاطین مشاهده شده کار می کند، اما آنها را منجمد نمی کند. و در نتیجه خطاهایی که فقط منجر به انجماد می شوند Corosync и دستگاه تنظیم کننده ضربان قلب، اما آویزان نیست sbd... برای بررسی Corosync قبلاً PR#83 (در GitHub در sbd)، در شعبه پذیرفته شد استاد. آنها قول دادند (در PR#83) که چیزی مشابه برای پیس میکر وجود خواهد داشت، امیدوارم تا آن زمان کلاه قرمزی 8 انجام خواهد داد. اما چنین "عیب‌هایی" حدس و گمان هستند و به راحتی با استفاده از روش مصنوعی تقلید می شوند. killall -STOP corosyncاما هرگز در زندگی واقعی ملاقات نمی کنند.

• У دستگاه تنظیم کننده ضربان قلب در نسخه برای CentOS 7 نادرست تنظیم شده است sync_timeout у دستگاه حد نصاب، در نتیجه اگر یکی از گره ها شکست بخورد، به احتمال زیاد گره دوم نیز راه اندازی مجدد می شود، که قرار بود استاد به سمت آن حرکت کند. با بزرگ شدن درمان می شود sync_timeout у دستگاه حد نصاب در حین استقرار (در اسکریپت setup/setup1). این اصلاحیه توسط توسعه دهندگان پذیرفته نشد دستگاه تنظیم کننده ضربان قلب، در عوض آنها قول دادند که زیرساخت ها را به گونه ای (در آینده نامعلومی) دوباره کار کنند که این زمان به طور خودکار محاسبه شود.

• اگر در طول پیکربندی پایگاه داده مشخص کردید که LC_MESSAGES (پیام های متنی) می توان از یونیکد استفاده کرد، به عنوان مثال، ru_RU.UTF-8، سپس در راه اندازی postgres در محیطی که محل UTF-8 نیست، مثلاً در یک محیط خالی (اینجا راهنما+pgsqlms(پاف) می دود postgres)، سپس در لاگ به جای حروف UTF-8 علامت سوال وجود خواهد داشت. توسعه دهندگان PostgreSQL در مورد اینکه در این مورد چه کاری انجام دهند به توافق نرسیده اند. هزینه دارد، باید نصب کنید LC_MESSAGES=en_US.UTF-8 هنگام پیکربندی (ایجاد) یک نمونه پایگاه داده.

• اگر wal_receiver_timeout تنظیم شده باشد (به طور پیش فرض 60 ثانیه است)، پس هنگام آزمایش PostgreSQL-STOP روی master در خوشه های tuchanka3 و tuchanka4 Replication دوباره به Master جدید متصل نمی شود. همانندسازی در آنجا همزمان است، بنابراین نه تنها Slave متوقف می‌شود، بلکه Master جدید نیز متوقف می‌شود. با تنظیم wal_receiver_timeout=0 هنگام پیکربندی PostgreSQL دریافت می شود.

• من گاهی اوقات تکرار PostgreSQL را در تست ForkBomb (سرریز حافظه) مشاهده کردم. بعد از ForkBomb، گاهی اوقات ممکن است Slave ها دوباره به Master جدید متصل نشوند. من فقط با این در خوشه‌های tuchanka3 و tuchanka4 مواجه شده‌ام، جایی که استاد به دلیل تکرار همزمان منجمد شد. این مشکل پس از مدت ها (حدود دو ساعت) خود به خود برطرف شد. برای اصلاح این موضوع به تحقیقات بیشتری نیاز است. علائم مشابه باگ قبلی است که به دلیل متفاوتی ایجاد می شود، اما پیامدهای مشابهی دارد.

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

منبع: www.habr.com