Patroni Failure Stories ან როგორ დაამტვრიოთ თქვენი PostgreSQL კლასტერი. ალექსეი ლესოვსკი

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

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

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

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

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

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

და მცირე უარი პასუხისმგებლობაზე, სანამ დავიწყებთ ჩვენს მოხსენებას.

ყველა ეს პრობლემა, რაც შეგვხვდა, ფუნქციონირების პირველ 6-7-8 თვეში გვქონდა. დროთა განმავლობაში მივედით ჩვენს შიდა საუკეთესო პრაქტიკამდე. და ჩვენი პრობლემები გაქრა. მაშასადამე, მოხსენება დაახლოებით ექვსი თვის წინ გამოცხადდა, როცა ეს ყველაფერი ჩემს თავში ახალი იყო და ეს ყველაფერი მშვენივრად მახსოვდა.

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

რა არის პატრონი?

• ეს არის შაბლონი HA-ს მშენებლობისთვის. ასე წერია დოკუმენტაციაში. და ჩემი აზრით, ეს არის ძალიან სწორი განმარტება. პატრონი არ არის ვერცხლის ტყვია, რომელიც ყველა პრობლემას მოგიგვარებს, ანუ შენ უნდა ეცადო იმუშაო და სარგებელი მოიტანო.
• ეს არის აგენტის სერვისი, რომელიც დაინსტალირებულია მონაცემთა ბაზის ყველა სერვისზე და არის ერთგვარი init სისტემა თქვენი Postgres-ისთვის. ის იწყებს Postgres-ს, აჩერებს, გადატვირთავს, ახდენს ხელახლა კონფიგურაციას და ცვლის თქვენი კლასტერის ტოპოლოგიას.
• შესაბამისად, კლასტერის მდგომარეობის შესანახად, მისი ამჟამინდელი წარმოდგენა, როგორც ჩანს, საჭიროა გარკვეული შენახვა. და ამ თვალსაზრისით პატრონმა გარე სისტემაში მდგომარეობის შენახვის გზა აიღო. ეს არის განაწილებული კონფიგურაციის შენახვის სისტემა. ეს შეიძლება იყოს Etcd, Consul, ZooKeeper ან kubernetes Etcd, ანუ ამ ვარიანტებიდან ერთ-ერთი.
• და Patroni-ის ერთ-ერთი მახასიათებელია ის, რომ თქვენ იღებთ ავტოფილერს ყუთიდან, მხოლოდ მისი დაყენებით. თუ შედარებისთვის ავიღებთ Repmgr-ს, მაშინ ფილერი შედის იქ. Repmgr-ით ვიღებთ გადართვას, მაგრამ თუ გვინდა ავტოფილერი, მაშინ მისი დამატებით კონფიგურაცია გვჭირდება. პატრონს უკვე აქვს ავტომატური ფილტრი.
• და კიდევ ბევრი რამ არის. მაგალითად, კონფიგურაციების შენარჩუნება, ახალი რეპლიკების ჩამოსხმა, სარეზერვო და ა.შ. მაგრამ ეს სცილდება მოხსენების ფარგლებს, ამაზე არ ვისაუბრებ.

და მცირე შედეგი არის ის, რომ Patroni-ს მთავარი ამოცანაა ავტოფაილის კარგად და საიმედოდ გაკეთება, რათა ჩვენი კლასტერი დარჩეს მოქმედი და აპლიკაციამ არ შეამჩნია ცვლილებები კლასტერის ტოპოლოგიაში.

მაგრამ როდესაც ჩვენ ვიწყებთ Patroni-ს გამოყენებას, ჩვენი სისტემა ცოტა უფრო რთული ხდება. თუ ადრე გვქონდა Postgres, მაშინ Patroni-ის გამოყენებისას ვიღებთ თავად Patroni-ს, ვიღებთ DCS-ს, სადაც სახელმწიფო ინახება. და ეს ყველაფერი როგორმე უნდა იმუშაოს. ასე რომ, რა შეიძლება მოხდეს არასწორი?

შეიძლება შესვენება:

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

ყველა ამ პუნქტს განვიხილავ მოხსენებაში.

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

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

