Citymobil-ში ჩვენ ვიყენებთ MySQL მონაცემთა ბაზას, როგორც მონაცემთა ძირითად მუდმივ შესანახად. ჩვენ გვაქვს მონაცემთა ბაზის რამდენიმე კლასტერი სხვადასხვა სერვისებისა და მიზნებისთვის.

ოსტატის მუდმივი ხელმისაწვდომობა არის მთელი სისტემის და მისი ცალკეული ნაწილების მუშაობის კრიტიკული მაჩვენებელი. კლასტერის ავტომატური აღდგენა ძირითადი მარცხის შემთხვევაში მნიშვნელოვნად ამცირებს ინციდენტზე რეაგირების დროს და სისტემის გაუმართაობას. ამ სტატიაში მე გადავხედავ MySQL კლასტერის მაღალი ხელმისაწვდომობის (HA) დიზაინს, რომელიც დაფუძნებულია MySQL ორკესტრი და ვირტუალური IP მისამართები (VIP).

HA გადაწყვეტა VIP-ზე დაფუძნებული

პირველ რიგში, მოკლედ გეტყვით რა არის ჩვენი მონაცემთა შენახვის სისტემა.

ჩვენ ვიყენებთ კლასიკურ რეპლიკაციის სქემას ერთი ჩასაწერად ხელმისაწვდომ ოსტატთან და რამდენიმე წაკითხვადი რეპლიკებით. კლასტერი შეიძლება შეიცავდეს შუალედურ მასტერს - კვანძს, რომელიც არის როგორც რეპლიკა, ასევე მასტერი სხვებისთვის. კლიენტებს წვდომა აქვთ რეპლიკაზე HAProxy-ის საშუალებით, რაც საშუალებას იძლევა თანაბარი დატვირთვის განაწილება და მარტივი მასშტაბირება. HAProxy-ის გამოყენება განპირობებულია ისტორიული მიზეზებით და ჩვენ ამჟამად ProxySQL-ზე მიგრაციის პროცესში ვართ.

რეპლიკაცია ხორციელდება ნახევრად სინქრონულ რეჟიმში საფუძველზე GTID. ეს ნიშნავს, რომ მინიმუმ ერთმა რეპლიკამ უნდა დაარეგისტრიროს ტრანზაქცია, სანამ ის წარმატებულად ჩაითვლება. რეპლიკაციის ეს რეჟიმი უზრუნველყოფს ოპტიმალურ ბალანსს შესრულებასა და მონაცემთა უსაფრთხოებას შორის ძირითადი კვანძის უკმარისობის შემთხვევაში. ძირითადად ყველა ცვლილება გადადის მასტერიდან რეპლიკაზე გამოყენებით Row Based Replication (RBR), მაგრამ ზოგიერთ კვანძს შეიძლება ჰქონდეს mixed binlog format.

ორკესტრატორი პერიოდულად ანახლებს კასეტური ტოპოლოგიის მდგომარეობას, აანალიზებს მიღებულ ინფორმაციას და თუ პრობლემები წარმოიქმნება, შეუძლია ავტომატური აღდგენის პროცედურის დაწყება. დეველოპერი პასუხისმგებელია თავად პროცედურაზე, რადგან ის შეიძლება განხორციელდეს სხვადასხვა გზით: VIP-ის, DNS-ის საფუძველზე, სერვისის აღმოჩენის სერვისების ან თვითდაწერილი მექანიზმების გამოყენებით.

ოსტატის აღდგენის ერთი მარტივი გზა, თუ ის ვერ მოხერხდა, არის მცურავი VIP მისამართების გამოყენება.

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

• VIP არის IP მისამართი, რომელიც არ არის დაკავშირებული კონკრეტულ ფიზიკურ ქსელურ ინტერფეისთან. თუ კვანძი ვერ მოხერხდა ან დაგეგმილი მოვლის დროს, ჩვენ შეგვიძლია გადავიტანოთ VIP სხვა რესურსზე მინიმალური შეფერხებით.
• ვირტუალური IP მისამართის გათავისუფლება და გაცემა იაფი და სწრაფი ოპერაციაა.
• VIP-თან მუშაობისთვის გჭირდებათ სერვერზე წვდომა SSH-ის საშუალებით, ან სპეციალური კომუნალური საშუალებების გამოყენება, მაგალითად, keepalived.

მოდით შევხედოთ ჩვენს ოსტატთან შესაძლო პრობლემებს და წარმოვიდგინოთ, როგორ უნდა იმუშაოს ავტომატური აღდგენის მექანიზმი.

