升级需谨慎！！！升级不规范，代码两行泪。。。

# 前言

自己自建了一个 Gitea 服务来托管自己平时的代码和 hexo 的源文件，然后前些日子登录控制台发现自己版本已经落后了整整一个大版本多（1.18.0 -> 1.19.3）

然后就闲的没事升了级，结果就悲催了。。。

# 小提示

Gitea 更新自带升级转换，会对数据库进行转换以适应新版本

但是仍需要注意是否有部分版本存在破坏性更新

并且最好不要一次性跨越太大版本，容易嘎

# 情景回顾

我是通过二进制文件的形式部署的，所以升级只需要替换二进制文件即可

我先是备份了 Gitea 的所有本地文件（二进制的方式好处就是打包方便），然后下载了官方 1.19.3 版本的 Gitea 二进制文件进行替换

替换完成后重启 Gitea 服务发现网页直接 502（使用 Nginx 反代），说明服务没启动起来

输入 systemctl status gitea 发现 gitea 果然没启动

手动切换到 git 用户后执行二进制文件发现一堆报错，而其中致命问题来自于数据库

我下意识就想到会不会是版本跨越太大数据库出现不兼容问题，然后我就发现一个致命问题

我数据库没备份。。。。。。😭😭😭

回退二进制文件启动，果然旧版本的 gitea 已阻止读取更新后的数据库。。。

当时感觉整个人都不好了。。。😨😨😨

不过幸好我宝塔设置了数据库自动备份，而且最近的一次备份刚好是在我最后一次 git push 后面的一天

吓得我一身虚汗，马上还原数据库

所以，一定要做好充分的备份准备再进行升级等相关操作 。。。

# 解决升级中的问题

# The maximum column size is 767 bytes

在网上找了一下相关资料，发现是数据库设置问题

“Mysql Index column size too large. The maximum column size is 767 bytes.”

因为 MySQL Innodb 索引字段长度最大为 767 字节

解决方法有两种，一种是更改业务逻辑（根本不现实好吧）

一种就是取消限制，我们这里采用第二种

我们登录数据库，对数据库执行 SQL 语句

1
2
show variables like 'innodb_file_format';
show variables like ‘innodb_large_prefix’;

我们可以看到数据库的 file_format 和 large_prefix 状态

执行下方语句进行更改

1
2
set global innodb_file_format = Barracuda;
set global innodb_large_prefix = on;

执行完成后即可解决这个致命报错，gitea 服务也可以启动了

# Warnings about struct defaults during database startup

这个问题是 gitea 在升级后有很多旧的字段不再使用了，但是数据库里还是存在

官方也已经给出了解决方法，只需要重建表就行

同样在进行数据库操作前要进行备份！！！

1
gitea doctor recreate-table

如果你像我一样用的二进制启动，app.ini 不是采用的默认位置还需要添加 - c 参数来指定 app.ini 的位置

1
gitea -c app.ini的位置 doctor recreate-table

重建表完成后基本上就没啥报错了

# tips

其实 Gitea 自带备份程序

下面是官方给出的 Gitea 备份教程

https://docs.gitea.cn/administration/backup-and-restore

# 后记

进行升级操作前一定要对其完整备份 ，不然嘎了那就不好玩了

# 参考

https://www.bboy.app/2023/04/28 / 解决 gitea 启动数据库告警 /

https://blog.csdn.net/zz0828zz/article/details/121152707

https://docs.gitea.cn/administration/backup-and-restore