მაშ ასე, იყო ფაილერი, მოდი წავიდეთ საქმეზე, რაც მოხდა.

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

მაგრამ შემავსებელი ყოველთვის არ არის მყისიერი, ანუ მას არ სჭირდება დროის ერთეული, ის შეიძლება გადაიდოს. ეს შეიძლება იყოს ხანგრძლივი.

მაშასადამე, მას აქვს დაწყების დრო და დასრულების დრო, ანუ ეს არის უწყვეტი მოვლენა. და ჩვენ ყველა მოვლენას ვყოფთ სამ ინტერვალად: გვაქვს დრო ფილერამდე, შემავსებლის დროს და შემავსებლის შემდეგ. ანუ ჩვენ განვიხილავთ ყველა მოვლენას ამ ვადებში.

და პირველი რაც მოხდა, როდესაც ფილერი მოხდა, ჩვენ ვეძებთ მომხდარის მიზეზს, რა იყო მიზეზი იმისა, რამაც გამოიწვია ფილერი.

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

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

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

თუ გადავხედავთ Patroni logs-ს, დავინახავთ, რომ გვაქვს ბევრი შეცდომა, ტაიმაუტი, ანუ Patroni აგენტი ვერ მუშაობს DCS-თან. ამ შემთხვევაში, ეს არის კონსული აგენტი, რომელიც კომუნიკაციას უწევს პორტ 8500-ს.

და პრობლემა აქ არის ის, რომ Patroni და მონაცემთა ბაზა მუშაობს ერთ ჰოსტზე. და Consul სერვერები გაშვებული იქნა იმავე კვანძზე. სერვერზე დატვირთვის შექმნით პრობლემები შევქმენით კონსულის სერვერებზეც. მათ არ შეეძლოთ სათანადო კომუნიკაცია.

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

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

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

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

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

პირველი პრობლემა, როგორც გესმით, მარტივია. ავიღეთ და დავაყენეთ DCS ბაზასთან ერთად, პრობლემა შეგვექმნა.

მეორე პრობლემა პირველის მსგავსია. მსგავსია იმით, რომ ჩვენ კვლავ გვაქვს DCS სისტემასთან თავსებადობის პრობლემები.

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

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

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

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

და როდესაც გადავედით იმ წერტილამდე, სადაც შეცდომები დაიწყო, ჩვენ ვხედავთ, რომ ჩვენ გვქონდა ავტომატური ფაილების გადატანა. და რადგან ჩვენი შეცდომები დაკავშირებული იყო DCS-თან ინტერაქციასთან და ჩვენს შემთხვევაში ჩვენ გამოვიყენეთ Consul, ჩვენ ასევე ვუყურებთ კონსულის ჟურნალებს, რა მოხდა იქ.

უხეშად რომ შევადაროთ საკონსულო ჟურნალის დრო და დრო, ჩვენ ვხედავთ, რომ კონსულის კლასტერში ჩვენმა მეზობლებმა დაიწყეს ეჭვი კონსულის კლასტერის სხვა წევრების არსებობაში.

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

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

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

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

