v1.1.0

Upgrade instructions

Warning

If you are using everestctl v1.1.0 to upgrade from a version prior to v1.0.0 you need to run the following command before upgrading:

kubectl get deployments everest-operator-controller-manager -n everest-system -o jsonpath='{.spec.template.spec.containers[?(@.name=="manager")].env[?(@.name=="DB_NAMESPACES")].value}' | xargs -d ',' -I {} kubectl label namespaces {} app.kubernetes.io/managed-by=everest

Release highlights

Important

Percona Everest 1.1.0 comes with its own set of limitations that you should be aware of (see the Known Limitations section below).

Enhancements for PostgreSQL disaster recovery

We've made our backups and restores more reliable by setting limits on how we manage backup storage. This proactive approach ensures that we can prevent potential issues from being triggered in edge-case scenarios.

Here's how it works:

• You can have up to three backup storages in use at a time, across both on-demand backups and schedules.

  Example:
  If you already have two scheduled backups using storage bucket-1 and bucket-2, and an on-demand backup using bucket-3, you’ll need to use one of these three storages for any new on-demand backup or schedule.

  

  

  

• You can only create up to three backup schedules for PostgreSQL.

  

• You cannot change the storage location in existing schedules.

• You cannot use the same storage location for multiple backup schedules.

Improvements

• EVEREST-1259 - We've implemented a rate limiter to control how many API requests you can make within a set time frame. If you exceed this limit on the login page, you'll receive an error message.

• EVEREST-1134 --Starting with Percona Everest 1.1.0, you can now upgrade the database version directly from the Namespaces page, skipping the need to use the edit DB wizard.

• EVEREST-1153 - We've improved the CLI experience for install, upgrade, and uninstall commands by streamlining it with concise loading animations and spinners.

• EVEREST-1088 - We've removed the icons from the Technology column in the database list table.

• EVEREST-1196 - We've added a confirmation dialog that appears when you try to exit the wizard using the side navigation.

• EVEREST-1070 - We've updated the restore icon across Percona Everest for a consistent look.

• EVEREST-247 - We've updated the Postgresql database icon on the UI for better clarity and visibility.

Backups and schedules

• EVEREST-1092 - Starting with Percona Everest 1.1.0, you can no longer initiate an on-demand backup while another backup is in progress. This change helps maintain data integrity and minimizes potential impact on database performance.

• EVEREST-1220 - In Percona Everest 1.1.0, you're limited to using a maximum of three different backup storages for PostgreSQL, including those used in existing backup schedules. This restriction ensures reliable backup restoration.

• EVEREST-1071- We've introduced a Deleting state that remains active until all resources associated with the backup are fully removed.

• EVEREST-1214 - We've made it easier to manage backup schedules by removing the restriction on deleting PostgreSQL schedules.

• EVEREST-1223 - Starting with Percona Everest 1.1.0, you cannot edit the region and bucket for the existing backup storage.

• EVEREST-1226 - Starting with Percona Everest 1.1.0, you cannot create backup storages with the same bucket, region, and URL.

• EVEREST-1229 - For a better user experience, you can now see which backup storage is being used for both on-demand backups and schedules.

• EVEREST-910 - The schedule name and storage location for scheduled backups are now displayed on the UI.

Bugs fixed

• EVEREST-1233 - You will now see the correct error message when attempting to downgrade a major database version.

• EVEREST-740 - MySQL is now correctly selected as the default database engine when creating a database, even if it wasn't the first operator installed.

• EVEREST-1181 - The option to upgrade the major version of the database engine for MongoDB and PostgreSQL is now correctly disabled in the database edit section, reflecting the intended functionality.

• EVEREST-859 - The issue causing an error during namespace deletion while uninstalling Percona Everest has been resolved.

• EVEREST-1074 - The backup page performance is now optimized for adding and editing backup.

• EVEREST-1141 - Backup files in the S3 bucket are now properly removed when the corresponding database is deleted.

