Upgrade a MinIO Deployment
MinIO uses an update-then-restart methodology for upgrading a deployment to a newer release:
Update the MinIO binary on all hosts with the newer release.
Restart the deployment using
mc admin service restart
.
This procedure does not require taking downtime and is non-disruptive to ongoing operations.
This page documents methods for upgrading using the update-then-restart method for both systemctl
and user-managed MinIO deployments.
Deployments using Ansible, Terraform, or other management tools can use the procedures here as guidance for implementation within the existing automation framework.
Test Upgrades In a Lower Environment
Your unique deployment topology, workload patterns, or overall environment requires testing of any MinIO upgrades in a lower environment (Dev/QA/Staging) before applying those upgrades to Production deployments, or any other environment containing critical data. Performing “blind” updates to production environments is done at your own risk.
For MinIO deployments that are significantly behind latest stable (6+ months), consider using MinIO SUBNET for additional support and guidance during the upgrade procedure.
Considerations
Upgrades Are Non-Disruptive
MinIO’s upgrade-then-restart procedure does not require taking downtime or scheduling a maintenance period. MinIO restarts are fast, such that restarting all server processes in parallel typically completes in a few seconds. MinIO operations are atomic and strictly consistent, such that applications using MinIO or S3 SDKs can rely on the built-in transparent retry without further client-side logic. This ensures upgrades are non-disruptive to ongoing operations.
“Rolling” or serial “one-at-a-time” upgrade methods do not provide any advantage over the recommended “parallel” procedure, and can introduce unnecessary complexity to the upgrade procedure. For virtualized environments which require rolling updates, you should amend the recommend procedure as follows:
Update the MinIO Binary in the virtual machine or container one at a time.
Restart the MinIO deployment using
mc admin service restart
.Update the virtual machine/container configuration to use the matching newer MinIO image.
Perform the rolling restart of each machine/container with the updated image.
Check Release Notes
MinIO publishes Release Notes for your reference as part of identifying the changes applied in each release. Review the associated release notes between your current MinIO version and the newer release such that you have a complete view of any changes.
Pay particular attention to any releases that are backwards incompatible. You cannot trivially downgrade from any such release.
Update systemctl
-Managed MinIO Deployments
Use these steps to upgrade a MinIO deployment where the MinIO server process is managed by systemctl
, such as those created using the MinIO DEB/RPM packages.
Update the MinIO Binary on Each Node
The following tabs provide examples of updating MinIO onto 64-bit Linux operating systems using RPM, DEB, or binary:
Use the following commands to download the latest stable MinIO RPM and update the existing installation.
wget https://dl.min.io/server/minio/release/linux-amd64/archive/minio-20230602231726.0.0.x86_64.rpm -O minio.rpm sudo dnf update minio.rpm
Use the following commands to download the latest stable MinIO DEB and upgrade the existing installation:
wget https://dl.min.io/server/minio/release/linux-amd64/archive/minio_20230602231726.0.0_amd64.deb -O minio.deb sudo dpkg -i minio.deb
Use the following commands to download the latest stable MinIO binary and overwrite the existing binary:
wget https://dl.min.io/server/minio/release/linux-amd64/minio chmod +x minio sudo mv minio /usr/local/bin/
Replace
/usr/local/bin
with the location of the existing MinIO binary. Runwhich minio
to identify the path if not already known.Restart the Deployment
Run the
mc admin service restart
command to restart all MinIO server processes in the deployment simultaneously.The restart process typically completes within a few seconds and is non-disruptive to ongoing operations.
mc admin service restart ALIAS
Replace alias of the MinIO deployment to restart.
Validate the Upgrade
Use the
mc admin info
command to check that all MinIO servers are online, operational, and reflect the installed MinIO version.Update MinIO Client
You should upgrade your
mc
binary to match or closely follow the MinIO server release. You can use themc update
command to update the binary to the latest stable release:mc update
Update Non-System Managed MinIO Deployments
Use these steps to upgrade a MinIO deployment where the MinIO server process is managed outside of the system (systemd
, systemctl
), such as by a user, an automated script, or some other process management tool.
This procedure only works for systems where the user running the MinIO process has write permissions for the path to the MinIO binary.
The mc admin update
command updates all MinIO server binaries in the target MinIO deployment before restarting all nodes simultaneously.
The restart process typically completes within a few seconds and is non-disruptive to ongoing operations.
For deployments managed using
systemctl
, see Update systemctl-Managed MinIO Deployments.For Kubernetes or other containerized environments, defer to the native mechanisms for updating container images across a deployment.
The following command updates a MinIO deployment with the specified alias to the latest stable release:
mc admin update ALIAS
You can specify a URL resolving to a specific MinIO server binary version. Airgapped or internet-isolated deployments may utilize this feature for updating from an internally-accessible server:
mc admin update ALIAS https://minio-mirror.example.com/minio
You should upgrade your mc
binary to match or closely follow the MinIO server release.
You can use the mc update
command to update the binary to the latest stable release:
mc update