chore(deps): update dependency mariadb-operator/mariadb-operator to v26 #4704
Reference in New Issue
Block a user
Delete Branch "renovate/major-unified-mariadb-operatormariadb-operator"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
25.10.4→26.3.0Release Notes
mariadb-operator/mariadb-operator (mariadb-operator/mariadb-operator)
v26.3.0Compare Source
mariadb-operator26.03 is here! 🦭Welcome to another release of
mariadb-operator! In this version, we have significantly enhanced our disaster recovery capabilities by adding support for on-demand physical backups, Azure Blob Storage and... (🥁)... Point-In-Time-Recovery ✨.Additionally, we've received a bunch of contributions by our amazing community during this release, including bug fixes and new features. We feel very grateful for your efforts and support, thank you! 🙇♂️ Refer to the PRs in the changelog below for further details.
If you're upgrading from previous versions, do not miss the UPGRADE GUIDE for a smooth transition.
Point-In-Time-Recovery
Point-in-time recovery (PITR) is a feature that allows you to restore a
MariaDBinstance to a specific point in time. For achieving this, it combines a full base backup and the binary logs that record all changes made to the database after the backup. This is something fully automated by operator, covering archival and restoration up to a specific time, ensuring business continuity and reduced RTO and RPO.In order to configure PITR, you need to create a
PhysicalBackupobject to be used as full base backup. For example, you can configure a nightly backup:Next step is configuring common aspects of both binary log archiving and point-in-time restoration by defining a
PointInTimeRecoveryobject:The new
PointInTimeRecoveryCR is just a configuration object that contains shared settings for both binary log archiving and point-in-time recovery. It has also a reference to aPhysicalBackupCR, used as full base backup.In order to configure binary log archiving, you need to set a reference to the
PointInTimeRecoveryCR in theMariaDBobject:This will enable the binary log archival in the sidecar agent, which will eventually report the last recoverable time via the
PointInTimeRecoverystatus:In order to perform a point-in-time restoration, you can create a new
MariaDBinstance with a reference to thePointInTimeRecoveryobject in thebootstrapFromfield, along with thetargetRecoveryTime, which should be before or at the last recoverable time:The restoration process will match the closest physical backup before or at the
targetRecoveryTime, and then it will replay the archived binary logs from the backup GTID position up until thetargetRecoveryTime.Refer to the PITR docs for additional details.
Azure Blob Storage
So far, we have only supported S3-compatible storage as object storage for keeping the backups. We are now introducing native support for Azure Blob Storage in the
PhysicalBackupandPointInTimeRecoveryCRs. You can configure it under thestoragefield, similarly to S3:Refer to the physical backup storage docs for additional details.
It is important to note that we couldn't find the bandwidth to support it for
Backupresource (logical backup) in this release, contributions are welcomed!Kudos to our co-maintainer @Michaelpalacce for smoothly driving this feature end-to-end!
On-demand
PhysicalBackupWe have introduced the ability to trigger on-demand physical backup manually. For doing so, you need to provide an identifier in the
schedule.onDemandfield of thePhysicalBackupresource:Once scheduled, the operator tracks the identifier under the status subresource. If the identifier in the status differs from
schedule.onDemand, the operator will trigger a new physical backup.Refer to the physical backup scheduling docs for additional details.
Behaviour change in
targetRecoveryTimeTo satisfy requirements of point-in-time recovery, we have unified the behaviour of the
bootstrapFrom.targetRecoveryTimefield in theMariaDBobject: Logical and physical backup files whose timestamp is closest totargetRecoveryTime, but not after, will be matched.Please take this into account when upgrading to this version.
Change in Helm
values.yamlconfighas been split intorepositoryandtagto facilitate overriding the image registry (see #1632). Please update yourvalues.yamlfrom:to the following format:
Updated dependencies
Updated roadmap
The next feature to be supported is the new multi-cluster topology. Stay tuned!
Point In Time Recovery (PITR)Community
Contributions of any kind are always welcome: adding yourself to the list of adopters, reporting issues, submitting pull requests, or simply starring the project! 🌟
Enterprise
For enterprise users, see the MariaDB Enterprise Operator, a commercially supported Kubernetes operator from MariaDB with additional enterprise-grade features.
What's Changed
MariaDBby @mmontes11 in #1650PointInTimeRecovery, Azure Blob Storage & on-demandPhysicalBackupsby @mmontes11 in #1517New Contributors
Full Changelog: https://github.com/mariadb-operator/mariadb-operator/compare/25.10.4...26.3.0
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.
620e020ceato3efcc971d6