სარეზერვო ასლები WAL-G-დან. რა არის 2019 წელს? ანდრეი ბოროდინი

გირჩევთ წაიკითხოთ ანდრეი ბოროდინის 2019 წლის დასაწყისის მოხსენების ტრანსკრიპტი "სარეზერვო ასლები WAL-G-ით. რა არის 2019 წელს?"

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

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

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

თუ მოულოდნელად თქვენ გაქვთ PostgreSQL კლასტერი და ვფიქრობ, რომ ყველას აქვს რამდენიმე მათგანი, და მოულოდნელად ჯერ არ არის სარეზერვო სისტემა, მაშინ უნდა მიიღოთ ნებისმიერი S3 საცავი ან Google Cloud თავსებადი მეხსიერება.

მაგალითად, შეგიძლიათ მოხვიდეთ ჩვენს სტენდზე და აიღოთ Yandex Object Storage-ის სარეკლამო კოდი, რომელიც თავსებადია S3-თან.

შემდეგ შექმენით Bucket. ეს მხოლოდ ინფორმაციის კონტეინერია.

შექმენით სერვისის მომხმარებელი.

შექმენით წვდომის გასაღები სერვისის მომხმარებლისთვის: aws-s3-key.

ჩამოტვირთეთ WAL-G-ის უახლესი სტაბილური გამოშვება.

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

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

ამის შემდეგ, შეგიძლიათ გააკეთოთ თქვენი პირველი სარეზერვო საშუალება. თქვით „backup-push“ WAL-G-ში და WAL-G-ში მიუთითეთ თქვენი კლასტერის pgdata მდებარეობა. და, სავარაუდოდ, PostgreSQL გეტყვით, თუ უკვე არ გაქვთ სარეზერვო სისტემა, რომ უნდა ჩართოთ "არქივის რეჟიმი".

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

ჩვენ ვიყენებთ WAL-G-ს ძირითადად Yandex მონაცემთა ბაზის მენეჯმენტში მაღალი ხელმისაწვდომობის კლასტერის შესაქმნელად.

და ის ჩვეულებრივ გამოიყენება ერთი მაგისტრისა და რამდენიმე რეპლიკაციის ტოპოლოგიაში. ამავე დროს, ის აკეთებს სარეზერვო ასლს Yandex Object Storage-ში.

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

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

და კიდევ ერთი მსგავსი სიტუაცია. ეს არის ძველი Master-ის გადატვირთვის საჭიროება მონაცემთა ცენტრიდან Cluster Master-ის გადართვის შემდეგ, რომელთანაც კავშირი დაიკარგა.

• შედეგად, ასლის სისტემის მოთხოვნების ჩამოყალიბებისას მივხვდით, რომ pg_basebackup არ არის შესაფერისი ჩვენთვის ღრუბელში მუშაობისას.
• ჩვენ გვინდოდა შეგვეძლოს ჩვენი მონაცემების შეკუმშვა. მაგრამ თითქმის ნებისმიერი სარეზერვო სისტემა, გარდა იმისა, რაც შედის ყუთში, უზრუნველყოფს მონაცემთა შეკუმშვას.
• გვინდოდა ყველაფრის პარალელიზება, რადგან ღრუბელში მომხმარებელი ყიდულობს პროცესორის ბირთვების დიდ რაოდენობას. მაგრამ თუ რომელიმე ოპერაციაში არ გვაქვს პარალელიზმი, მაშინ ბირთვების დიდი რაოდენობა უსარგებლო ხდება.
• ჩვენ გვჭირდება დაშიფვრა, რადგან ხშირად ეს არ არის ჩვენი მონაცემები და არ შეიძლება შენახული იყოს მკაფიო ტექსტში. სხვათა შორის, ჩვენი წვლილი WAL-G-ში დაშიფვრით დაიწყო. ჩვენ დავასრულეთ დაშიფვრა WAL-G-ში, რის შემდეგაც გვკითხეს: "იქნებ რომელიმე ჩვენგანი განავითაროს პროექტი?" და მას შემდეგ ერთ წელზე მეტია ვმუშაობ WAL-G-თან.
• ჩვენ ასევე გვჭირდებოდა რესურსების ჩახშობა, რადგან დროთა განმავლობაში ღრუბლის გამოყენებით აღმოვაჩინეთ, რომ ზოგჯერ ადამიანებს ღამით მნიშვნელოვანი სასურსათო ტვირთი აქვთ და ამ დატვირთვაში ხელის შეშლა შეუძლებელია. ამიტომ ჩვენ დავამატეთ რესურსების throttling.
• ასევე ჩამონათვალი და მართვა.
• და გადამოწმება.

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

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