• EVEREST-1144 - While editing the backup storage in a PostgreSQL database backup schedule, an error was encountered after three backup schedules were created. The issue has been resolved now.

• EVEREST-1050 - The restore page now correctly updates the restore information.

• EVEREST-1244 - While attempting to restore a database, there was a discrepancy between the messages indicating the status of the restoration process and the actual actions being taken by Percona Everest. The issue has been resolved now.

• EVEREST-307 - CLI errors now display more user-friendly messages without exceptions and stack traces.

Known limitations

You can't use the same URL, bucket, and region in two different backup storages. Doing so may cause issues with restoring from the existing backups.

Here’s what you need to know:

Scenario 1

If you have multiple storages with the same bucket, URL, and region, you won’t be able to edit them after the 1.1.0 update. You’ll need to delete the duplicates.

To check whether your existing Everest installation has any backup storages using the same bucket, region, and endpoint URL, execute the following command:

curl -sS "https://raw.githubusercontent.com/percona/everest-doc/main/tools/bin/check-duplicated-storages.sh" | bash

Scenario 2

What to do if you have schedules or backups that are using duplicated storages in different database technologies.

• MongoDB, MySQL: create a new backup using a different backup storage. Then, delete the old schedules and backups that use the duplicated storage.
• PG: Any backups using duplicated backup storages should be deleted. First, delete the backups from both backup storages, then delete the backup schedules, and finally, delete the backup storages themselves. Then, create a new backup storage and take backups using the new backup storage.

v1.0.1

Fixed issues

Telemetry

• EVEREST-1231 - We've addressed an issue that was causing our telemetry to be disabled.

v1.0.0

What's new in Percona Everest 1.0.0

We proudly announce that Percona Everest has officially hit the general availability (GA) milestone with the release of version 1.0.0.

To begin your journey with Percona Everest, check out the Quickstart Guide for Percona Everest.

Percona Everest is an open source cloud native database platform that helps provision and manage databases faster, scale deployments rapidly, and reduce database administration overhead. Plus, you can regain control over your data, database configuration, and DBaaS costs.

Upgrading to Percona Everest 1.0.0

Note

Despite being a major version upgrade, we fully support upgrading from Percona Everest 0.10.1 to 1.0.0.

Check out our comprehensive documentation for all the details on how to upgrade to Percona Everest 1.0.0.

Release highlights

Version 1.0.0 introduces the following changes:

Simplified database operator upgrades

We are excited to announce that you can now upgrade database operators and all their components across any namespace with just a single click using our intuitive UI.

Moreover, before initiating the upgrade process, Everest provides a comprehensive list of tasks that must be completed to ensure a seamless transition of your clusters to the next version of the database operators.

For a deep dive into this feature, see our comprehensive documentation.

User management

Percona Everest 1.0.0 introduces user management features, enabling you to securely log in to the platform through either the Percona Everest user interface or the API. So, get ready for a more secure and user-friendly experience with this update.

Local user management involves administering Percona Everest users to ensure secure access to database resources. This encompasses tasks such as creating and deleting users, updating their passwords, etc.

If you’re looking for in-depth insights into this feature, see our documentation.

IdP integration for enhanced security

Starting with Percona Everest 1.0.0, you can now integrate your Percona Everest instance using an external identity provider (IdP). This enables centralized authentication and authorization management, streamlining and simplifying user access. By tapping into IdP integration, you can ensure that users are authenticated and authorized securely.

Percona Everest uses OpenID Connect (OIDC) Protocol to integrate with external Identity Providers (IdP).

To integrate IdP with Percona Everest, first install Percona Everest and then configure OIDC on the IdP's side as well as the Percona Everest side.

To explore the depths of this feature, delve into our documentation.

All new components page

We're always striving to enhance user experience, and we're excited to announce our latest addition – the Components page! This new page is your go-to destination for in-depth details about the pods and containers, such as their status, type, age, and much more.

New features

• EVEREST-816 - Starting with Percona Everest 1.0.0, you can now upgrade database operators and all their components across any namespace with just a single click using our intuitive UI.

