Failover Cluster PostgreSQL + Patroni. განხორციელების გამოცდილება

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

ჩვენ გვაქვს ძალიან დატვირთული სერვისი: 2,5 მილიონი მომხმარებელი მთელს მსოფლიოში, 50K+ აქტიური მომხმარებელი ყოველდღიურად. სერვერები განლაგებულია ამაზონში, ირლანდიის ერთ რეგიონში: მუდმივად მუშაობს 100+ სხვადასხვა სერვერი, რომელთაგან თითქმის 50 არის მონაცემთა ბაზებით.

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

რატომ გადავედით Redis-დან PostgreSQL-ზე

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

Redis-ის დადებითი მხარეები:

1. მაღალი რეაგირების სიჩქარე, რადგან ყველაფერი ინახება მეხსიერებაში;
2. სარეზერვო და რეპლიკაციის სიმარტივე.

Redis-ის უარყოფითი მხარეები ჩვენთვის:

1. რეალური გარიგებები არ არის. ჩვენ ვცადეთ მათი სიმულაცია ჩვენი აპლიკაციის დონეზე. სამწუხაროდ, ეს ყოველთვის არ მუშაობდა კარგად და მოითხოვდა ძალიან რთული კოდის დაწერას.
2. მონაცემთა რაოდენობა შეზღუდულია მეხსიერების რაოდენობით. მონაცემთა ოდენობის გაზრდით, მეხსიერება გაიზრდება და, საბოლოოდ, ჩვენ გადავაწყდებით არჩეული ინსტანციის მახასიათებლებს, რაც AWS-ში მოითხოვს ჩვენი სერვისის შეჩერებას ინსტანციის ტიპის შესაცვლელად.
3. აუცილებელია მუდმივად შენარჩუნდეს დაბალი შეყოვნების დონე, რადგან. ჩვენ გვაქვს ძალიან დიდი რაოდენობის მოთხოვნა. ჩვენთვის დაყოვნების ოპტიმალური დონეა 17-20 ms. 30-40 ms დონეზე, ჩვენ ვიღებთ ხანგრძლივ პასუხებს ჩვენი აპლიკაციის მოთხოვნებზე და სერვისის დეგრადაციაზე. სამწუხაროდ, ეს მოხდა ჩვენთან 2018 წლის სექტემბერში, როდესაც Redis-ის ერთ-ერთმა შემთხვევამ რაიმე მიზეზით მიიღო შეყოვნება ჩვეულებრივზე 2-ჯერ მეტი. პრობლემის გადასაჭრელად, ჩვენ შევაჩერეთ სერვისი შუადღისას დაუგეგმავი ტექნიკური მომსახურების გამო და შევცვალეთ პრობლემური Redis ეგზემპლარი.
4. მარტივია მონაცემთა შეუსაბამობის მიღება კოდში მცირე შეცდომების შემთხვევაშიც კი და შემდეგ დიდი დრო დახარჯავს კოდის დაწერას ამ მონაცემების გამოსასწორებლად.

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

ჩვენ უკვე 1,5 წელია გადავდივართ ახალ მონაცემთა ბაზაში და გადავიტანეთ მონაცემების მხოლოდ მცირე ნაწილი, ამიტომ ახლა ვმუშაობთ ერთდროულად Redis-თან და PostgreSQL-თან. მეტი ინფორმაცია მონაცემთა ბაზებს შორის გადატანისა და გადართვის ეტაპების შესახებ იწერება ჩემი კოლეგის სტატია.

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

PgBouncer-ის დანერგვა

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

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

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


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

PgBouncer-ის წარუმატებლობა

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

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