ქსელის დაკავშირება მასტერთან გაქრა, ან წარმოიშვა პრობლემა აპარატურის დონეზე და სერვერი მიუწვდომელია

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 ხსნარის ზოგადი დიაგრამა წარმოდგენილია ქვემოთ.

ახალი ოსტატის არჩევა

ორკესტრი საკმარისად ჭკვიანია და ცდილობს აირჩიოს ყველაზე შესაფერისი რეპლიკა როგორც ახალი ოსტატი შემდეგი კრიტერიუმების მიხედვით:

• რეპლიკა ჩამორჩება მასტერს;
• Master-ისა და რეპლიკას MySQL ვერსია;
• რეპლიკაციის ტიპი (RBR, SBR ან შერეული);
• მდებარეობა იმავე ან სხვადასხვა მონაცემთა ცენტრებში;
• ხელმისაწვდომობა errant GTID - ტრანზაქციები, რომლებიც შესრულდა რეპლიკაზე და არ არის მასტერზე;
• ასევე გათვალისწინებულია საბაჟო შერჩევის წესები.

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

რეაგირებისა და აღდგენის დრო

ინციდენტის შემთხვევაში მნიშვნელოვანია სისტემის შეფერხების მინიმუმამდე შემცირება, ამიტომ განვიხილოთ MySQL პარამეტრები, რომლებიც გავლენას ახდენენ ორკესტრატორის მიერ კასეტური ტოპოლოგიის შექმნასა და განახლებაზე:

• slave_net_timeout — წამების რაოდენობა, რომლის დროსაც რეპლიკა ელოდება ახალ მონაცემებს ან გულისცემის სიგნალს მასტერისგან, სანამ კავშირი დაკარგული იქნება და ხელახლა დაკავშირდება. რაც უფრო დაბალია მნიშვნელობა, მით უფრო სწრაფად შეუძლია რეპლიკა განსაზღვროს, რომ მასტერთან კომუნიკაცია გატეხილია. ჩვენ დავაყენეთ ეს მნიშვნელობა 5 წამზე.
• MASTER_CONNECT_RETRY — წამების რაოდენობა ხელახლა დაკავშირების მცდელობებს შორის. ქსელის პრობლემების შემთხვევაში, ამ პარამეტრის დაბალი მნიშვნელობა საშუალებას მისცემს სწრაფ ხელახლა დაკავშირებას და ხელს შეუშლის კლასტერის აღდგენის პროცესის დაწყებას. რეკომენდებული მნიშვნელობა არის 1 წამი.
• MASTER_RETRY_COUNT — ხელახალი დაკავშირების მცდელობების მაქსიმალური რაოდენობა.
• MASTER_HEARTBEAT_PERIOD — ინტერვალი წამებში, რის შემდეგაც ოსტატი აგზავნის გულისცემის სიგნალს. ნაგულისხმევი მნიშვნელობის ნახევარი slave_net_timeout.

ორკესტრის ვარიანტები:

• DelayMasterPromotionIfSQLThreadNotUpToDate - თუ თანაბარი true, მაშინ სამაგისტრო როლი არ იქნება გამოყენებული კანდიდატის რეპლიკაზე, სანამ ასლის SQL თემა არ დაასრულებს ყველა გამოუყენებელ ტრანზაქციას სარელეო ჟურნალიდან. ჩვენ ვიყენებთ ამ ვარიანტს, რათა თავიდან ავიცილოთ ტრანზაქციების დაკარგვა, როდესაც ყველა კანდიდატის რეპლიკა ჩამორჩება.
• InstancePollSeconds — ტოპოლოგიის აგების და განახლების სიხშირე.
• RecoveryPollSeconds — ტოპოლოგიის ანალიზის სიხშირე. თუ პრობლემა გამოვლინდა, ტოპოლოგიის აღდგენა იწყება. ეს მუდმივი, უდრის 1 წამს.

ყოველი კლასტერული კვანძი გამოკითხულია ორკესტრის მიერ ერთხელ ერთხელ InstancePollSeconds წამი როდესაც პრობლემა აღმოჩენილია, კლასტერული მდგომარეობა იძულებულია განახლებულია, და შემდეგ მიიღება საბოლოო გადაწყვეტილება აღდგენის ჩატარებაზე. მონაცემთა ბაზისა და ორკესტრატორის სხვადასხვა პარამეტრებზე ექსპერიმენტებით, ჩვენ შევძელით პასუხის და აღდგენის დრო 30 წამამდე შემცირება.