მთავარი იდეოლოგია, რომელსაც ჩვენ ვიცავთ არის ის, რომ WAL-G უნდა იყოს ისეთივე მარტივი, როგორც ბალალაიკა.

WAL-G-ს აქვს 4 ბრძანება. ეს:

WAL-PUSH - ლილვის დაარქივება.

WAL-FETCH - მიიღეთ ლილვი.

BACKUP-PUSH – გააკეთეთ სარეზერვო საშუალება.

BACKUP-FETCH – მიიღეთ სარეზერვო ასლი სარეზერვო სისტემიდან.

ფაქტობრივად, WAL-G-ს ასევე აქვს ამ სარეზერვო ასლების მართვა, ანუ ისტორიაში ჩანაწერების და სარეზერვო ასლების ჩამოთვლა და წაშლა, რომლებიც ამ მომენტში აღარ არის საჭირო.

ჩვენთვის ერთ-ერთი მნიშვნელოვანი ფუნქციაა დელტა ასლების შექმნის ფუნქცია.

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

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

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

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

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

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

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

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

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

შედეგად, ჩვენ მოგვიწია გაუგებარი ნაწილების ჩასმა _delta_partial ფაილებში. შედეგად, როცა წარსულს დავუბრუნდებით, WAL-ის ჩანაწერის ნაწილებს ერთში ვაწებებთ, ამის შემდეგ გავაანალიზებთ და გავიგებთ რა შეიცვალა მასში.

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