ჩვენ შევქმენით PgBouncer შეცდომის ტოლერანტობის სქემა შემდეგნაირად: ყველა აპლიკაციის სერვერი წვდება Network Load Balancer-ს, რომლის უკან არის ორი PgBouncer. თითოეული PgBouncer უყურებს თითოეული ფრაგმენტის ერთსა და იმავე PostgreSQL მასტერს. თუ AWS ინსტანციის ავარია განმეორდება, მთელი ტრაფიკი გადამისამართდება სხვა PgBouncer-ის მეშვეობით. Network Load Balancer-ის გაუმართაობა მოწოდებულია AWS-ის მიერ.

ეს სქემა აადვილებს ახალი PgBouncer სერვერების დამატებას.

შექმენით PostgreSQL Failover კლასტერი

ამ პრობლემის გადაჭრისას განვიხილეთ სხვადასხვა ვარიანტები: თვითნაწერი failover, repmgr, AWS RDS, Patroni.

თვითნაწერი სკრიპტები

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

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

Cons:

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

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

Repmgr

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

AWS RDS

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

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

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

გარდა ამისა, AWS RDS თითქმის ორჯერ ძვირია, ვიდრე ჩვეულებრივი ინსტანციის ფასი, რაც ამ გადაწყვეტის მიტოვების მთავარი მიზეზი იყო.

პატრონი

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

პატრონის დადებითი მხარეები:

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

Cons:

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

შედეგად, ჩვენ ავირჩიეთ Patroni, რათა შეგვექმნა failover კლასტერი.

პატრონის განხორციელების პროცესი

Patroni-მდე გვქონდა 12 PostgreSQL ფრაგმენტი ერთი ძირითადი და ერთი ასინქრონული რეპლიკაციის კონფიგურაციაში. აპლიკაციის სერვერები შედიოდნენ მონაცემთა ბაზებზე Network Load Balancer-ის საშუალებით, რომლის უკან იყო ორი ინსტანცია PgBouncer-ით და მათ უკან ყველა PostgreSQL სერვერი.


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

როგორ მუშაობს პატრონი კონსულთან

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

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

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

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

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

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

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

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

კონსულ-თარგი

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

გამოსავლის ძიებაში ვიპოვეთ სტატია (სამწუხაროდ არ მახსოვს სათაური), სადაც ეწერა, რომ Сonsul-template ძალიან დაეხმარა PgBouncer-ისა და Patroni-ის დაწყვილებაში. ამან გვაიძულებს გამოგვეკვლია, როგორ მუშაობს Consul-template.

აღმოჩნდა, რომ Consul-template მუდმივად აკონტროლებს PostgreSQL კლასტერის კონფიგურაციას კონსულში. როდესაც ლიდერი იცვლება, ის განაახლებს PgBouncer-ის კონფიგურაციას და აგზავნის ბრძანებას მის გადატვირთვისთვის.

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

ახალი არქიტექტურა პატრონთან ერთად

შედეგად მივიღეთ მუშაობის შემდეგი სქემა:


ყველა აპლიკაციის სერვერი წვდება ბალანსერს → მის უკან არის PgBouncer-ის ორი ინსტანცია → თითოეულ ინსტანციაზე, იხსნება Consul-template, რომელიც აკონტროლებს თითოეული Patroni კლასტერის სტატუსს და აკონტროლებს PgBouncer კონფიგურაციის შესაბამისობას, რომელიც აგზავნის მოთხოვნებს ამჟამინდელ ლიდერთან. თითოეული კლასტერის.

ხელით ტესტირება

ჩვენ გავუშვით ეს სქემა მცირე სატესტო გარემოზე გაშვებამდე და შევამოწმეთ ავტომატური გადართვის მოქმედება. გახსნეს დაფა, გადაიტანეს სტიკერი და ამ დროს მტევნის ლიდერი „მოკლეს“. AWS-ში ეს ისეთივე მარტივია, როგორც ინსტანციის გამორთვა კონსოლის საშუალებით.