• EVEREST-1087 - You can now integrate your Percona Everest instance using an external identity provider (IdP). This enables centralized authentication and authorization management, streamlining and simplifying user access.

• EVEREST-1025 - We introduced the user management feature with Percona Everest 1.0.0, enabling you to securely log in to the platform through either the user interface or the API.

• EVEREST-974 - Everest now supports editing the DB Engine version after a cluster has been created. However, it's important to note the following restrictions:

  • You are unable to upgrade to a different major version.
  • Downgrading the DB Engine version is not supported.

• EVEREST-1069 - We've recently introduced a new page - the components page. This page provides detailed information about the pods and containers, including their status, type, age, and more.

• EVEREST-866 - Starting with Percona Everest 1.0.0, you can restore your database from a full backup or using the PITR. However, if you choose a backup other than the latest backup, the PITR option becomes unavailable.

• EVEREST-872 - When deleting a backup, you can now choose to delete the data from the backup storage as well.

• EVEREST-873 - When attempting to delete a database, you now have the option to delete the data as well from the backup storage. However, for PostgreSQL databases, the backup storage data is retained.

• EVEREST-731 - Added support for customizing load balancer source ranges in PostgreSQL clusters.

Improvements

• EVEREST-909 - Percona Everest now validates scheduled backups if another backup is already scheduled for the same time and location.

• EVEREST-924 - Starting with Percona Everest 1.0.0, you now have the option to create multiple backup schedules using the wizard.

• EVEREST-931 - When you go through a wizard, return to a specific step, and delete something from a mandatory field, the editing functionality is now disabled.

• EVEREST-1055 - Starting with Percona Everest 1.0.0, we have introduced a new deleting state. This state will persist until all resources associated with the database have been removed.

• EVEREST-953 - For an improved user interface (UI) experience, we have consolidated backups and PITR on the same page.

• EVEREST-971 - Access and secret key inputs are now visible on the UI when adding a storage location. You can use the eye icon to toggle between making the keys visible or hidden. This feature allows you to conveniently view the S3 keys directly from the UI.

• EVEREST-1007 - For an improved user experience, the Actions button has been moved to the Database Details tab on the right side of the database name.

• EVEREST-937 - We have made some improvements in our telemetry, including sending telemetry data about the DB cluster every time a user creates one and adding information about the Everest version reported for the instance ID.

Bugs

• EVEREST-807 - Fixed an issue where PITR did not display the storage location being used when enabling PITR during database creation or editing.

• EVEREST-837 - We have now updated the help for the Command Line Interface (CLI) commands to include the descriptions.

• EVEREST-841 - Fixed an issue where the user interface (UI) could not identify the correct operator/database cluster for different namespaces.

• EVEREST-869 - Fixed an issue where everestctl install failed to revert to the default namespace when the namespace was left blank.

• EVEREST-870 - When running the everestctl install command, the installation wizard asked for values such as namespaces and operators, even though the values were already provided by flags (--namespaces=everest --operator.mongodb=false --operator.postgresql=false --operator.xtradb-cluster=true). The issue has been resolved now.

• EVEREST-1003 - Resolved an issue where the installation of operators in a new namespace was failing.

• EVEREST-1016 - We updated the Last backup status from inactive to scheduled because it was confusing for the users.

• EVEREST-1034 - The Restores page did not display the restores in a sorted order. The issue has been resolved now.

