ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Metabase 自托管迁移至 Metabase Cloud 全流程实战(Metabase 49 及以下版本)

Metabase 自托管迁移至 Metabase Cloud 全流程实战(Metabase 49 及以下版本) Metabase 自托管迁移至 Metabase Cloud 全流程实战Metabase 49 及以下版本【免费下载链接】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导读本文以 Metabase 官方迁移指南 guide-pre-50.md 为核心面向运行 Metabase 49 及以下版本的自托管用户系统讲解如何把现有实例含全部问题、仪表盘、用户与设置平滑迁移到 Metabase Cloud。读完本文你将掌握迁移前的环境检查与备份要领、Store 迁移脚本的执行细节JAR / Docker / Heroku 三种部署形态、迁移后的 SSO 与嵌入配置收尾并理解迁移脚本背后的应用数据库快照机制在仓库源码中的实现依据。适用前提如果你运行的是 Metabase 50 及以上版本请直接参考新版迁移指南 guide.md新版流程已内嵌到 Metabase 管理界面无需在 Store 执行脚本若希望从 Metabase Cloud 迁回自托管可参考 cloud-to-self-hosted.md。迁移原理为什么一切数据都能“原样带走”Metabase 的运行时数据问题、仪表盘、集合、用户、权限、设置项等全部存放在单一的应用数据库Application Database中而不是散落在多个文件里。这一点在 backing-up-metabase-application-data.md 中有明确说明“Metabase 使用单个 SQL 数据库保存所有运行时应用数据”。因此迁移的本质就是把应用数据库的数据完整上传到 Metabase Cloud 的新实例这正是旧版迁移脚本所做的工作。从仓库源码可以印证这一机制cloud_migration/settings.clj 中定义了migration-dump-file迁移 dump 文件与migration-dump-version迁移 dump 对应的 Metabase 版本号两个内部设置其中migration-dump-version的注释明确指出“This will cause the restore to fail on cloud unless you also setmigration-dump-fileto a dump from that version”说明迁移上传的内容本质上是带版本标识的应用数据库快照Metabase Cloud 端会按版本还原该快照。同时该文件还定义了read-only-mode设置注释说明它是“Boolean indicating whether a Metabase instance is in read-only mode with regards to its app db”即迁移期间实例进入只读模式的开关——这解释了为什么旧版指南要求你在迁移前彻底关闭自托管实例。迁移前准备了解 Metabase Cloud 的局限迁移前应通读 limitations.md确认现有部署不依赖以下受限能力否则迁移后功能会受影响局限项说明仅支持官方数据库Metabase Cloud 只支持官方支持的数据库且排除 SQLite 与 H2不支持社区驱动见 community-drivers.md因为云端没有文件存储自定义证书支持有限仅部分数据库支持在连接设置界面录入/上传自定义证书邮件发件地址不可定制邮件报告、告警与系统通知的 “from address” 无法自定义无法访问应用数据库若需要了解用户使用情况改用使用分析查询超时单次查询超过 20 分钟会被强制超时确认访问权限与环境执行迁移需要两个前提Shell 访问权限能够登录到自托管 Metabase 所在服务器JAR 进程或 Docker 容器所在主机。外网访问自托管环境需要能够访问互联网以便下载迁移脚本并上传应用数据。预留停机窗口迁移期间实例不可用应提前通知用户并尽量安排在非工作时间。旧版迁移流程通常不超过 15 分钟。关闭自托管 Metabase 实例在生成快照之前必须彻底停止 MetabaseJAR 部署停止 JAR 进程CTRL-C、关闭终端或停止对应 systemd 等服务。Docker 部署停止对应容器。这样做的目的是防止用户在迁移期间继续创建问题或仪表盘导致实例与应用数据库快照处于不一致状态。备份应用数据库为防万一迁移前务必备份应用数据库详见 backing-up-metabase-application-data.md。该文档给出的几种备份方式可直接复用H2 默认库 Dockerdocker cp metabase:/metabase.db/metabase.db.mv.db ./H2 默认库 JAR停止进程后直接复制metabase.db.mv.db文件妥善保管自托管 PostgreSQL使用pg_dump等 PostgreSQL 官方备份方式Amazon RDS建议开启 RDS 自动备份正式迁移从 Metabase Store 发起第一步创建 Metabase Cloud 实例如果还没有 Metabase Cloud 实例先在 Metabase Store 注册一个14 天免费试用实例作为迁移目标已有实例可直接跳过本步。第二步在 Store 中发起迁移并获取脚本登录 Metabase Store 账户点击Initiate Migration。系统会根据你的部署形态生成一条迁移命令用于下载并执行迁移脚本Metabase JAR一条命令Docker另一条命令通常直接复用当前容器的环境变量。第三步按部署形态设置应用数据库环境变量执行迁移脚本前需要让脚本能够访问你的应用数据库。不同部署形态的做法不同部署形态操作Docker环境变量通常已在容器中配置好可直接执行脚本JAR在运行 JAR 的服务器上执行MB_DB_CONNECTION_URIxxxxx migration_script.shHeroku需要额外步骤见下节及 heroku.mdMB_DB_CONNECTION_URI是 JDBC 风格的连接 URI在 environment-variables.md 中有完整说明它可替代MB_DB_HOST等大部分MB_DB_*变量尤其适用于需要携带特定连接字符串参数的场景连接类型要求与MB_DB_TYPE一致。你也可以使用MB_DB_TYPE、MB_DB_HOST、MB_DB_PORT、MB_DB_DBNAME、MB_DB_USER、MB_DB_PASS等变量组合来指定应用数据库连接例如参考 migrating-from-h2.md 中的完整示例export MB_DB_TYPEpostgres export MB_DB_CONNECTION_URIjdbc:postgresql://host:5432/metabase?userusernamepasswordpassword migration_script.sh第四步在自托管环境中执行迁移脚本重要警告如果你已经在 Metabase Cloud 试用实例中创建了任何问题或仪表盘上传自托管应用数据后这些内容会被覆盖。因此建议迁移前保持云端实例为空。脚本会将自托管实例的应用数据上传到新的 Metabase Cloud 实例。一切顺利时脚本会输出Done!。若中途出错按脚本提示逐步处理仍无法解决时可向 Metabase 官方支持求助排查。Heroku 部署的特殊步骤Heroku 属于托管平台无法直接登录服务器需要借助 heroku.md 的补充流程安装 Heroku CLI通过heroku ps:exec --app your-metabase-app-name-in-heroku替换为你的应用名使用 SSH 隧道Heroku Exec进入运行 Metabase 的 dyno首次执行可能需要重启 dyno输入y确认。设置MB_DB_CONNECTION_URI在 Heroku 应用的Settings → Config Vars中复制DATABASE_URL然后在 Shell 中执行export MB_DB_CONNECTION_URIYOUR_DATABASE_URL_GOES_HERE执行迁移脚本在同一个 Shell 会话中运行curl -s long-metabase-migration-script-url | bash迁移后的收尾工作上传成功后Metabase Cloud 会在几分钟内自动完成收尾与重启届时即可登录新实例所有问题与仪表盘应与原自托管实例完全一致。接下来还需处理以下事项更新 SSO 相关配置Google Sign-in 用户登录 Google Developers Console将新的 Metabase Cloud URL 添加到 Google Auth Client ID 的Authorized JavaScript Origins中。使用 SAML SSO 的 Pro/Enterprise 客户需要到身份提供商IdP处更新Redirect URL与Base URL为新的 Metabase Cloud URL否则 IdP 仍会把用户重定向到已关闭的旧实例。具体配置参考 authenticating-with-saml.md。告知团队新的访问地址确认一切正常后将新的 Metabase Cloud URL 告知团队成员用户可像往常一样登录并继续工作。如果 Metabase 被嵌入到应用中务必同步更新代码中的 URL。清理旧的托管服务如果你是通过第三方服务自托管的记得取消相关订阅与存储资源例如旧备份占用的存储避免产生不必要的费用。迁移期间与之后的只读与版本行为从仓库源码看新版迁移流程Metabase 50会在实例内部先进入read-only-mode只读模式定义于 cloud_migration/settings.clj迁移期间用户仍可查看问题与仪表盘但不能新建内容而本指南针对的旧版本v49 及以下则通过“直接关闭实例”达到同等目的。此外在版本处理上详见新版指南 guide.md若 Metabase Cloud 当前版本高于你的自托管版本迁移后会自动升级若云端默认版本等于或低于你的版本则保持原有版本。常见问题迁移脚本在哪获取登录 Metabase Store 账户点击Initiate Migration后按部署形态JAR / Docker / Heroku获取对应命令。迁移需要多长时间通常不超过 15 分钟建议安排在非工作时间。迁移失败怎么办按脚本输出的提示逐步排查确认MB_DB_CONNECTION_URI等连接变量无误且自托管环境能正常访问外网。仍无法解决时联系 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/metabase创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表