სტიკერი უკან დაბრუნდა 10-20 წამში, შემდეგ კი ისევ ნორმალურად დაიწყო მოძრაობა. ეს ნიშნავს, რომ Patroni კლასტერმა სწორად იმუშავა: მან შეცვალა ლიდერი, გაუგზავნა ინფორმაცია Сonsul-ს და Сonsul-template-მა მაშინვე აიღო ეს ინფორმაცია, შეცვალა PgBouncer კონფიგურაცია და გაუგზავნა გადატვირთვის ბრძანება.

როგორ გადავრჩეთ მაღალი დატვირთვის ქვეშ და შევინარჩუნოთ შეფერხების დრო მინიმალური?

ყველაფერი მუშაობს იდეალურად! მაგრამ არის ახალი კითხვები: როგორ იმუშავებს იგი მაღალი დატვირთვის პირობებში? როგორ სწრაფად და უსაფრთხოდ გავაფართოვოთ ყველაფერი წარმოებაში?

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

ორივე ამოცანა ამბიციურად გამოიყურება, მაგრამ ჩვენ გვაქვს PostgreSQL 9.6. შეგვიძლია თუ არა დაუყოვნებლივ განახლება 11.2-ზე?

ჩვენ გადავწყვიტეთ ამის გაკეთება 2 ეტაპად: ჯერ განაახლეთ 11.2-ზე, შემდეგ გაუშვით Patroni.

PostgreSQL განახლება

PostgreSQL ვერსიის სწრაფად განახლებისთვის გამოიყენეთ ვარიანტი -k, რომელშიც მყარი ბმულები იქმნება დისკზე და არ არის საჭირო თქვენი მონაცემების კოპირება. 300-400 GB ბაზაზე განახლებას 1 წამი სჭირდება.

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

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

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

გაუშვით პატრონი

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

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

rm -rf /var/lib/postgresql/

ეს უნდა გაკეთდეს მხოლოდ მონაზე!

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

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

დატვირთვის ტესტი

ჩვენ დავიწყეთ ტესტი, რომელიც ახდენს მომხმარებლის გამოცდილების სიმულაციას დაფებზე. როდესაც დატვირთვამ მიაღწია ჩვენს საშუალო დღიურ მნიშვნელობას, ჩვენ გავიმეორეთ ზუსტად იგივე ტესტი, გამორთეთ ერთი ინსტანცია PostgreSQL ლიდერთან. ავტომატური ფაილოვერი მუშაობდა ისე, როგორც ველოდით: პატრონმა შეცვალა ლიდერი, Consul-template-მა განაახლა PgBouncer-ის კონფიგურაცია და გაგზავნა ბრძანება გადატვირთვის შესახებ. Grafana-ში ჩვენი გრაფიკების მიხედვით, ცხადი იყო, რომ არის 20-30 წამის შეფერხება და მცირე რაოდენობის შეცდომები სერვერებიდან, რომლებიც დაკავშირებულია მონაცემთა ბაზასთან კავშირთან. ეს ნორმალური სიტუაციაა, ასეთი მნიშვნელობები მისაღებია ჩვენი მარცხისთვის და ნამდვილად უკეთესია ვიდრე სერვისის შეფერხება.

პატრონის წარმოებაში მოყვანა

შედეგად, ჩვენ მივიღეთ შემდეგი გეგმა:

• განათავსეთ Consul-თარგი PgBouncer სერვერებზე და გაუშვით;
• PostgreSQL განახლებები 11.2 ვერსიამდე;
• შეცვალეთ კლასტერის სახელი;
• პატრონონის კლასტერის დაწყება.

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

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

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


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


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

გადატვირთეთ Patroni კლასტერი

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

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

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

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

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

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

პრობლემა კვლავ მოუგვარებელი რჩება. ჩვენ ვგეგმავთ ვცადოთ შემდეგი გადაწყვეტილებები:

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

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

საბედნიეროდ, მეტი შეცდომა არ შეგვხვედრია.

პატრონის გამოყენების შედეგები

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


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

პატრონის გამოყენების მცირე შეჯამება:

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

წყარო: www.habr.com