• [EVE...

v0.10.1

Fixed issues

Backups

• EVEREST-1061 - We fixed a race condition in the Everest operator where backups deleted due to retention policies were re-created. We fixed the issue and ensured that completed backups were not reconciled.
• EVEREST-1064 - While configuring a backup schedule for the MongoDB cluster, duplicate backups of the same data were generated in S3, whereas only a single backup was produced in Everest. The issue has been resolved now.

Restores

• EVEREST-1082 - Attempting to restore a MongoDB backup to a new database failed if the backup storage used a self-signed certificate. This issue has been resolved now.

• EVEREST-1054 - While restoring a PostgreSQL database cluster, we encountered an issue connecting to an S3-compatible bucket with a self-signed certificate. This problem caused the restored cluster to become unresponsive and enter an unknown state. The issue has been resolved now.

Retention copies

• EVEREST-979 - When the retention were specified in a backup schedule, the Everest operator successfully deleted the backup objects from Kubernetes. However, it failed to clean up the data on S3. This issue has been resolved now.

Known limitations

Backups for PostgreSQL do not work with GCP S3 compatible API.

v0.10.0

Release highlights

Simplified Percona Everest upgrades

Warning

• You need to download CLI version >=0.10.0 for the upgrade command to work.
• Upgrade works only if you have Percona Everest version 0.9.0 or higher installed.

We're thrilled to announce that you can now upgrade your Percona Everest instance using our Command Line Interface (CLI). The CLI upgrade process is simple and straightforward, enabling you to quickly upgrade your Everest to the latest version.

You can only upgrade one minor version at a time. For instance, you can upgrade from version 0.9.0 to version 0.10.0.

For more information on upgrading Percona Everest, see our documentation.

Streamlining traffic management with API rate limiting

Starting with Percona Everest 0.10.0 version, we have introduced a new feature called API rate limiting.

API rate limiting is one of the key aspects of managing API's. With this you can set a threshold for the number of requests your API can receive within a specific period. This means you can take control and regulate the incoming traffic, mitigating the risk of server overload or abuse.

The default rate limit for Percona Everest is 100 requests per second. However, you can customize these limits according to your usage patterns and requirements. To dive deep into this feature, see our comprehensive documentation.

Added control for TLS certificate validation

With the release of Percona Everest 0.10.0, you can add backup storages and monitoring instances without verifying the Transport Layer Security (TLS) certificate. TLS certificate verifies the server's certificate chain and hostname, ensuring its authenticity.

When using a self-signed TLS certificate, the TLS certificate validation will fail as the certificate has not been issued by a trusted authority. To overcome this issue, you may need to skip the TLS certificate validation.

Skipping certificate validation is recommended only when there is no need to ensure the authenticity of the server holding the certificate. For example, if you have a private network where you have complete control over everything, the identity check may not be required.

New features and improvements

• EVEREST-793 - Starting with Percona Everest 0.10.0, you can upgrade your Percona Everest instance using the CLI (everestctl).

• EVEREST-396 - You can now add monitoring instances without verifying the TLS certificates.

• EVEREST-964 - Starting with Percona Everest 0.10.0, we have introduced a new feature called API rate limiting. With this you can set a threshold for the number of requests your API can receive within a specific period.

• EVEREST-935 - Previously, the cancel button was disabled while editing anything in the wizard. This button is now enabled.

• EVEREST-928 - We have updated all the labels on the buttons to sentence case for consistency.

• EVEREST-938 - Restoring a database using PITR now includes a backup storage name.

Backups

• EVEREST-895 - You can now add backup storage without verifying the TLS certificates.

• EVEREST-919 - You can now access backup storage with path-style URLs.

• EVEREST-668 - We have introduced Retention copies while creating backup schedules. Retention copies refer to the number of backup instances that should be kept.

• EVEREST-819 - Due to the current limitation of PostgreSQL, you can only create up to 3 schedules. To avoid confusion, we have added a tooltip that states this limitation.

• EVEREST-911 - We added a new column to the database view displaying the time of the last backup.

• EVEREST-912 - We have added an icon and tooltip to the backups column.

Bugs fixed

• EVEREST-385 - Previously, there was an issue where the backup and pods associated with a database cluster were not being deleted when the cluster itself was deleted. The issue has been resolved now.

• EVEREST-846 - Fixed an issue where the new database contained the backups of the old database with the same name.

• EVEREST-921 - We have resolved an issue that prevented users from logging in immediately after logging out.

• EVEREST-947 - While attempting to uninstall Percona Everest, an error occurred which prevented the uninstallation process from completing successfully. The issue has now been resolved.

• EVEREST-948 - The actionable Alert button was not visible in the dark theme. The issue has been resolved now.

• EVEREST-967 - Fixed an issue where the last backup information was inaccurate.

• EVEREST-940 - The documentation link on Point-in-time recovery option for PostgreSQL was opening in the same tab. The issue has been resolved now.

v0.9.1

Release highlights

Warning

Percona Everest introduces a breaking change that prevents you from directly upgrading to version 0.9.1.
To install Percona Everest 0.9.1, make sure to uninstall any previous versions by running the command:
everestctl uninstall

Fixed issues

• EVEREST-949 - We have updated the quick install script to correct the URL for downloading the CLI (everestctl). Previously, the script failed because of an incorrect URL.

v0.9.0

Warning

To install Percona Everest 0.9.0, first uninstall the previous version.

Release highlights

We've taken a step forward in enhancing Percona Everest's point-in-time (PITR) capabilities for PostgreSQL, MySQL as well as MongoDB databases.

You can now restore your databases to specific points in time within the same cluster as well as a new cluster. This gives you more control over your database environments and more options for data recovery.

If you're looking for in-depth insights into this feature, refer to the sections Create new database from a point-in-time recovery and Restore to a point-in-time recovery in our documentation.

New features and improvements

• EVEREST-618, EVEREST-620 - Starting with Percona Everest 0.9.0, you can now create a new database using point-in-time recovery for your MySQL and MongoDB databases. If you're looking to explore this feature further, see our comprehensive documentation.

• EVEREST-914 - We have added a Kubernetes cluster ID to the VMAgent configuration, enabling you to use the same PMM instance to monitor multiple Kubernetes clusters.

• EVEREST-871 - We have improved Percona Everest to ensure you don't accidentally delete a cluster. We've introduced a confirmation pop-up that will prompt you to enter the database's name correctly. Only when the correct database name is entered can you proceed with deleting the cluster.

Point-in-time recovery for PostgreSQL

• EVEREST-598 - We have now added support for Point-In-Time Recovery (PITR) functionality for PostgreSQL databases.

• EVEREST-624 - We have added a message on the Percona Everest UI for PostgreSQL informing users that Point-in-time recovery (PITR) is enabled by default and cannot be turned off.

• EVEREST-619 - Starting with Percona Everest 0.9.0, you can now create a new database using point-in-time recovery for your PostgreSQL databases.

• EVEREST-896 - We have added a warning on the Percona Everest UI to inform users about the limitations of PostgreSQL for PITR.

Bugs fixed

• EVEREST-656 - While initiating a backup for MongoDB, the backup status was being displayed as unknown. The issue has been resolved now.

• EVEREST-759 - We have added an error message to the Percona Everest UI for scheduled backups, which reminds you to set a backup storage location before configuring backup schedules to avoid any hassles.

• EVEREST-786 - Fixed an issue where the PMM monitoring URL accepted incorrect credentials.

• EVEREST-813 - When choosing the appropriate cluster size (small, medium, large) on the Resources page, the selector invariably switched to the Custom option. The issue has been resolved now.

• EVEREST-856 - When editing a database with multiple backup schedules, an error was thrown. The issue has been resolved now.

• EVEREST-862 - We resolved an issue where the column hide/unhide option was not functioning correctly on various UI pages.

• EVEREST-885 - Fixed an issue where the Quick install script did not work on Linux machines with ARM CPUs.

• EVEREST-887 - Storage location could not be chosen if scheduled backups were enabled for the first time while editing a MongoDB database.

• EVEREST-888 - When creating a backup, the Backup storage field was not automatically populated as it was for scheduled backups. We have resolved this issue now.

• EVEREST-890 - We have fixed an issue that was causing problems with restoring data to a new MySQL database using point-in-time recovery (PITR).

• EVEREST-913 - We corrected the AWS load balancer type for the HAProxy replicas to use the network LB type when enabling external access to the DB cluster instead of the classic LB type.