升级 Metabase
本页介绍如何升级到新的 Metabase 版本。
升级 Metabase 云
如果您使用的是 Metabase 云 计划，我们会在每次新版本发布时自动升级您的 Metabase；您无需采取任何行动（除非您正在使用嵌入式分析 SDK）。
我们何时为您升级取决于发布类型
- 次要版本发布（例如，x.54.4 到 x.54.5）：通常大约一周。
- 主要版本发布（例如，x.53.4 到 x.54.1）：时间较长，通常是几个月（只是为了确保一切顺利）。
云客户可以通过发送电子邮件至 help@metabase.com 联系支持团队，请求提前升级。请附上您希望我们升级的 Metabase 的 URL。
在 Metabase 云上使用嵌入式分析 SDK 的实例必须请求升级
如果您在 Metabase 云上使用 嵌入式分析 SDK，我们会锁定您的版本，使其不会自动升级，因为您应该在升级前测试更改。
要升级您的 Metabase，您需要通过联系支持团队请求升级。
请参阅我们的嵌入式分析 SDK 升级指南。
升级自托管 Metabase
以下是升级到新 Metabase 版本（主要或次要）的步骤
1. 备份您的应用程序数据库
应用程序数据库会跟踪您的 Metabase 实例的所有内容（除了您连接的数据库中的数据）。虽然您不太可能需要回滚到当前版本，但如果出现问题，备份将让您高枕无忧。
2. 替换为新的 Metabase 版本
步骤因您运行的是容器镜像还是 JAR 而异。
升级容器镜像
-
停止当前容器。
-
拉取最新的 Metabase Docker 镜像（但我们建议您拉取特定标签而不是使用
latest）。Metabase 开放源代码
docker pull metabase/metabase:latestMetabase 专业版或企业版
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 专业版或企业版
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，然后重新启动服务。
例如，如果您在 Debian 上使用 Nginx 将 Metabase 作为服务运行。
-
停止 Metabase 服务。假设您将服务命名为
metabase.service，您将运行sudo systemctl stop metabase.service -
下载最新版本的 JAR 文件
并用您下载的新 JAR 文件替换当前（旧）的 Metabase JAR 文件。
-
重新启动服务
sudo systemctl restart metabase.service
从旧版 Metabase 升级
如果您使用的 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 并在其中运行迁移命令。
一旦迁移过程完成，使用您要运行的版本的 JAR 或容器镜像启动 Metabase。
升级在集群中运行的 Metabase
如果您在集群中运行 Metabase
- 将节点数量减少到单个节点。您不能同时升级所有节点，因为升级过程通过从单个客户端获取应用程序数据库上的迁移锁来执行迁移。如果您在执行主要版本升级时保持多个节点活动，应用程序将无法正常运行，因为应用程序数据库的架构更改可能会导致仍在运行旧版本 Metabase 的节点出现问题。
- 正常执行升级（如上所述）。
- 将节点数量增加到与之前相同的数量。
确保您的容器编排器或集群管理器在 Metabase 执行迁移时不会终止 Metabase 进程，否则您可能会导致应用程序数据库损坏，需要从备份恢复。
阅读其他版本的 Metabase 的文档。