• უმარტივესი ვარიანტი, რომელიც, ჩემი აზრით, დოკუმენტაციაშიც კი წერია, არის საკონსულო ჩეკების გამორთვა, ანუ უბრალოდ ცარიელი მასივის გავლა. და ჩვენ ვეუბნებით კონსულის აგენტს, არ გამოიყენოს ჩეკები. ამ შემოწმებებით, ჩვენ შეგვიძლია უგულებელვყოთ ეს ქსელის ქარიშხალი და არ წამოვიწყოთ ფაილერი.
• კიდევ ერთი ვარიანტია გაორმაგებული შემოწმება raft_multiplier. ეს არის თავად Consul სერვერის პარამეტრი. ნაგულისხმევად, ის დაყენებულია 5-ზე. ეს მნიშვნელობა რეკომენდირებულია დოკუმენტაციის მიერ დადგმული გარემოსთვის. სინამდვილეში, ეს გავლენას ახდენს საკონსულო ქსელის წევრებს შორის შეტყობინებების სიხშირეზე. სინამდვილეში, ეს პარამეტრი გავლენას ახდენს საკონსულო კლასტერის წევრებს შორის სერვისული კომუნიკაციის სიჩქარეზე. წარმოებისთვის კი უკვე რეკომენდებულია მისი შემცირება ისე, რომ კვანძებმა უფრო ხშირად გაცვალონ შეტყობინებები.
• კიდევ ერთი ვარიანტი, რომელიც ჩვენ გამოვიყენეთ, არის საკონსულო პროცესების პრიორიტეტის გაზრდა ოპერაციული სისტემის პროცესების განრიგის სხვა პროცესებს შორის. არსებობს ასეთი "მშვენიერი" პარამეტრი, ის უბრალოდ განსაზღვრავს პროცესების პრიორიტეტს, რომელსაც მხედველობაში იღებს OS განრიგის მიერ დაგეგმვისას. ჩვენ ასევე შევამცირეთ სასიამოვნო ღირებულება კონსულის აგენტებისთვის, ე.ი. გაიზარდა პრიორიტეტი ისე, რომ ოპერაციულმა სისტემამ კონსულ პროცესებს მეტი დრო მისცეს სამუშაოდ და მათი კოდის შესასრულებლად. ჩვენს შემთხვევაში, ამან გადაჭრა ჩვენი პრობლემა.
• კიდევ ერთი ვარიანტია არ გამოიყენოთ კონსული. მე მყავს მეგობარი, რომელიც არის Etcd-ის დიდი მხარდამჭერი. და ჩვენ რეგულარულად ვკამათობთ მასთან, რომელია უკეთესი Etcd თუ Consul. მაგრამ იმ თვალსაზრისით, თუ რომელია უკეთესი, ჩვენ ჩვეულებრივ ვეთანხმებით მას, რომ კონსულს ჰყავს აგენტი, რომელიც უნდა იმუშაოს თითოეულ კვანძზე მონაცემთა ბაზაში. ანუ პატრონის ურთიერთქმედება საკონსულო კლასტერთან გადის ამ აგენტზე. და ეს აგენტი ხდება ბოთლი. თუ რამე დაემართება აგენტს, მაშინ პატრონი ვეღარ იმუშავებს კონსულის კლასტერთან. და ეს არის პრობლემა. Etcd გეგმაში არ არის აგენტი. პატრონს შეუძლია პირდაპირ იმუშაოს Etcd სერვერების სიათან და უკვე დაუკავშირდეს მათ. ამ მხრივ, თუ თქვენ იყენებთ Etcd-ს თქვენს კომპანიაში, მაშინ Etcd ალბათ უკეთესი არჩევანი იქნება ვიდრე Consul. მაგრამ ჩვენ, ჩვენს მომხმარებლებს, ყოველთვის შეზღუდული ვართ იმით, რაც კლიენტმა აირჩია და იყენებს. და ჩვენ გვყავს კონსული უმეტესწილად ყველა კლიენტისთვის.
• და ბოლო წერტილი არის პარამეტრების მნიშვნელობების გადახედვა. ჩვენ შეგვიძლია ამ პარამეტრების ამაღლება იმ იმედით, რომ ჩვენი მოკლევადიანი ქსელის პრობლემები იქნება ხანმოკლე და არ დაეცემა ამ პარამეტრების დიაპაზონს. ამ გზით ჩვენ შეგვიძლია შევამციროთ Patroni-ის აგრესიულობა ავტომატურ ფაილზე, თუ რაიმე ქსელის პრობლემა წარმოიქმნება.

ვფიქრობ, ბევრი ვინც იყენებს Patroni-ს იცნობს ამ ბრძანებას.

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

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

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

და ჩვენ უნდა შევხედოთ რეპლიკას, რომელიც ჩამოვარდა და რომელიც არ არის კლასტერში. ვხსნით Patroni log-ებს და ვხედავთ, რომ გვქონდა პრობლემა კლასტერთან დაკავშირების პროცესში pg_rewind ეტაპზე. კლასტერთან დასაკავშირებლად, თქვენ უნდა გადაახვიოთ ტრანზაქციის ჟურნალი, მოითხოვოთ მასტერისგან საჭირო ტრანზაქციის ჟურნალი და გამოიყენოთ იგი მასტერთან დასაჭერად.

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

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

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

