从 MySQL 到 MariaDB 的数据库迁移

本站已完成数据库的迁移工作：从原先的 MySQL 换成了 MariaDB。迁移过程整体比较顺利，只在 Gitea（代码托管服务）的迁移上遇到一些曲折，下面具体说明。

迁移步骤

1. Halo（博客系统）：迁移最简单。只需在旧环境中备份 Halo 所使用的数据库（mysqldump 或在博客后台中导出），然后在安装了 MariaDB 的新环境中恢复该备份即可。Halo 本身并不绑定数据库类型，迁移后直接运行正常。

2. Gitea（代码托管）：需要根据原先使用的数据库类型区分处理：

   • 原使用 SQLite3：Gitea 默认使用 SQLite3 时，数据存储在一个单一的数据库文件中（通常是 gitea.db）。迁移只需备份这个文件，复制到新环境对应的路径下，然后启动 Gitea 即可。由于是文件型数据库，操作非常简单。

   • 原使用 MySQL：如果原先 Gitea 配置的是 MySQL 数据库，理论上应该先备份 MySQL 中的 Gitea 数据库（使用 1Panel 面板的备份功能或命令行），然后卸载当前的 Gitea 和 MySQL，安装 MariaDB 后恢复数据。不过本站实际操作时，并没有采用这种方案，而是选择在 MariaDB 环境下全新安装 Gitea，然后手动重建仓库（因为仓库数量不多，且已有备份）。这样避免了复杂的数据类型兼容性问题。

迁移局限性

本次迁移遇到的最大限制，源于 1Panel 面板的容器化部署方式。1Panel 将所有应用（包括 MySQL、MariaDB、各个站点）部署在相互独立的 Docker 容器中。容器之间网络隔离，无法直接通过 localhost 或内部 IP 互相连接。这意味着无法让一个容器直接访问另一个容器的数据库实例来执行跨库迁移。只能通过“备份旧容器数据 → 新建新容器 → 恢复数据”的流程完成。对于 Gitea 这种对数据库连接配置敏感的软件，还可能出现连接串、权限等额外问题，所以最终选择了重新安装。

迁移结果

经过这次调整，本站已全部迁移至完全开源软件。原先可能依赖的闭源组件（如 MySQL 的某些企业特性）已被 MariaDB 替代，所有底层服务都运行在开源生态中。后续维护和升级将更加自由可控。