Metabase 生产部署时怎么选择并配置应用数据库?

发布时间:2026/9/10 14:25:14
Metabase 生产部署时怎么选择并配置应用数据库? Metabase 生产部署时怎么选择并配置应用数据库【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabaseMetabase 自托管上线时有一个绕不开的决定应用数据库application database选什么、怎么配。应用数据库保存的是 Metabase 自身运行所需的数据——用户账号、问题、仪表盘、集合等——它和你存业务数据的数据仓库是两回事。官方文档明确建议生产环境使用 PostgreSQLH2 只适合本地演示、应避免用于生产。本文按文档给出选择依据、建库命令、连接配置环境变量与 JDBC 连接串两种方式、启动与验证方法覆盖 JAR 与 Docker 两种启动方式。先弄清应用数据库和数据仓库的区别Metabase 的文档对两者的分工描述是应用数据库存储用户账号、问题、仪表盘以及运行 Metabase 应用所需的其他数据。数据仓库你实际做分析的业务数据库通过「连接受支持的数据库」单独配置见 Connecting to a supported database。一个关键限制Metabase 只在启动时读取应用数据库的连接配置应用运行期间不能切换应用数据库见 configuring-application-database.md。所以连接方式必须在启动前通过环境变量或 JDBC 连接串定好之后修改配置需要重启才生效。三种可选数据库怎么选configuring-application-database.md 给出的选择列表选项生产适用性版本与要求PostgreSQL官方推荐用于生产支持「受支持的最老版本到最新稳定版」MySQL / MariaDB可用于生产最低 MySQL 8.4.0 / MariaDB 10.6.0必须使用utf8mb4字符集H2默认值仅限本地演示生产环境避免使用文件型数据库随 JAR 目录自动生成补充几条文档中明确的边界migrating-from-h2.md 中「受支持的应用数据库」一节标注 PostgreSQL 最低版本为14并要求 MySQL/MariaDB 具备默认设置utf8mb4_unicode_cicollation、utf8mb4字符集和innodb_large_prefixON。两份文档对 PostgreSQL 版本下限的表述不完全一致前者指向 PostgreSQL 官方支持周期后者写最低 14选型时以你实际部署环境对照 PostgreSQL 官方支持周期为准。文档明确不支持 ApsaraDB MySQL如使用阿里云应选 ApsaraDB PostgreSQL。如果不提供任何指定生产数据库的连接环境变量Metabase 启动时会在 JAR 所在目录自动创建一个新的 H2 文件库——这是本地演示的行为不是生产配置。H2 文件形如metabase.db.mv.db早期版本为metabase.db.h2.db可用ls metabase.*查看。最短主路径PostgreSQL 环境变量方式下面按此展开MySQL/MariaDB 作为可选分支放在后面。第一步创建目标数据库Metabase 不会替你建库文档强调Metabase 不会自动创建 Postgres/MySQL 数据库需要你先建好一个空库。不需要建任何表——表结构由 Metabase 启动时自行创建。PostgreSQL 示例命令来自文档createdb --encodingUTF8 -e metabaserunning-the-metabase-jar-file.md 的生产章节中数据库名写作metabaseappdb文档说明应用数据库名可以随意起。可选分支——MySQL/MariaDBCREATE DATABASE metabase CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;第二步配置连接信息文档给出两种等价的配置方式都通过环境变量在启动前设置。方式一分项环境变量PostgreSQL 主路径export MB_DB_TYPEpostgres export MB_DB_DBNAMEmetabase export MB_DB_PORT5432 export MB_DB_USERusername export MB_DB_PASSpassword export MB_DB_HOSTlocalhost java --add-opens java.base/java.nioALL-UNNAMED -jar metabase.jar其中username、password、localhost是文档示例中的占位值替换为你的实际数据库用户、密码与主机。各变量含义来自 environment-variables.mdMB_DB_TYPE取值h2、postgres、mysql默认h2MB_DB_HOST/MB_DB_PORT/MB_DB_USER/MB_DB_PASS/MB_DB_DBNAME分别指定主机、端口、用户名、密码与库名。MySQL 版本只需改两处export MB_DB_TYPEmysql export MB_DB_PORT3306 # 其余变量与上面相同方式二JDBC 连接串有额外参数时使用当连接需要额外参数时可直接提供完整 JDBC 连接串export MB_DB_CONNECTION_URIjdbc:postgresql://localhost:5432/metabase?userusernamepasswordpassword java --add-opens java.base/java.nioALL-UNNAMED -jar metabase.jarMySQL 示例为jdbc:mysql://localhost:3306/metabase?userusernamepasswordpassword。如果密码里包含特殊字符文档建议把凭据与连接串分开传用MB_DB_CONNECTION_URI组合MB_DB_USER和MB_DB_PASSexport MB_DB_CONNECTION_URIjdbc:postgresql://localhost:5432/metabase export MB_DB_USERusername export MB_DB_PASSpassword java --add-opens java.base/java.nioALL-UNNAMED -jar metabase.jar另外两条与连接配置直接相关的限制来自 environment-variables.mdMB_DB_CONNECTION_URI中currentSchema参数不生效PostgreSQL 应用数据库使用的 schema 必须是public。H2 场景下MB_DB_FILE不应包含.mv.db/.h2.db扩展名——虽然生产环境不该用 H2但如果你在迁移旧实例会用到见文末「已有 H2 数据怎么办」。可选用 SSL 或云身份认证替代密码文档在「Upgrading from a Metabase version pre-0.38」一节给出了应用数据库启用 SSL 证书校验的写法即通过MB_DB_CONNECTION_URI追加参数export MB_DB_CONNECTION_URIpostgres://localhost:5432/metabase?userusernamepasswordpasswordsslmodeverify-casslrootcertpath to CA root or intermediate root certificate其中path to CA root or intermediate root certificate替换为你的 CA 根证书或中间证书路径。文档同时列出ssltruesslfactoryorg.postgresql.ssl.NonValidatingFactory这一不校验证书的方案但明确标注它不安全仅用于排障或安全不是优先事项的场景。如果你托管在云上还有两个免密认证选项均要求省略MB_DB_PASSMB_DB_AWS_IAMtruev0.58.0 起PostgreSQL 或 MySQL/MariaDB 位于 AWS RDS/Aurora 时改用 AWS IAM 认证token 自动刷新要求 AWS 凭据可通过标准凭据链获得且具备rds-db:connect权限。MySQL/MariaDB 还需配合MB_DB_SSL_CERT或在连接串中传 SSL 参数。MB_DB_AZURE_MANAGED_IDENTITY_CLIENT_IDv0.51.0 起Azure Managed Identity 认证要求 Pro/Enterprise 的 Database authentication providers 特性。第三步启动 MetabaseJAR 方式就是上面的启动命令终端会打印启动日志等待出现Metabase Initialization Complete后访问http://localhost:3000端口可用MB_JETTY_PORT环境变量修改。Docker 方式通过-e传入同一组变量来自 running-metabase-on-docker.md 的生产章节docker run -d -p 3000:3000 \ -e MB_DB_TYPEpostgres \ -e MB_DB_DBNAMEmetabaseappdb \ -e MB_DB_PORT5432 \ -e MB_DB_USERname \ -e MB_DB_PASSpassword \ -e MB_DB_HOSTmy-database-host \ --name metabase metabase/metabase注意文档特别提醒Metabase 是从容器内部连出数据库的MB_DB_HOST要么用全限定主机名要么在容器/etc/hosts中配好对应条目——直接写宿主机上的localhost在容器网络里通常指不到你的数据库。如果以 systemd 服务方式运行 JAR这些环境变量需要放进服务的配置文件里见 running-metabase-as-service.md。如何验证配置生效两个文档中给出的判断方式启动日志终端出现Metabase Initialization Complete表示启动完成这是 running-the-metabase-jar-file.md 中给出的成功标志。API 查询应用数据库类型以管理员身份调用GET /api/bug-reporting/details返回中会包含application-database字段。文档示例注意这是文档中的示例输出{ application-database: h2 }按 migrating-from-h2.md 的说法若application-database不是postgres或mysql说明还在用内嵌 H2即生产配置没有生效。配置正确时该字段应显示为你选择的数据库类型。手动控制 schema 迁移可选Metabase 启动时通常会检测应用数据库是否需要变更并自动执行。如果需要在启动前人工审查/执行这些变更设置export MB_DB_AUTOMIGRATEfalse启动后应用会停住并打印所需执行的 SQL文档示例日志中出现metabase.db :: Database Upgrade Required及一段待执行脚本手动把 SQL 应用到数据库后再重启即可。注意这个变量只控制应用数据库 schema 迁移与从 H2 迁移数据无关。已有 H2 数据怎么办如果你之前用默认 H2 跑过 Metabase、已经积累了问题和仪表盘不能直接改环境变量了事需要走一次性迁移确认版本一致迁移用的 Metabase 版本必须与创建/更新 H2 文件的版本相同、备份 H2 文件、用load-from-h2命令把数据加载到全新空的目标库再按新配置启动。完整步骤见 migrating-from-h2.mdH2 文件备份方法见 backing-up-metabase-application-data.mdDocker 场景用docker cp把metabase.db.mv.db拷出容器。迁移中遇到文件路径/扩展名类报错可参考 loading-from-h2.md。文档建议既然已经决定上生产尽早迁移并继续保留旧 H2 文件作为备份。部署完成后应用数据库里存的是 Metabase 全部应用数据备份它就是备份一个 SQL 库即可自托管 PostgreSQL 按 PostgreSQL 官方备份方式做 dump 即可见 backing-up-metabase-application-data.md。下一步通常是完成初始化设置并连接你的数据仓库见 setting-up-metabase.md遇到安装问题可查 troubleshooting-guide/running.md。后续升级 Metabase 时schema 变更仍由 Metabase 启动时自动处理升级流程见 upgrading-metabase.md。【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考