რა არის ვარიანტი?

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

მაგრამ აქ არის პრობლემა, რომ როდესაც მასტერი მიდის რეპლიკაზე, ის შლის სლოტებს და შლის WAL სეგმენტებს სლოტებთან ერთად. და ამ პრობლემის აღმოსაფხვრელად გადავწყვიტეთ wal_keep_segments პარამეტრის გაზრდა. ნაგულისხმევად არის 8 სეგმენტი. ჩვენ გავზარდეთ 1-მდე და შევხედეთ, რამდენი თავისუფალი ადგილი გვქონდა. და ჩვენ შევწირეთ 000 გიგაბაიტი wal_keep_segments-ისთვის. ანუ გადართვისას ჩვენ ყოველთვის გვაქვს 16 გიგაბაიტი ტრანზაქციის ჟურნალის რეზერვი ყველა კვანძზე.

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

ჩვენ გვაქვს საწარმოო ბაზა. უკვე მიმდინარეობს პროექტები.

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

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

გასაგებია, რომ pg_rewind-მა გამოტოვა ისინი. ჩვენ მაშინვე მივხვდით ამას, მაგრამ წავედით, რომ გვენახა რა ხდებოდა.

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

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

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

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

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

მაგრამ რა გავარკვიეთ ჩვენთვის?

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

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

გარდა ამისა, არის "maximum_lag_on_failover" პარამეტრი. ნაგულისხმევად, თუ მეხსიერება მემსახურება, ამ პარამეტრს აქვს 1 მეგაბაიტის მნიშვნელობა.

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

მაგრამ არის პრობლემა, რომ რეპლიკაციის ჩამორჩენა Patroni კლასტერში და DCS განახლებულია გარკვეული ინტერვალით. ვფიქრობ, 30 წამი არის ნაგულისხმევი ttl მნიშვნელობა.

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

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

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

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

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

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

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

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

ჩვენ შევხედეთ სისტემის dmesg-ს (ბირთის ჟურნალი). და დავინახეთ, რომ ერთ-ერთ დისკთან გვაქვს პრობლემები. დისკის ქვესისტემა იყო პროგრამული Raid. ჩვენ გადავხედეთ /proc/mdstat-ს და დავინახეთ, რომ ერთი დისკი გვაკლდა. ანუ არის 8 დისკის Raid, ერთი გვაკლია. თუ ყურადღებით დააკვირდებით სლაიდს, მაშინ გამოსავალში ხედავთ, რომ იქ sde არ გვაქვს. ჩვენთან, პირობითად რომ ვთქვათ, დისკი ამოვარდა. ამან გამოიწვია დისკის პრობლემები და აპლიკაციებს ასევე შეექმნათ პრობლემები Postgres კლასტერთან მუშაობისას.

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

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

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

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

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

იყო კავშირების შეწყვეტა, ანუ კლიენტები დახეული.

იყო სხვადასხვა სიმძიმის ბლოკირება.

და, შესაბამისად, დისკის ქვესისტემა არ არის ძალიან მგრძნობიარე.

და ჩემთვის ყველაზე იდუმალი რამ არის დაუყოვნებელი გამორთვის მოთხოვნა, რომელიც ჩამოვიდა. Postgres-ს აქვს გამორთვის სამი რეჟიმი:

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

ვინ გაგზავნა ეს სიგნალი? Postgres-ის ფონური პროცესები არ უგზავნიან ასეთ სიგნალებს ერთმანეთს, ანუ ეს არის kill-9. ასეთ რაღაცებს არ უგზავნიან ერთმანეთს, მხოლოდ ასეთ რაღაცეებზე რეაგირებენ, ანუ ეს არის Postgres-ის გადაუდებელი გადატვირთვა. ვინ გამოაგზავნა, არ ვიცი.

