მონაცემთა ბაზები
PostgreSQL, CloudNativePG, Amazon RDS და MySQL InnoDB Cluster: რეპლიკაცია, გადართვები, კავშირების პულები და აღდგენა.
8 სტატია
- RDS კავშირებზე უარს ამბობდა 10% CPU-ზე: ნაგულისხმევი პულები, გამრავლებული რეპლიკებზედატვირთვის ტესტები ~420 კავშირის ბრტყელ პლატოზე ჩერდებოდა და „უფრო დიდ ბაზას" ითხოვდნენ. ნამდვილი ჭერი იყო max_connections Npgsql-ის ნაგულისხმევი პულების წინააღმდეგ.
- Argo CD აჩვენებდა Synced-ს, API სერვერმა კი ჩუმად გადააგდო ჩემი შესწორებათვეობით არ იყო მეტრიკები, შესწორება უკვე git-ში იდო და სტატუსი მწვანე Synced იყო. ველი CRD-ის სქემაში არ არსებობდა, API სერვერმა მოჭრა და არავინ იჩივლა.
- Postgres-ის რეპლიკა 23 საათი pg_rewind-ის ციკლში ტრიალებდა: ხელახლა შექმენით და ნუ შეაკეთებთfailover-ის შემდეგ CloudNativePG-ის რეპლიკამ rewind ვერ გააკეთა: მისი WAL-სეგმენტები ნულოვანი ზომის იყო, მონაცემთა კატალოგი კი primary-ზე ათჯერ პატარა. 23 საათი ვერავინ შეამჩნია, რადგან ოპერატორის მეტრიკები არ გროვდებოდა.
- პროდაქშენის Postgres-ის გადატანა RDS Multi-AZ instance-დან Multi-AZ DB cluster-ზედაგეგმილი cutover თითქმის მონაცემების დაკარგვის გარეშე — და სამი ხაფანგი: „ტექსამუშაოები“, რომლებმაც ჩაწერა ვერ შეაჩერეს, პაროლები, რომელთა კოპირებასაც RDS არ იძლევა, და დამპი 25 წუთში VPN-ით 31 წამის წინააღმდეგ VPC-ში.
- CloudNativePG-ის გადაყვანა Barman Cloud პლაგინზე არქივის გაწყვეტის გარეშეCNPG barmanObjectStore-ის ჩაშენებულ მხარდაჭერას აუქმებს. გადართვას ვალიდური შუალედური მდგომარეობა არ აქვს, ბაზას არც ერთი საბაზისო ბექაპი არ ჰქონდა, ერთი გზა კი წყვეტს, იმუშავებს თუ არა point-in-time recovery.
- ONLINE_UNCERTAIN: როცა MySQL ოპერატორი და ბაზა ვერ თანხმდებიანRouter ციმციმებს, ოპერატორი ორი დღეა ბლოკირებაშია, CRD 2/3-ზე გაიყინა — თან InnoDB Cluster-ის სამივე წევრი ჯანმრთელია. გამოსავალი მეტამონაცემების ერთი rescan იყო.
- სამი ინციდენტი, რომელიც ერთი აღმოჩნდა: კონფიგში ჩაწერილი მონაცემთა ბაზის IP500 შესვლისას, CrashLoopBackOff-ში მყოფი ბექენდები და გაჭედილი დეპლოი სამ პრობლემად გამოიყურებოდა. სამივე pgbouncer-ის კონფიგში ჩაწერილი ერთი IP აღმოჩნდა.
- ხუთი დღე 1/3-ზე მწვანე დაშბორდებით: როცა CRD-ის სტატუსი ცრუობსMySQL InnoDB Cluster ხუთი დღე HA-ს გარეშე მუშაობდა, რესურსის სტატუსი, პოდების ფაზა და readiness gate კი ჯანმრთელობას აჩვენებდნენ. სამივე სიგნალი ერთი გაჭედილი ოპერატორიდან მოდიოდა.