შედეგად, მთელმა ჩვენმა ტანჯვამ განაპირობა ის, რომ ჩვენ WAL-G პარსირების ბიბლიოთეკის ღია წყაროს შევქმენით. როგორც ვიცი ჯერ არავინ ხმარობს, მაგრამ თუ ვინმეს უნდა დაწეროს და გამოიყენოს საჯარო დომენშია. (განახლებული ბმული https://github.com/wal-g/wal-g/tree/master/internal/walparser)

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

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

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

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

ეს არის ის, რაც ახლა კოდშია.

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

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

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

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

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

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

ჩვენ გვინდა შევქმნათ კიდევ ერთი ფუნქცია WAL-G-ში. ჩვენ გვინდა გავხადოთ ის გაფართოებული, რადგან გვჭირდება სხვადასხვა მონაცემთა ბაზის მხარდაჭერა და გვსურს, რომ იგივე გზით მივუდგეთ სარეზერვო მენეჯმენტს. მაგრამ პრობლემა ის არის, რომ MySQL API რადიკალურად განსხვავებულია. MySQL-ში PITR ეფუძნება არა ფიზიკურ WAL ჟურნალს, არამედ ბინლოგს. და ჩვენ არ გვაქვს არქივის სისტემა MySQL-ში, რომელიც აცნობებს ზოგიერთ გარე სისტემას, რომ ეს ბინლოგი დასრულებულია და საჭიროებს დაარქივებას. სადმე უნდა დავდგეთ მონაცემთა ბაზასთან და შევამოწმოთ არის თუ არა რამე მზად?

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

მოხსენებაში ასევე მინდოდა მესაუბრა იმ შემთხვევებზე, როდესაც WAL-G არ არის თქვენთვის შესაფერისი.

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

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

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

მაგრამ ეს პრობლემა ნაკლებად სავარაუდოა, რომ დაფიქსირდეს WAL-E მხარეს, ამიტომ ამჟამად შეუძლებელია არქივის ბრძანების შექმნა, რომელიც დაარქივებს ფაილს WAL-G და WAL-E-ში.

გარდა ამისა, არის შემთხვევები, როდესაც WAL-G ახლა არ არის თქვენთვის შესაფერისი, მაგრამ ჩვენ აუცილებლად გამოვასწორებთ.

ჯერ ერთი, ჩვენ ამჟამად არ გვაქვს ჩაშენებული სარეზერვო გადამოწმება. ჩვენ არ გვაქვს გადამოწმება არც სარეზერვო და არც აღდგენის დროს. რა თქმა უნდა, ეს ხორციელდება ღრუბელში. მაგრამ ეს ხორციელდება უბრალოდ წინასწარი შემოწმებით, უბრალოდ კლასტერის აღდგენით. მინდა მივცეთ ეს ფუნქცია მომხმარებლებს. მაგრამ ვერიფიკაციით, ვვარაუდობ, რომ WAL-G-ში შესაძლებელი იქნება კლასტერის აღდგენა და გაშვება და კვამლის ტესტების გაშვება: pg_dumpall / dev/null-ზე და amcheck index verification.

ამჟამად WAL-G-ში არ არსებობს გზა WAL-დან ერთი სარეზერვო ასლის გადადება. ანუ რაღაც ფანჯარას ვუჭერთ მხარს. მაგალითად, ბოლო შვიდი დღის შენახვა, ბოლო ათი სარეზერვო ასლის შენახვა, ბოლო სამი სრული სარეზერვო ასლის შენახვა. ხშირად მოდიან ადამიანები და ამბობენ: „ჩვენ გვჭირდება სარეზერვო ასლი, რაც მოხდა ახალ წელს და გვინდა, რომ ის სამუდამოდ შევინარჩუნოთ“. WAL-G-მ ჯერ არ იცის როგორ გააკეთოს ეს. (შენიშვნა - ეს უკვე გამოსწორებულია. დაწვრილებით - სარეზერვო-ნიშნის ოფცია https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

ჩვენ არ გვაქვს გვერდის შემოწმება და მთლიანობის შემოწმება ყველა ლილვის სეგმენტისთვის PITR-ის დამოწმებისას.

ამ ყველაფრისგან შევადგინე პროექტი Google Summer of Code-ისთვის. თუ იცნობთ ჭკვიან სტუდენტებს, რომლებსაც სურთ Go-ში დაწერონ რამე და მიიღონ რამდენიმე ათასი დოლარი ერთი კომპანიისგან ასო „G“-ით, მაშინ რეკომენდაცია გაუწიეთ მათ ჩვენს პროექტს. მე ვიქცევი ამ პროექტის მენტორად, მათ შეუძლიათ ამის გაკეთება. თუ სტუდენტები არ არიან, მაშინ ავიღებ და თვითონ გავაკეთებ ზაფხულში.

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

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

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

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

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

ჩვენ გვაქვს WAL-G გაშვებული ათასზე მეტ კლასტერზე Yandex მონაცემთა ბაზის მენეჯმენტში. და ის ყოველდღიურად რამდენიმე ასეული ტერაბაიტი მონაცემების სარეზერვო ასლს ქმნის.

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

კითხვები

Საღამო მშვიდობისა! Გმადლობთ! ჩემი ვარაუდით, თუ თქვენ იყენებთ WAL-delta-ს, ალბათ დიდად ეყრდნობით სრულ გვერდს. და თუ ასეა, ჩაატარე ტესტები? მშვენიერი გრაფიკი აჩვენე. რამდენად უფრო ლამაზი ხდება FPW თუ გამორთულია?

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

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

ველოდებით გაყვანის მოთხოვნას. ჩვენი მონაცემთა ბაზები ცხოვრობს SSD და NMVE დისკებზე და ჩვენ ნამდვილად არ გვჭირდება ეს ფუნქცია. მე არ ვარ მზად ახლა სერიოზული დრო დავხარჯო ამის კარგად გაკეთებაზე. მე მთელი გულით ვემხრობი, რომ ჩვენ მხარს ვუჭერთ ამას. არიან ადამიანები, რომლებიც მხარს უჭერდნენ, მაგრამ მხარს უჭერდნენ ისე, როგორც მათ შეეფერებათ. მათ გააკეთეს ჩანგალი, მაგრამ ისინი არ ასრულებენ მოთხოვნებს. (დამატებულია 0.2.13 ვერსიაში)

და მეორე კითხვა. თქვენ თავიდანვე თქვით, რომ WAL-G ვარაუდობს, რომ ის მუშაობს მარტო და არ არის საჭირო შეფუთვა. მე თვითონ ვიყენებ სახვევებს. რატომ არ უნდა იქნას გამოყენებული?

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

Საღამო მშვიდობისა! გმადლობთ ანგარიშისთვის! ჩვენ ვერ მოვახერხეთ WAL-G-ს GPG-ის გაშიფვრით მუშაობა. ის ჩვეულებრივ შიფრავს, მაგრამ არ სურს გაშიფვრა. არის ის, რაც არ გამოგვივიდა? მდგომარეობა დამთრგუნველია.

შექმენით პრობლემა GitHub-ზე და მოდით გავარკვიოთ.

ანუ ეს არ შეგხვედრიათ?

არსებობს შეცდომის მოხსენების ფუნქცია, რომ როდესაც WAL-G არ ესმის, რა სახის ფაილია, ის სვამს კითხვას: „იქნებ დაშიფრულია?“ ალბათ პრობლემა საერთოდ არ არის დაშიფვრა. მინდა გავაუმჯობესო ლოგინგი ამ თემაზე. მან უნდა გაშიფროს იგი. ჩვენ ამჟამად ვმუშაობთ ამ თემაზე იმ გაგებით, რომ ჩვენ ნამდვილად არ მოგვწონს როგორ არის ორგანიზებული საჯარო და პირადი გასაღებების მოპოვების სისტემა. იმიტომ, რომ ჩვენ ვუწოდებთ გარე GPG-ს, რათა ის გვაძლევს თავის გასაღებებს. შემდეგ ჩვენ ვიღებთ ამ კლავიშებს და გადავცემთ შიდა GPG-ს, რომელიც არის ღია PGP, რომელიც ჩვენთვის არის შედგენილი WAL-G-ში და იქ ვუწოდებთ დაშიფვრას. ამ მხრივ, ჩვენ გვსურს სისტემის გაუმჯობესება და გვინდა Libsodium დაშიფვრის მხარდაჭერა (დამატებულია 0.2.15 ვერსიაში). რა თქმა უნდა, დეკოდირებამ უნდა იმუშაოს, მოდით გავარკვიოთ - თქვენ გჭირდებათ მეტი სიმპტომი, ვიდრე ორი სიტყვა. შეგიძლიათ ოდესმე შეიკრიბოთ სპიკერის ოთახში და დაათვალიეროთ სისტემა. (PGP დაშიფვრა გარე GPG-ის გარეშე - v0.2.9)

გამარჯობა! გმადლობთ ანგარიშისთვის! ორი კითხვა მაქვს. უცნაური სურვილი მაქვს გავაკეთო pg_basebackup და WAL შესვლა ორ პროვაიდერში, ანუ მინდა გავაკეთო ერთი ღრუბელი და მეორე. არის რაიმე გზა ამის გასაკეთებლად?

ეს ახლა არ არსებობს, მაგრამ საინტერესო იდეაა.

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

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

დიახ, რა თქმა უნდა.

და შემდეგ, როდესაც სტუდენტები მივლენ Google Summer of Code-ზე, ჩვენ მათ დავამატებთ პროექტს, რათა მეტი სამუშაო იყოს მათგან მეტის მისაღებად.

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

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

SLA არ არის? მათთვის არ წერია როგორ აძლევენ თავს ტანჯვის უფლებას?

საქმე იმაშია, რომ ადამიანებს, რომლებსაც ეს კითხვა უჩნდებათ, ჩვეულებრივ აქვთ საკუთარი სარდაფი. ანუ, არავინ მოდის Amazon-დან ან Google Cloud-დან ან Yandex Object Storage-დან.

იქნებ კითხვა აღარ არის თქვენთვის?

კითხვა აქ ამ შემთხვევაში არ აქვს მნიშვნელობა ვისთვის. თუ არსებობს რაიმე იდეა, თუ როგორ უნდა გაუმკლავდეთ ამას, მოდით გავაკეთოთ ეს WAL-G-ში. მაგრამ ჯერჯერობით არ მაქვს კარგი იდეები, თუ როგორ უნდა გავუმკლავდე ამას. არსებობს ობიექტების საცავი, რომელიც მხარს უჭერს სარეზერვო ასლების ჩამონათვალს განსხვავებულად. თქვენ სთხოვთ მათ ჩამოთვალონ ობიექტები და ისინი დაამატებენ იქ საქაღალდეს. WAL-G ეშინია ამის - აქ არის რაღაც ისეთი, რაც არ არის ფაილი, მე არ შემიძლია მისი აღდგენა, რაც ნიშნავს, რომ სარეზერვო ასლი არ იყო აღდგენილი. ანუ, ფაქტობრივად, თქვენ გაქვთ მთლიანად აღდგენილი კლასტერი, მაგრამ ის გიბრუნებს მცდარ სტატუსს, რადგან Object Storage-მა დააბრუნა უცნაური ინფორმაცია, რომელიც ბოლომდე არ ესმოდა.

ეს არის ის, რაც ხდება ფოსტის ღრუბელში.

თუ შეგიძლია შექმნა რეპროდუცირება...

ის მუდმივად მრავლდება...

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

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

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

ანუ, ყოველ ჯერზე, როცა WAL-G-ს გავუშვით, ის ცდილობს სრული სარეზერვო ასლის გაკეთებას?

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

უხეშად რომ ვთქვათ, თუ ყოველ ჯერზე ნულით გაუშვით, ის იქცევა როგორც pg_basebackup?

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

Pg_basebackup შეიძლება გაშვებული იყოს ლილვების გარეშე.

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

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

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

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

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

გამარჯობა, მადლობა მოხსენებისთვის. როგორც მე მესმის, WAL-G არ არის ბარმენის მსგავსი ცენტრალიზებული სისტემა? გეგმავთ თუ არა ამ მიმართულებით მოძრაობას?

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

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

PS გამოვიდა ახალი ვერსია 0.2.15, რომელშიც შეგიძლიათ გამოიყენოთ .walg.json კონფიგურაციის ფაილი, რომელიც ნაგულისხმევად მდებარეობს postgres მთავარი დირექტორიაში. შეგიძლიათ მიატოვოთ bash სკრიპტები. მაგალითი .walg.json არის ამ გამოცემაში https://github.com/wal-g/wal-g/issues/545

ვიდეო:

წყარო: www.habr.com