CloudNativePG-ის გადაყვანა Barman Cloud პლაგინზე არქივის გაწყვეტის გარეშე

სახლის ლაბორატორიაში CloudNativePG-ის მიერ მართული ორინსტანსიანი PostgreSQL 16 კლასტერი პეტ-პროექტის აპლიკაციას ემსახურება და MinIO-ში აარქივებს ცალკე VM-ზე. CloudNativePG-მა spec.backup.barmanObjectStore მოძველებულად გამოაცხადა და ოპერატორი ამას პირდაპირ ამბობს admission გაფრთხილებაში: Barman Cloud-ის ჩაშენებული მხარდაჭერა 1.31.0-ში წაიშლება. ჩანაცვლება Barman Cloud პლაგინია.

სანამ Postgres-ს შევეხებოდი, ამოცანის ანალიზმა ორი პრობლემა გამოავლინა.

პირველი პრობლემა: cert-manager

პლაგინს მოჰყვება თვითხელმოწერილი Issuer და ორი Certificate ოპერატორთან mTLS-ისთვის, ამიტომ cert-manager მკაცრი პირობაა. ის დაყენებული არ იყო.

მეორე პრობლემა: ბექაპები არ იყო

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

ვალიდური შუალედური მდგომარეობა არ არსებობს

ცვლილების ფორმას თავად API განსაზღვრავს:

spec.plugins: Invalid value: ["barman-cloud.cloudnative-pg.io"]:
Cannot enable a WAL archiver plugin when barmanObjectStore is configured

ძველი ველი და WAL-ის არქივატორი პლაგინი ერთად ვერ იარსებებს, ამიტომ გადართვის ეტაპებად დაყოფა შეუძლებელია. ObjectStore, Cluster.spec.plugins, spec.backup-ის წაშლა და ScheduledBackup.method: plugin ერთი apply-ით უნდა შევიდეს.

თანმიმდევრობა

1. ჯერ უნდა უზრუნველვყოთ, რომ ბექაპები არსებობდეს. ყოველდღიური ScheduledBackup immediate: true-ით. იმ ბაზის ბექაპის მექანიზმის გადატანა, რომელსაც აღდგენადი ბექაპი არასოდეს ჰქონია, ნიშნავს უკანდახევის გზის არქონას, თუ რამე არასწორად წავა, და იმის დამტკიცების საშუალების არქონას, რომ მიგრაციამ რამე შეინარჩუნა.
2. cert-manager-ის, შემდეგ პლაგინის დაყენება და თითოეულის ფუნქციური შემოწმება: ერთჯერადი თვითხელმოწერილი Certificate Ready=True-მდე უნდა მივიდეს.
3. ერთი ატომური კომიტი გადართვისთვის.
4. შედეგის დამტკიცება პლაგინის მიერ გადაღებული ახალი ბექაპით და არა სტატუსის პირობით.

გადაწყვეტილება, რომელსაც ყველაზე დიდი მნიშვნელობა ჰქონდა

destinationPath ბაიტამდე იდენტური დავტოვე. Barman ობიექტურ საცავს ალაგებს როგორც <destinationPath>/<serverName>/, სერვერის სახელი კი ნაგულისხმევად კლასტერის სახელს უდრის, ამიტომ გზის შენარჩუნება ნიშნავს, რომ პლაგინი იმავე არქივს აგრძელებს. ObjectStore-ის სტატუსმა საბოლოოდ აჩვენა აღდგენის ერთი უწყვეტი ფანჯარა ორივე მექანიზმში: აღდგენის პირველი წერტილი — ძველი კოდის მიერ გადაღებული ბექაპიდან, ბოლო წარმატებული ბექაპი — პლაგინიდან.

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

როგორ შევამოწმე

• კლასტერის ფაზამ გაიარა „Primary instance is being restarted without a switchover“ და ოთხ-ხუთ წუთში ჯანსაღ მდგომარეობას დაუბრუნდა. აპლიკაციის ტრაფიკზე ამას გავლენა არ ჰქონია, მაგრამ ეს მომსახურების ფანჯარაა და არა კონფიგის შესწორება.
• pg_stat_archiver თავად Postgres-იდან pg_switch_wal()-ის შემდეგ, რომ შემოწმება „ახლანდელზე“ იყოს: დაარქივებულთა მთვლელი იზრდება, შეცდომების მთვლელი დგას.
• Backup METHOD plugin-ით და PHASE completed-ით, მოთხოვნილი სრული სახელით backups.postgresql.cnpg.io. როცა Longhorn დაყენებულია, მოკლე backup მის CRD-ად იხსნება.

ხაფანგები გზაზე

• kubectl apply --dry-run=server სწორ მანიფესტზე იმავე „cannot enable“ შეცდომით ეცემოდა. ობიექტი Argo CD-მ შექმნა server-side apply-ით და კლიენტის merge-მა არ იცოდა, რომ ძველი ველი უნდა წაშლილიყო. Server-side dry-run Argo-ს field manager-ით გავიდა.
• პლაგინის sidecar ნატიური init კონტეინერია restartPolicy: Always-ით. შემოწმება, რომელიც მხოლოდ spec.containers-ს კითხულობს, გადაწყვეტს, რომ ის არ ჩაუნერგავთ.
• ScheduledBackup.method ნაგულისხმევად barmanObjectStore-ია. თუ მის მითითებას დაივიწყებთ, განრიგი იმ მექანიზმზე მიუთითებს, რომელიც კლასტერს აღარ აქვს, ობიექტი კი ნორმალურად გამოიყურება.
• შენახვის პოლიტიკა ObjectStore-ში გადადის. თუ Cluster-ში დატოვებთ, ის ჩუმად დაიკარგება.

რა წავიღოთ

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