გადავხედე "ბოლო" ბრძანებას და დავინახე ერთი ადამიანი, რომელიც ასევე შემოვიდა ამ სერვერზე ჩვენთან ერთად, მაგრამ ძალიან მორცხვი ვიყავი კითხვის დასმა. ალბათ ეს იყო მოკვლა -9. მე დავინახავდი მოკვლას -9-ს ჟურნალებში, რადგან Postgres ამბობს, რომ დასჭირდა kill -9, მაგრამ მე არ მინახავს ეს ჟურნალებში.

შორს რომ გავიხედე, დავინახე, რომ პატრონი საკმაოდ დიდხანს არ წერდა ჟურნალს - 54 წამი. და თუ შევადარებთ ორ დროის ნიშანს, არ იყო შეტყობინებები დაახლოებით 54 წამის განმავლობაში.

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

ჩვენ გვაქვს რეპლიკა, რომელიც გახდა ოსტატი. და არის მეორე პასუხი. და იყო პრობლემები მეორე რეპლიკასთან დაკავშირებით. მან სცადა ხელახლა კონფიგურაცია. როგორც მივხვდი, მან სცადა შეცვალოს recovery.conf, გადატვირთე Postgres და დაუკავშირდეს ახალ მასტერს. ის ყოველ 10 წამში წერს შეტყობინებებს, რომ ცდილობს, მაგრამ არ გამოსდის.

და ამ მცდელობების დროს, მყისიერი გამორთვის სიგნალი მოდის ძველ ოსტატთან. სამაგისტრო გადატვირთვაა. ასევე აღდგენა ჩერდება, რადგან ძველი ოსტატი გადატვირთავს. ანუ რეპლიკა ვერ უკავშირდება მას, რადგან ის გამორთვის რეჟიმშია.

რაღაც მომენტში ის მუშაობდა, მაგრამ რეპლიკაცია არ დაწყებულა.

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

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

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

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

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

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

მეგონა ხელახლა გადატვირთავდი. ხელახლა გადავტვირთე Patroni და Postgres კი არ გავატარე, მაგრამ Patroni-ს გადავტვირთე იმ იმედით, რომ ჯადოსნურად დაიწყებდა მონაცემთა ბაზას.

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

და მერე აზრზე ვარ - რა მოხდება, თუ Postgres-ს გადატვირთავ, ამ დროს ვაკეთებ გამშვებ პუნქტს მიმდინარე მასტერზე, რომ ტრანზაქციის ჟურნალის წერტილი ოდნავ წინ გადავიტანო, რომ აღდგენა სხვა მომენტიდან დაიწყოს? გარდა ამისა, ჩვენ ჯერ კიდევ გვქონდა WAL-ის მარაგი.

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

ჩემთვის ასეთი პრობლემა ერთ-ერთი ყველაზე იდუმალი პრობლემაა, რაზეც ახლაც თავს ვაბნევ, რა მოხდა იქ რეალურად.

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

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

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

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

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

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

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

როგორ მივუდგე დიაგნოზის საკითხს? მოხდა ისე, რომ ჩვენ ვმუშაობთ სხვადასხვა კლიენტებთან და არავის აქვს ELK სტეკი და ლოგის დალაგება გვიწევს 6 კონსოლის და 2 ჩანართის გახსნით. ერთ ჩანართში ეს არის Patroni ჟურნალები თითოეული კვანძისთვის, მეორე ჩანართში ეს არის Consul logs ან Postgres საჭიროების შემთხვევაში. ამის დიაგნოსტიკა ძალიან რთულია.

რა მიდგომები შევიმუშავე? პირველ რიგში, მე ყოველთვის ვუყურებ, როდის მოვიდა ფაილერი. და ჩემთვის ეს წყალგამყოფია. მე ვუყურებ, რა მოხდა ფაილერამდე, შემავსებლის დროს და შემავსებლის შემდეგ. ფაილის გადატანას აქვს ორი ნიშანი: ეს არის დაწყების და დასრულების დრო.

შემდეგ, მე ვეძებ ჟურნალებში მოვლენებს შემავსებლის წინ, რომლებიც წინ უძღოდა ფაილერს, ანუ ვეძებ მიზეზებს, რის გამოც მოხდა ფაილი.

