Open-source database operator adds safer failover, encrypted PITR
An operator for the open-source relational database used by many web applications has added resource-aware tuning, transaction recovery during asynchronous failover and encrypted point-in-time recovery. Percona released version 1.3.0 of its open-source Operator for the database server on October 29, 2026. A Kubernetes operator is software that automates the deployment and operation of an application inside Kubernetes. Percona says this operator works on any Kubernetes distribution conforming to Cloud Native Computing Foundation standards.
Two changed defaults require attention before an upgrade. Leader election, the process that selects one controller to make decisions when several copies are running, is now enabled automatically. A single-controller development or debugging deployment can restore the previous behaviour by setting PSO_LEADER_ELECTION_ENABLED to false on the operator Deployment. The release also lets administrators tune leader-election settings through PSO_LEADER_ELECTION_* environment variables.
The more consequential upgrade change affects asynchronous clusters. Asynchronous replication acknowledges a committed transaction before a secondary database has necessarily received it. Version 1.3.0 requires backups to be enabled for these clusters and will refuse to reconcile, meaning bring the deployed system into line with its declared configuration, if they are absent. Administrators can instead set spec.unsafeFlags.asyncFailoverWithPossibleDataLoss to true. That restores fast promotion without attempting to recover transactions that remained only on the failed primary. Clusters using Group Replication are not affected.
Automatic tuning is configured under the automatic-configuration section in the cluster's custom resource, the Kubernetes document describing the desired database. Enabling it requires both CPU and memory limits because those limits provide the basis for calculating database server settings. Administrators select mostlyReads, someWrites, equalReadsWrites or heavyWrites as the loadType and provide a database server version in X.Y.Z form. Percona's example assigns 8 GiB of memory, four CPUs, the someWrites workload and database server version 8.4.0. The operator then sizes the buffer pool, the database server's main in-memory data cache, and related settings. It recalculates them when the resources or workload type change.
Settings that the database server permits to change while running are applied with SET GLOBAL, avoiding a restart. Static settings still require one, so the operator restarts the pods sequentially. A pod is a Kubernetes unit containing one or more closely related containers. This distinction matters operationally: automatic tuning reduces configuration drift after resource changes, but it does not make every database setting dynamically adjustable.
The new failover process addresses a specific weakness of asynchronous replication. If a primary fails after accepting transactions but before a replica reads the corresponding binary logs, which record database changes in sequence, an ordinary promotion can lose those transactions. Version 1.3.0 extends the xtrabackup sidecar on every database server pod. A sidecar is a supporting container that runs beside the database. Its POST /failover/stream endpoint on port 6450 can provide binary logs as a tar stream.
During failover, the tool first checks whether the failed primary has recovered. If not, it stops replication, flushes the relay logs held by the replica and reads Source_Log_File and Read_Source_Log_Pos to locate the missing section. It retrieves the absent binary logs from the failed primary's sidecar, cuts them back to the last complete transaction and joins them to the latest closed relay log. The SQL thread, which applies replicated changes to the local database, then runs until all salvaged transactions have been processed. Only after that does the orchestrator promote the selected replica.
This protection has an important boundary. The old primary's database server process may be down, but its pod and sidecar must remain reachable. By default, the failover tool has one hour from its first attempt to reach the source and apply the missing work. The timer is not reset for each retry. When it expires, the Abort policy leaves the cluster unpromoted, while ForceWithPossibleDataLoss proceeds despite the possible gap. The backup requirement is intended to ensure the supporting sidecar is present, but teams should still test whether their failure scenarios leave it accessible.
The release also encrypts binary logs sent to object storage for point-in-time recovery (PITR), which restores a backup and then replays recorded changes up to a chosen moment. It uses envelope encryption: every file receives its own data encryption key (DEK), and that key is protected by a key encryption key (KEK). The operator reads the KEK from a Kubernetes Secret rather than placing the master material on every database server pod. AES-256-CTR is the default symmetric cipher. The encryption configuration specifies the cipher and kekId, while keyringSecret identifies the Secret and its keyring file, whose default key is keyring.json.
During restoration, the PITR tool reads the file metadata, locates the named KEK, opens the per-file key and streams decrypted events through the binary-log replay utility into the restored database. A missing keyring or absent KEK causes an explicit failure before a partial recovery is produced. Percona's example combines enabled backups and PITR with an S3 bucket, credentials Secret, endpoint, region, AES-256-CTR, the KEK entry alpha and a separate binlog-server keyring Secret.
Other changes move more routine operations into the cluster specification. Application accounts can be declared in spec.users with databases, permitted hosts, grants, optional password Secret references and grant delegation. Backup storage can trust a custom certificate authority for private MinIO or other S3-compatible endpoints. TLS, the encryption used for network connections, can use a cluster-scoped cert-manager ClusterIssuer. Certificate rotation merges the old and new authorities, reloads leaf certificates without restarting the database server and removes the old authority after propagation is confirmed.
Backups can now have deadlines so an overlong job reports failure instead of hanging. Operator logs persist across controller restarts, replication lag reporting shows how far replicas trail, and DigitalOcean Kubernetes is officially supported. Database server version 9.7 joins the supported-version matrix. The release also includes even-sized asynchronous clusters, bootstrap from backup, ClusterSet rejoin and a replication-type switch marked as a tech preview, meaning it is available for evaluation rather than treated as a finished production feature.