升级 Metabase
本页面介绍如何升级到新的 Metabase 版本。
升级 Metabase Cloud
如果您使用的是 Metabase Cloud 套餐，我们会为您自动升级 Metabase 至新版本；无需您采取任何操作（除非您使用了嵌入式分析 SDK）。
我们升级您的速度取决于发布的类型
- 次要版本（例如，x.54.4 到 x.54.5）：通常需要一周左右。
- 主要版本（例如，x.53.4 到 x.54.1）：时间较长，通常需要几个月（以确保一切顺利）。
Cloud 客户可以通过发送电子邮件至 help@metabase.com 联系支持团队，请求提前升级。请在邮件中包含您希望我们升级的 Metabase 的 URL。
在 Metabase Cloud 上使用嵌入式分析 SDK 的实例必须请求升级
如果您在 Metabase Cloud 上使用 嵌入式分析 SDK，我们会固定您的版本，使其不会自动升级，因为您应该在升级前测试更改。
要升级您的 Metabase，您需要 联系支持团队 来请求升级。
请参阅我们的 嵌入式分析 SDK 升级指南。
升级自托管的 Metabase
以下是将 Metabase 升级到新版本（主要版本或次要版本）的步骤
1. 备份您的应用程序数据库
应用程序数据库会记录您 Metabase 实例的所有信息（但不包括连接数据库的数据）。虽然您不太可能需要回滚到当前版本，但在发生意外情况时，备份将让您更加安心。
请参阅 备份 Metabase 应用程序数据。
2. 替换为新版 Metabase
具体步骤取决于您使用的是容器镜像还是 JAR 文件。
升级容器镜像
-
停止当前容器。
-
拉取最新的 Metabase Docker 镜像（但我们建议您拉取特定标签，而不是使用
latest）。Metabase 开放源代码
docker pull metabase/metabase:latestMetabase Pro 或 Enterprise
docker pull metabase/metabase-enterprise:latest -
启动新的容器镜像。根据端口和容器名称，命令大致如下：
Metabase 开放源代码
docker run -d -p 3000:3000 -e MB_DB_CONNECTION_URI="jdbc:postgresql://<host>:5432/metabase?user=<username>&password=<password>" --name metabase metabase/metabase:latestMetabase Pro 或 Enterprise
docker run -d -p 3000:3000 -e MB_DB_CONNECTION_URI="jdbc:postgresql://<host>:5432/metabase?user=<username>&password=<password>" --name metabase metabase/metabase-enterprise:latest
启动时，Metabase 将自动执行升级。Metabase 完成升级后，您将运行新版本。
升级 JAR 文件
要进行升级，您需要停止服务，用新版本替换 JAR 文件，然后重新启动服务。
例如，如果您使用 Nginx 作为服务在 Debian 上运行 Metabase。
-
停止 Metabase 服务。假设您的服务名为
metabase.service，您将运行sudo systemctl stop metabase.service -
下载最新版本的 JAR 文件
并用下载的较新 JAR 文件替换当前（较旧）的 Metabase JAR 文件。
-
重启服务
sudo systemctl restart metabase.service
从旧版本 Metabase 升级
如果您使用的是 Metabase 40 之前的版本，您需要逐个版本升级，直到达到 Metabase 40 的最新版本。从 Metabase 40 的最新版本开始，您可以跳到当前版本的 Metabase。
例如，如果您运行的是 Metabase 1.38，您的升级路径将如下所示：
- 1.38.X
- 1.39.X
- 1.40.X
- 最新
其中 X 是每个版本可用的最新版本。
请查看 Metabase 版本列表。
在主要版本之间升级（例如，v53.x 到 v54.x）时，请使用该主要版本可用的最新次要版本。例如，如果您想从 v50 升级到 v51，请使用 51 版本可用的最新小版本。
在其他平台上升级 Metabase
升级或降级时会发生什么？
在进行主要版本升级（例如，53.1 或 54.1）期间，Metabase 将：
- 执行所有必要的迁移以升级到新版本，例如两个版本之间应用程序数据库的任何模式更改。
- 保留其在应用程序数据库上工作所需的所有元数据。
Metabase 将自动完成所有这些操作。
如果您在主要版本升级后需要降级，您需要恢复备份，或手动迁移到较低版本，否则 Metabase 可能会拒绝启动（请参阅下一节）。
在进行次要版本升级（例如，54.1 到 54.2）期间，新的 Metabase 容器或 Jar 将正常工作。只有在极少数情况下需要执行迁移，但与主要版本升级一样，Metabase 会自动执行迁移。当然，每次升级时您都会备份您的应用程序数据库，对吧？
回滚升级或到旧版本
降级命令必须在具有较高版本号的 JAR 上运行。
通常，定期备份（尤其是在升级前备份）是最佳策略，因此我们建议恢复应用程序数据库的备份来回滚升级。
但是，如果您在升级后进行了任何更改（例如添加了新的问题/仪表板等）并希望保留这些更改，您可以使用 migrate down 命令将 Metabase 应用程序数据库回滚到之前运行的 Metabase 版本。当 Metabase 升级到新版本时，它会运行迁移，这些迁移可能会更改应用程序数据库的模式。 migrate down 命令将撤销这些模式更改。总的来说，我们建议从备份恢复（您记得在升级前生成的备份），并且仅在需要保留升级后所做的更改时才使用 migrate down 命令。
使用 migrate down 命令
停止您的 Metabase，并使用当前已升级的 Metabase JAR（而不是您要回滚到的 Metabase JAR）来完成回滚，运行 migrate down 命令。确保您的应用程序数据库的连接详细信息已在环境变量中设置，例如：
export MB_DB_TYPE=postgres
export MB_DB_DBNAME=metabaseappdb
export MB_DB_PORT=5432
export MB_DB_USER=username
export MB_DB_PASS=password
export MB_DB_HOST=localhost
java --add-opens java.base/java.nio=ALL-UNNAMED -jar metabase.jar migrate down
如果您正在运行 Docker，请使用命令 "migrate down"（"migrate down" 周围带有引号），并包含您的应用程序数据库的连接详细信息，例如：
docker run
-e "MB_DB_TYPE=postgres" \
-e "MB_DB_DBNAME=metabaseappdb" \
-e "MB_DB_PORT=5432" \
-e "MB_DB_USER=name" \
-e "MB_DB_PASS=password" \
-e "MB_DB_HOST=my-database-host" \
--rm metabase/metabase:<tag> "migrate down"
注意 "migrate down" 周围的引号。您也可以直接打开容器的 shell，并在其中运行 migrate 命令。
迁移过程完成后，使用您想要运行的版本对应的 JAR 或容器镜像来启动 Metabase。
升级集群中运行的 Metabase
如果您正在集群中运行 Metabase
- 将节点数量减少到一个。您不能同时升级所有节点，因为升级过程是通过从单个客户端获取应用程序数据库的迁移锁来执行的。如果您在进行主要版本升级时保留一个以上的节点处于活动状态，应用程序将无法正常工作，因为应用程序数据库的模式更改可能会导致仍在运行旧版本 Metabase 的节点出现问题。
- 按正常方式执行升级（如上所述）。
- 将节点数量增加到之前的数量。
请确保您的容器编排器或集群管理器在 Metabase 执行迁移时不会终止 Metabase 进程，否则您可能会导致应用程序数据库损坏，需要从备份恢复。
阅读其他版本的 Metabase 的文档。