ორკესტრატორი MySQL-ისთვის: რატომ არ შეგიძლიათ შექმნათ შეცდომების შემწყნარებელი პროექტი მის გარეშე

ნებისმიერი დიდი პროექტი დაიწყო რამდენიმე სერვერით. თავიდან იყო ერთი DB სერვერი, შემდეგ მას დაემატა სლავები კითხვის გასაზომად. და შემდეგ - გაჩერდი! ბატონი ერთია, მონა კი ბევრია; თუ რომელიმე მონა წავა, მაშინ ყველაფერი კარგად იქნება, მაგრამ თუ ოსტატი წავა, ეს ცუდი იქნება: შეფერხება, ადმინები ცდილობენ სერვერის ამაღლებას. Რა უნდა ვქნა? დაჯავშნე ოსტატი. ჩემმა კოლეგამ პაველმა უკვე დაწერა ამის შესახებ მუხლი, არ გავიმეორებ. ამის ნაცვლად, მე გეტყვით, რატომ გჭირდებათ აუცილებლად Orchestrator MySQL-სთვის!

დავიწყოთ მთავარი კითხვით: ”როგორ გადავცვალოთ კოდი ახალ მანქანაზე, როდესაც მასტერი წავა?”

• ყველაზე მეტად VIP (ვირტუალური IP) სქემა მომწონს, ამაზე ქვემოთ ვისაუბრებთ. ეს არის უმარტივესი და ყველაზე აშკარა, თუმცა აქვს აშკარა შეზღუდვა: მასტერი, რომელსაც ჩვენ ვიტოვებთ, უნდა იყოს L2 სეგმენტში ახალი აპარატით, ანუ შეგვიძლია დავივიწყოთ მეორე DC. და, მეგობრულად, თუ დაიცავთ წესს, რომ დიდი L2 არის ბოროტება, რადგან L2 არის მხოლოდ თითო თაროზე, ხოლო L3 არის თაროებს შორის და ასეთ სქემას კიდევ უფრო მეტი შეზღუდვა აქვს.
• შეგიძლიათ დაწეროთ DNS სახელი კოდში და გადაჭრათ ის /etc/hosts-ის საშუალებით. ფაქტობრივად, რეზოლუცია არ იქნება. სქემის უპირატესობა: არ არსებობს პირველი მეთოდისთვის დამახასიათებელი შეზღუდვა, ანუ შესაძლებელია cross-DC-ის ორგანიზება. მაგრამ შემდეგ ჩნდება აშკარა კითხვა: რამდენად სწრაფად შეგვიძლია მივაწოდოთ ცვლილება /etc/host-ებს Puppet-Ansible-ის საშუალებით?
• შეგიძლიათ ოდნავ შეცვალოთ მეორე მეთოდი: დააინსტალირეთ ქეშირების DNS ყველა ვებ სერვერზე, რომლის მეშვეობითაც კოდი გადავა მთავარ მონაცემთა ბაზაში. თქვენ შეგიძლიათ დააყენოთ TTL 60 ამ ჩანაწერისთვის DNS-ში. როგორც ჩანს, თუ სწორად განხორციელდა, მეთოდი კარგია.
• სქემა სერვისის აღმოჩენით, რომელიც გულისხმობს კონსულის გამოყენებას და ა.შ.
• საინტერესო ვარიანტია ProxySQL. თქვენ უნდა გადაიყვანოთ მთელი ტრაფიკი MySQL-ზე ProxySQL-ის მეშვეობით; თავად ProxySQL-ს შეუძლია განსაზღვროს ვინ არის ოსტატი. სხვათა შორის, თქვენ შეგიძლიათ წაიკითხოთ ამ პროდუქტის გამოყენების ერთ-ერთი ვარიანტი ჩემს საიტზე მუხლი.

Github-ში მომუშავე Orchestrator-ის ავტორმა პირველი სქემა ჯერ VIP-ით განახორციელა, შემდეგ კი კონსულთან ერთად გადააკეთა სქემაში.

ტიპიური ინფრასტრუქტურის განლაგება:

მე დაუყოვნებლივ აღვწერ აშკარა სიტუაციებს, რომლებიც უნდა იქნას გათვალისწინებული:

• VIP მისამართი არ უნდა იყოს რეგისტრირებული კონფიგურაციაში რომელიმე სერვერზე. წარმოვიდგინოთ სიტუაცია: ოსტატმა გადატვირთა და სანამ ის იტვირთებოდა, ორკესტრი გადავიდა ფაილოვერის რეჟიმში და ერთ-ერთი სლავი მასტერად აქცია; შემდეგ ძველი ოსტატი გაიზარდა და ახლა VIP ორ მანქანაზეა. Ეს არის ცუდი.
• ორკესტრატორისთვის დაგჭირდებათ სკრიპტის დაწერა ძველი ოსტატისა და ახალი ოსტატის გამოძახებისთვის. ძველ მასტერზე თქვენ უნდა გაუშვათ ifdown, ხოლო ახალ მასტერზე - ifup vip. კარგი იქნება, რომ ამ სკრიპტში ასევე შევიტანოთ, რომ მარცხის შემთხვევაში, ძველი ოსტატის გადამრთველის პორტი უბრალოდ გამორთულია, რათა თავიდან აიცილოთ რაიმე გაყოფა.
• მას შემდეგ, რაც ორკესტრატორმა დაურეკა თქვენს სკრიპტს, რომ ჯერ ამოიღოთ VIP და/ან ჩააქროთ პორტი გადამრთველზე, შემდეგ კი გამოიძახოთ VIP ამაღლების სკრიპტი ახალ მასტერზე, არ დაგავიწყდეთ გამოიყენოთ arping ბრძანება, რათა ყველას უთხრათ, რომ ახალი VIP არის ახლა. აქ.
• ყველა სლავს უნდა ჰქონდეს read_only=1, და როგორც კი თქვენ დააწინაურებთ slave-ს ოსტატთან, მას უნდა ჰქონდეს read_only=0.
• არ დაგავიწყდეთ, რომ ნებისმიერი მონა, რომელიც ჩვენ ამისთვის ავირჩიეთ, შეიძლება გახდეს ბატონი (ორკესტრატორს აქვს მთელი უპირატესობის მექანიზმი, რომელი მონა განიხილოს პირველ რიგში ახალი ბატონის კანდიდატად, რომელი მეორე ადგილზე და რომელი მონა. არავითარ შემთხვევაში არ იყოს შერჩეული ოსტატი). თუ მონა ხდება ბატონი, მაშინ მასზე დარჩება მონას ტვირთი და დაემატება ბატონის ტვირთი, ეს გასათვალისწინებელია.

რატომ გჭირდებათ ორკესტრი, თუ არ გყავთ?

• ორკესტრატორს აქვს ძალიან მოსახერხებელი გრაფიკული ინტერფეისი, რომელიც აჩვენებს მთელ ტოპოლოგიას (იხილეთ ეკრანის სურათი ქვემოთ).
• ორკესტრატორს შეუძლია თვალყური ადევნოს, თუ რომელი სლავები ჩამორჩებიან და სად იშლება რეპლიკაცია (ჩვენ გვაქვს ორკესტრატორზე მიმაგრებული სკრიპტები SMS-ის გასაგზავნად).
• ორკესტრატორი გეუბნებათ რომელ მონებს აქვთ GTID ცდომილება.

ორკესტრატორის ინტერფეისი:

რა არის GTID შეცდომა?

ორკესტრის მუშაობისთვის ორი ძირითადი მოთხოვნაა:

• აუცილებელია, რომ ფსევდო GTID ჩართული იყოს MySQL კლასტერის ყველა მანქანაზე; ჩვენ ჩართული გვაქვს GTID.
• აუცილებელია, რომ ყველგან იყოს ერთი ტიპის ბინლოგი, შეგიძლიათ გამოიყენოთ განცხადება. ჩვენ გვქონდა კონფიგურაცია, რომელშიც ბატონს და სლავების უმეტესობას ჰქონდა Row, ხოლო ორი ისტორიულად დარჩა შერეულ რეჟიმში. შედეგად, ორკესტრატორს უბრალოდ არ სურდა ამ მონების დაკავშირება ახალ ბატონთან.

დაიმახსოვრე, რომ წარმოების მონაში ყველაზე მნიშვნელოვანი არის მისი თანმიმდევრულობა ბატონთან! თუ თქვენ გაქვთ ჩართული გლობალური ტრანზაქციის ID (GTID) როგორც თქვენს მთავარზე, ასევე სლავზე, მაშინ შეგიძლიათ გამოიყენოთ gtid_subset ფუნქცია, რათა გაარკვიოთ, რეალურად არის თუ არა შესრულებული იგივე მოთხოვნები მონაცემთა ცვლილების შესახებ ამ მანქანებზე. ამის შესახებ მეტი შეგიძლიათ წაიკითხოთ აქ.

ამრიგად, Orchestrator გაჩვენებთ GTID-ის შეცდომის მეშვეობით, რომ არის ტრანზაქციები მონაზე, რომელიც არ არის მასტერზე. Რატომ ხდება ეს?

