Skip to content

v1.1.1
Compare
Choose a tag to compare
@github-actions github-actions released this 22 Aug 12:58
· 235 commits to main since this release
v1.1.1
be3e3ec

Upgrade instructions

Warning

If you are using everestctl v1.1.1 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.1 comes with its own set of limitations that you should be aware of (see the Known Limitations section below).

Fixed issues

  • EVEREST-1349 - While attempting to delete a database cluster after upgrading from Percona Everest version 1.0.x to 1.1.0, the databases provisioned in v1.0.x were stuck in the Deleting state. The issue has been resolved now.

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.1 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.
Assets 7
Loading