და ეს იძლევა სურათს იმის გაგების შესახებ, თუ რა მოხდა და რა შეიძლება გაკეთდეს მომავალში, რომ არ მოხდეს ასეთი გარემოებები (და შედეგად, არ არსებობს შემავსებელი).

და სად ვიყურებით ჩვეულებრივ? ვუყურებ:

• ჯერ პატრონის მორები.
• შემდეგი, მე ვუყურებ Postgres-ის ლოგებს, ან DCS-ის ჟურნალებს, იმისდა მიხედვით, თუ რა იყო ნაპოვნი Patroni-ის ჟურნალებში.
• და სისტემური ჟურნალი ასევე ზოგჯერ იძლევა იმის გაგებას, თუ რა გამოიწვია შემავსებელი.

როგორ ვგრძნობ პატრონს? პატრონთან ძალიან კარგი ურთიერთობა მაქვს. ჩემი აზრით, ეს არის საუკეთესო, რაც დღეს არსებობს. ბევრი სხვა პროდუქტი ვიცი. ესენია Stolon, Repmgr, Pg_auto_failover, PAF. 4 ხელსაწყო. ყველა ვცადე. პატრონი ჩემი ფავორიტია.

თუ მკითხავენ: „პატრონს გირჩევ?“. მე ვიტყვი დიახ, რადგან მომწონს პატრონი. და ვფიქრობ, ვისწავლე მისი მომზადება.

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

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

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

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

Სულ ეს არის. თუ თქვენ გაქვთ შეკითხვები, ჰკითხეთ.

კითხვები

გმადლობთ ანგარიშისთვის! თუ ფაილერის შემდეგ თქვენ ჯერ კიდევ გჭირდებათ იქ ძალიან ფრთხილად შეხედვა, მაშინ რატომ გვჭირდება ავტომატური შემავსებელი?

იმიტომ რომ ახალი რაღაცაა. ჩვენ მხოლოდ ერთი წელი ვიყავით მასთან. ჯობია იყოს უსაფრთხო. ჩვენ გვინდა, რომ შევიდეთ და დავინახოთ, რომ ყველაფერი ისე გამოვიდა, როგორც უნდა. ეს არის ზრდასრულთა უნდობლობის დონე - სჯობს გადაამოწმოთ და ნახოთ.

მაგალითად, დილით წავედით და ვნახეთ, არა?

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

დიდი მადლობა!

დიდი მადლობა შესანიშნავი ისტორიისთვის! თუ DCS კლასტერი გადავიტანეთ სადმე Postgres კლასტერიდან შორს, მაშინ ამ კლასტერსაც პერიოდულად სჭირდება სერვისი? რა არის საუკეთესო პრაქტიკა, რომლითაც საჭიროა DCS კლასტერის ზოგიერთი ნაწილის გამორთვა, რაიმე მათთან დაკავშირებული და ა.შ.? როგორ გადარჩება მთელი ეს სტრუქტურა? და როგორ აკეთებ ამ საქმეებს?

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

ანუ სწორად მივხვდი, რომ ჰოსტებთან რაიმეს გაკეთებამდე მჭირდება პატრონის გამორთვა, ფილერის გათიშვა, ყველაფრის გამორთვა?

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

დიდი მადლობა!

დიდი მადლობა თქვენი ანგარიშისთვის! როგორ გრძნობს პროდუქტის გუნდი მონაცემების დაკარგვას?

პროდუქტის გუნდებს არ აინტერესებთ და გუნდის ლიდერები შეშფოთებულნი არიან.

რა გარანტიები არსებობს?

