Database operator me burim të hapur shton failover më të sigurt dhe PITR të enkriptuar
Një operator për bazën relacionale të të dhënave me burim të hapur që përdoret nga shumë aplikacione web ka shtuar akordim sipas burimeve, rikuperim të transaksioneve gjatë failover asinkron dhe point-in-time recovery të enkriptuar. Më 29 tetor 2026, Percona publikoi versionin 1.3.0 të Operator me burim të hapur për serverin e bazës së të dhënave. Një Kubernetes operator është softuer që automatizon vendosjen dhe funksionimin e një aplikacioni brenda Kubernetes. Percona thotë se ky operator funksionon në çdo shpërndarje Kubernetes që përputhet me standardet e Cloud Native Computing Foundation.
Dy vlera të parazgjedhura që kanë ndryshuar kërkojnë vëmendje përpara një përmirësimi. Leader election, procesi që zgjedh një controller për të marrë vendime kur janë duke funksionuar disa kopje, tani aktivizohet automatikisht. Një vendosje zhvillimi ose diagnostikimi me një controller të vetëm mund të rikthejë sjelljen e mëparshme duke vendosur PSO_LEADER_ELECTION_ENABLED në false te Deployment i operator. Publikimi u lejon gjithashtu administratorëve të akordojnë cilësimet e leader election përmes variablave të mjedisit PSO_LEADER_ELECTION_*.
Ndryshimi më i rëndësishëm i përmirësimit prek cluster asinkrone. asynchronous replication konfirmon një transaksion të kryer përpara se një bazë dytësore të dhënash ta ketë marrë domosdoshmërisht atë. Versioni 1.3.0 kërkon që backup të jenë të aktivizuara për këto cluster dhe do të refuzojë të kryejë reconcile, domethënë ta sjellë sistemin e vendosur në përputhje me konfigurimin e deklaruar, nëse ato mungojnë. Në vend të kësaj, administratorët mund ta vendosin spec.unsafeFlags.asyncFailoverWithPossibleDataLoss në true. Kjo rikthen promovimin e shpejtë pa u përpjekur të rikuperojë transaksionet që mbetën vetëm në primary që dështoi. Cluster që përdorin Group Replication nuk preken.
Akordimi automatik konfigurohet nën seksionin automatic-configuration në custom resource të cluster, dokumenti Kubernetes që përshkruan gjendjen e dëshiruar të bazës së të dhënave. Aktivizimi i tij kërkon kufij si për CPU-në, ashtu edhe për memorien, sepse këta kufij shërbejnë si bazë për llogaritjen e cilësimeve të serverit të bazës së të dhënave. Administratorët zgjedhin mostlyReads, someWrites, equalReadsWrites ose heavyWrites si loadType dhe japin një version të serverit të bazës së të dhënave në formatin X.Y.Z. Shembulli i Percona cakton 8 GiB memorie, katër CPU, ngarkesën someWrites dhe versionin 8.4.0 të serverit të bazës së të dhënave. Më pas operator përcakton madhësinë e buffer pool, cache kryesore në memorie e të dhënave të serverit të bazës së të dhënave, si edhe cilësimet përkatëse. Ai i rillogarit ato kur ndryshojnë burimet ose lloji i ngarkesës.
Cilësimet që serveri i bazës së të dhënave lejon të ndryshohen gjatë funksionimit zbatohen me SET GLOBAL, duke shmangur restart. Cilësimet statike vazhdojnë ta kërkojnë atë, ndaj operator i rinis pod në mënyrë të njëpasnjëshme. Një pod është një njësi Kubernetes që përmban një ose më shumë container të lidhur ngushtë. Ky dallim ka rëndësi operacionale: akordimi automatik zvogëlon devijimin e konfigurimit pas ndryshimeve të burimeve, por nuk e bën çdo cilësim të bazës së të dhënave të rregullueshëm në mënyrë dinamike.
Procesi i ri i failover trajton një dobësi specifike të asynchronous replication. Nëse një primary dështon pasi ka pranuar transaksione, por përpara se një replica të lexojë binary logs përkatëse, të cilat regjistrojnë ndryshimet e bazës së të dhënave sipas radhës, një promovim i zakonshëm mund t'i humbasë këto transaksione. Versioni 1.3.0 zgjeron xtrabackup sidecar në çdo pod të serverit të bazës së të dhënave. Një sidecar është një container mbështetës që funksionon përkrah bazës së të dhënave. Endpoint POST /failover/stream i tij në portën 6450 mund t'i ofrojë binary logs si një tar stream.
Gjatë failover, mjeti kontrollon fillimisht nëse primary që dështoi është rikuperuar. Nëse jo, ai ndalon replication, shkruan në disk relay logs që mbahen nga replica dhe lexon Source_Log_File dhe Read_Source_Log_Pos për të gjetur pjesën që mungon. Ai merr binary logs që mungojnë nga sidecar i primary që dështoi, i shkurton deri te transaksioni i fundit i plotë dhe i bashkon me relay log më të fundit të mbyllur. SQL thread, i cili zbaton ndryshimet e replikuara në bazën lokale të të dhënave, më pas funksionon derisa të jenë përpunuar të gjitha transaksionet e shpëtuara. Vetëm pas kësaj orchestrator promovon replica e zgjedhur.
Kjo mbrojtje ka një kufi të rëndësishëm. Procesi i serverit të bazës së të dhënave në primary e vjetër mund të mos funksionojë, por pod dhe sidecar i tij duhet të mbeten të arritshëm. Si vlerë e parazgjedhur, mjeti i failover ka një orë nga përpjekja e tij e parë për të arritur source dhe për të zbatuar punën që mungon. Kohëmatësi nuk rivendoset për çdo riprovë. Kur koha mbaron, politika Abort e lë cluster pa u promovuar, ndërsa ForceWithPossibleDataLoss vazhdon pavarësisht boshllëkut të mundshëm. Kërkesa për backup synon të sigurojë që sidecar mbështetës të jetë i pranishëm, por ekipet duhet të testojnë përsëri nëse skenarët e tyre të dështimit e lënë atë të arritshëm.
Publikimi enkripton gjithashtu binary logs që dërgohen në object storage për point-in-time recovery (PITR), i cili rikthen një backup dhe më pas riluajnë ndryshimet e regjistruara deri në një moment të zgjedhur. Ai përdor envelope encryption: çdo skedar merr data encryption key (DEK) të vetin dhe ky key mbrohet nga një key encryption key (KEK). operator lexon KEK nga një Kubernetes Secret në vend që ta vendosë materialin master në çdo pod të serverit të bazës së të dhënave. AES-256-CTR është symmetric cipher i parazgjedhur. Konfigurimi i enkriptimit përcakton cipher dhe kekId, ndërsa keyringSecret identifikon Secret dhe skedarin e tij keyring, key i parazgjedhur i të cilit është keyring.json.
Gjatë rikthimit, mjeti PITR lexon metadata e skedarit, gjen KEK e emërtuar, hap key për çdo skedar dhe transmeton event të dekriptuara përmes mjetit të riluajtjes së binary logs në bazën e rikthyer të të dhënave. Mungesa e keyring ose e KEK shkakton një dështim të qartë përpara se të prodhohet një rikuperim i pjesshëm. Shembulli i Percona kombinon backup dhe PITR të aktivizuara me një S3 bucket, Secret të kredencialeve, endpoint, region, AES-256-CTR, hyrjen KEK alpha dhe një Secret të veçantë keyring për binlog-server.
Ndryshime të tjera zhvendosin më shumë operacione rutinë në specifikimin e cluster. Llogaritë e aplikacioneve mund të deklarohen në spec.users me bazat e të dhënave, host e lejuar, grants, referenca opsionale te Secret i fjalëkalimit dhe delegim të grants. Backup storage mund t'i besojë një certificate authority të personalizuar për endpoint private MinIO ose endpoint të tjera të pajtueshme me S3. TLS, enkriptimi që përdoret për lidhjet e rrjetit, mund të përdorë një cert-manager ClusterIssuer me fushëveprim në nivel cluster. Rotacioni i certifikatave bashkon authority të vjetër dhe të ri, ringarkon leaf certificates pa rinisur serverin e bazës së të dhënave dhe heq authority të vjetër pasi konfirmohet përhapja.
Backup tani mund të kenë afate, në mënyrë që një job që zgjat tepër të raportojë dështim në vend që të mbetet pezull. Logs e operator ruhen pas restart të controller, raportimi i replication lag tregon se sa prapa mbeten replica dhe DigitalOcean Kubernetes mbështetet zyrtarisht. Versioni 9.7 i serverit të bazës së të dhënave i shtohet matricës së versioneve të mbështetura. Publikimi përfshin gjithashtu cluster asinkrone me numër çift anëtarësh, bootstrap nga backup, ribashkim në ClusterSet dhe një ndryshim të llojit të replication të shënuar si tech preview, që do të thotë se ofrohet për vlerësim dhe nuk trajtohet si një veçori e përfunduar për production.