სატესტო სტენდი

ჩვენ დავიწყეთ HA სქემის ტესტირება ლოკალური შემუშავებით ტესტის სკამი და შემდგომი განხორციელება სატესტო და საწარმოო გარემოში. ლოკალური სტენდი სრულად ავტომატიზირებულია Docker-ზე დაფუძნებული და საშუალებას გაძლევთ ექსპერიმენტი ჩაატაროთ ორკესტრისა და ქსელის კონფიგურაციაზე, გააფართოვოთ კლასტერი 2-3 სერვერიდან რამდენიმე ათეულამდე და ჩაატაროთ სავარჯიშოები უსაფრთხო გარემოში.

სავარჯიშოების დროს ვირჩევთ პრობლემის ემულაციის ერთ-ერთ მეთოდს: მყისიერად ესვრით მასტერს გამოყენებით kill -9, რბილად შეწყვიტე პროცესი და შეაჩერე სერვერი (docker-compose stop), ქსელის პრობლემების სიმულაცია გამოყენებით iptables -j REJECT ან iptables -j DROP. ჩვენ ველოდებით შემდეგ შედეგებს:

• ორკესტრი აღმოაჩენს მასტერთან არსებულ პრობლემებს და განაახლებს ტოპოლოგიას არაუმეტეს 10 წამში;
• აღდგენის პროცედურა ავტომატურად დაიწყება: შეიცვლება ქსელის კონფიგურაცია, ოსტატის როლი გადავა რეპლიკაზე, ტოპოლოგია ხელახლა აშენდება;
• ახალი ოსტატი გახდება ჩასაწერი, ცოცხალი რეპლიკა არ დაიკარგება აღდგენის პროცესში;
• დაიწყება მონაცემების ახალ მასტერზე ჩაწერა და ტირაჟირება;
• აღდგენის მთლიანი დრო იქნება არაუმეტეს 30 წამი.

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

დასკვნები

ძირითადი შენახვის სისტემის კვანძის ჯანმრთელობა არის SRE და ოპერაციების გუნდის ერთ-ერთი მთავარი ამოცანა. VIP-ზე დაფუძნებული ორკესტრატორისა და HA გადაწყვეტის განხორციელებამ მოგვცა შემდეგი შედეგების მიღწევა:

• მონაცემთა ბაზის კლასტერის ტოპოლოგიასთან დაკავშირებული პრობლემების საიმედო გამოვლენა;
• ავტომატური და სწრაფი რეაგირება ოსტატთან დაკავშირებულ ინციდენტებზე, რაც ამცირებს სისტემის გაუმართაობას.

თუმცა, გამოსავალს აქვს თავისი შეზღუდვები და უარყოფითი მხარეები:

• HA სქემის სკალირება რამდენიმე მონაცემთა ცენტრამდე საჭიროებს ერთ L2 ქსელს მათ შორის;
• ახალ მასტერზე VIP-ის მინიჭებამდე უნდა გავათავისუფლოთ ის ძველზე. პროცესი თანმიმდევრულია, რაც ზრდის აღდგენის დროს;
• VIP-ის გამოშვება მოითხოვს SSH წვდომას სერვერზე, ან დისტანციური პროცედურების გამოძახების სხვა მეთოდს. ვინაიდან სერვერს ან მონაცემთა ბაზას აქვს პრობლემები, რამაც გამოიწვია აღდგენის პროცესი, ჩვენ არ შეგვიძლია დარწმუნებული ვიყოთ, რომ VIP-ის ამოღება წარმატებით დასრულდება. და ამან შეიძლება გამოიწვიოს ორი სერვერის გამოჩენა იგივე ვირტუალური IP მისამართით და პრობლემა split brain.

რომ თავიდან ავიცილოთ split brain, შეგიძლიათ გამოიყენოთ მეთოდი სტონიტი ("Shoot The Other Node In The Head"), რომელიც მთლიანად იზოლირებს ან გამორთავს პრობლემურ კვანძს. არსებობს კლასტერების მაღალი ხელმისაწვდომობის განხორციელების სხვა გზები: VIP და DNS-ის კომბინაცია, სერვისების აღმოჩენა და პროქსი სერვისები, სინქრონული რეპლიკაცია და სხვა მეთოდები, რომლებსაც აქვთ საკუთარი უარყოფითი მხარეები და უპირატესობები.

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

წყარო: www.habr.com