გარანტიები ძალიან რთულია. ალექსანდრე კუკუშკინს აქვს მოხსენება "როგორ გამოვთვალოთ RPO და RTO", ანუ აღდგენის დრო და რამდენი მონაცემი შეიძლება დავკარგოთ. ვფიქრობ, ეს სლაიდები უნდა მოვძებნოთ და შევისწავლოთ. რამდენადაც მახსოვს, არსებობს კონკრეტული ნაბიჯები, თუ როგორ უნდა გამოვთვალოთ ეს ყველაფერი. რამდენი ტრანზაქცია შეიძლება დავკარგოთ, რამდენი მონაცემი შეიძლება დავკარგოთ. როგორც ვარიანტი, ჩვენ შეგვიძლია გამოვიყენოთ სინქრონული რეპლიკაცია პატრონის დონეზე, მაგრამ ეს არის ორლესიანი ხმალი: ჩვენ ან გვაქვს მონაცემთა სანდოობა, ან ვკარგავთ სიჩქარეს. არსებობს სინქრონული რეპლიკაცია, მაგრამ ის ასევე არ იძლევა 100% დაცვას მონაცემთა დაკარგვისგან.

ალექსეი, მადლობა შესანიშნავი მოხსენებისთვის! გაქვთ რაიმე გამოცდილება პატრონის გამოყენებისას ნულოვანი დონის დაცვისთვის? ანუ სინქრონულ ლოდინსთან ერთად? ეს არის პირველი შეკითხვა. და მეორე კითხვა. თქვენ იყენებდით სხვადასხვა გადაწყვეტილებებს. ჩვენ გამოვიყენეთ Repmgr, მაგრამ ავტოფილერის გარეშე და ახლა ვგეგმავთ ავტოფილერის ჩართვას. ალტერნატიულ გადაწყვეტად კი პატრონს მივიჩნევთ. რას იტყვით უპირატესობად Repmgr-თან შედარებით?

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

მეორე კითხვასთან დაკავშირებით, ჩვენ გამოვიყენეთ Repmgr და ახლაც ვიყენებთ ზოგიერთ კლიენტთან ისტორიული მიზეზების გამო. რა შეიძლება ითქვას? Patroni მოყვება autofiler out of box, Repmgr მოყვება autofiler, როგორც დამატებითი ფუნქცია, რომელიც უნდა ჩართოთ. ჩვენ უნდა გავუშვათ Repmgr დემონი თითოეულ კვანძზე და შემდეგ შეგვიძლია დავაკონფიგურიროთ ავტოფილერი.

Repmgr ამოწმებს, არის თუ არა Postgres კვანძები ცოცხალი. Repmgr პროცესები ამოწმებენ ერთმანეთის არსებობას, ეს არ არის ძალიან ეფექტური მიდგომა. შეიძლება იყოს ქსელის იზოლაციის რთული შემთხვევები, როდესაც დიდი Repmgr კლასტერი შეიძლება დაიშალოს რამდენიმე მცირედ და გააგრძელოს მუშაობა. დიდი ხანია არ მივყვები Repmgr-ს, იქნებ გამოსწორდა... ან შეიძლება არა. მაგრამ DCS-ში კლასტერის მდგომარეობის შესახებ ინფორმაციის ამოღება, როგორც ამას Stolon, Patroni აკეთებს, ყველაზე ეფექტური ვარიანტია.

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

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

უხეშად რომ ვთქვათ, DCS ხდება ჩვენთვის ისეთივე მნიშვნელოვანი სერვისი, როგორც თავად ბაზა?

Დიახ დიახ. ბევრ თანამედროვე კომპანიაში Service Discovery ინფრასტრუქტურის განუყოფელი ნაწილია. ის დანერგილია მანამდეც კი, სანამ ინფრასტრუქტურაში მონაცემთა ბაზა იყო. შედარებით რომ ვთქვათ, ინფრასტრუქტურა ამოქმედდა, განლაგდა DC-ში და ჩვენ მაშინვე გვაქვს Service Discovery. თუ ეს არის კონსული, მაშინ მასზე შეიძლება აშენდეს DNS. თუ ეს არის Etcd, მაშინ შეიძლება იყოს ნაწილი Kubernetes კლასტერიდან, რომელშიც ყველაფერი დანარჩენი განლაგდება. მეჩვენება, რომ Service Discovery უკვე თანამედროვე ინფრასტრუქტურის განუყოფელი ნაწილია. და ისინი ამაზე ბევრად ადრე ფიქრობენ, ვიდრე მონაცემთა ბაზებზე.

დიდი მადლობა!

წყარო: www.habr.com