• Read_only=1 არ არის ჩართული სლავზე, ვიღაც დაუკავშირდა და დაასრულა მოთხოვნა მონაცემთა შეცვლის შესახებ.
• Super_read_only=1 არ არის ჩართული სლავზე, შემდეგ ადმინი, რომელმაც სერვერი დააბნია, შევიდა და იქ შეასრულა მოთხოვნა.
• თუ გავითვალისწინებთ ორივე წინა პუნქტს, მაშინ არის კიდევ ერთი ხრიკი: MySQL-ში, ბინლოგების გარეცხვის მოთხოვნა ასევე მიდის ბინლოგში, ასე რომ, პირველ გარეცხვისას, GTID შეცდომა გამოჩნდება მასტერსა და ყველა სლავზე. როგორ ავიცილოთ თავიდან ეს? Perona-5.7.25-28-მა შემოიტანა binlog_skip_flush_commands=1 პარამეტრი, რომელიც კრძალავს ბინლოგებში flush ჩაწერას. არსებობს დადგენილი mysql.com ვებსაიტზე შეცდომა.

ნება მომეცით შევაჯამოთ ყოველივე ზემოთქმული. თუ ჯერ არ გსურთ ორკესტრატორის გამოყენება failover რეჟიმში, ჩადეთ იგი დაკვირვების რეჟიმში. შემდეგ ყოველთვის გექნებათ თქვენს თვალწინ MySQL მანქანების ურთიერთქმედების რუკა და ვიზუალური ინფორმაცია იმის შესახებ, თუ რა ტიპის რეპლიკაცია არის თითოეულ მანქანაზე, ჩამორჩებიან თუ არა სლავები და რაც მთავარია, რამდენად შეესაბამება ისინი ბატონს!

აშკარა კითხვაა: "როგორ უნდა მუშაობდეს ორკესტრი?" მან უნდა შეარჩიოს ახალი ოსტატი ამჟამინდელი სლავებიდან და შემდეგ ხელახლა დააკავშიროს მას ყველა სლავი (ეს არის ის, რისთვისაც საჭიროა GTID; თუ იყენებთ ძველ მექანიზმს binlog_name-ით და binlog_pos-ით, მაშინ გადართეთ სლავი ამჟამინდელი მასტერიდან ახალზე. უბრალოდ შეუძლებელია!). სანამ ორკესტრი გვეყოლებოდა, ერთხელ მომიწია ამ ყველაფრის ხელით გაკეთება. ძველი ბატონი ჩამოკიდებული იყო ადაპტეკის კონტროლერის გამო, მას 10-მდე მონა ჰყავდა. მე მჭირდებოდა VIP-ის გადაცემა ოსტატიდან ერთ-ერთ სლავზე და ყველა სხვა სლავის ხელახლა დაკავშირება. რამდენი კონსოლის გახსნა მომიწია, რამდენი ერთდროული ბრძანება შევიყვანე... ღამის 3 საათამდე მომიწია ლოდინი, ორის გარდა ყველა სლავიდან, პირველი მანქანა გავაკეთო ორი მასტერისგან, სასწრაფოდ დავამაგრო მეორე მანქანა. მას, ამიტომ მიამაგრეთ ყველა სხვა მონა ახალ ბატონს და დააბრუნეთ ტვირთი. ზოგადად, საშინელება...

როგორ მუშაობს ორკესტრატორი, როდესაც ის გადადის failover რეჟიმში? ეს ყველაზე ადვილად ილუსტრირებულია სიტუაციის მაგალითით, როდესაც ჩვენ გვსურს ოსტატი გავხადოთ უფრო მძლავრი, უფრო თანამედროვე მანქანა, ვიდრე ახლა გვაქვს.

ფიგურაში ნაჩვენებია პროცესის შუა ნაწილი. რა გაკეთდა უკვე ამ დრომდე? ჩვენ ვთქვით, რომ გვინდოდა რომელიმე მონა ახალ ბატონად გაგვეკეთებინა, ორკესტრატორმა უბრალოდ დაიწყო ყველა სხვა მონას მასთან დაკავშირება, ახალი ოსტატი მოქმედებდა როგორც სატრანზიტო მანქანა. ამ სქემით არანაირი შეცდომა არ ხდება, ყველა მონა მუშაობს, ორკესტრი აშორებს VIP-ს ძველ მასტერს, გადასცემს ახალს, აკეთებს read_only=0-ს და ივიწყებს ძველ მასტერს. ყველა! ჩვენი სერვისის შეფერხება არის VIP გადაცემის დრო, რომელიც შეადგენს 2-3 წამს.

დღეისთვის სულ ესაა, მადლობა ყველას. მალე მეორე სტატია იქნება ორკესტრატორის შესახებ. ცნობილ საბჭოთა ფილმში "გარაჟი", ერთმა პერსონაჟმა თქვა: "მე არ წავიდოდი მასთან დაზვერვაზე!" ასე რომ, ორკესტრატორო, შენთან ერთად წავიდოდი დაზვერვაზე!

წყარო: www.habr.com