seatable4.3迁移失败

疑问解答
1

按照 备份与恢复 - seatable-manual教程来做，从一台远程VPS迁移到本地的Ubuntu主机上时，打开工作表出现了Library does not exist.错误。

2

看一下服务器日志有哪些具体错误

3

暂时没看到错误，只是提示有个什么文件已经loaded，我忘记了。目前，准备整个文件夹拷贝过来，重新试试部署命令来部署，但是文件夹已经很大了，有好几个G，得点时间拷贝。

4

请问一下这个服务器日志在哪里看？

5 
2024/04/10 15:04:57 [error] 40#40: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.128.1, server: seatable.10an.fu

n, request: "GET /api/v2.1/admin/sysinfo/ HTTP/1.1", upstream: "http://127.0.0.1:8000/api/v2.1/admin/sysinfo/", host: "seatable.10an.fun", referrer: "https://

seatable.10an.fun/sys/info/"

2024/04/10 15:15:23 [error] 38#38: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.128.1, server: seatable.10an.fu

n, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8000/", host: "seatable.10an.fun", referrer: "https://seatable.10an.fun/workspace/3/dtable/%E7%94%9F

%E4%BA%A7%E8%B0%83%E5%BA%A6%E6%8A%A5%E8%A1%A8/"

2024/04/10 15:17:51 [error] 39#39: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.128.1, server: seatable.10an.fu

n, request: "GET /workspace/3/dtable/%E7%94%9F%E4%BA%A7%E8%B0%83%E5%BA%A6%E6%8A%A5%E8%A1%A8/ HTTP/1.1", upstream: "http://127.0.0.1:8000/workspace/3/dtable/%E

7%94%9F%E4%BA%A7%E8%B0%83%E5%BA%A6%E6%8A%A5%E8%A1%A8/", host: "seatable.10an.fun", referrer: "https://seatable.10an.fun/"

2024/04/10 15:17:54 [error] 39#39: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.128.1, server: seatable.10an.fu

n, request: "GET /workspace/3/dtable/%E7%94%9F%E4%BA%A7%E8%B0%83%E5%BA%A6%E6%8A%A5%E8%A1%A8/ HTTP/1.1", upstream: "http://127.0.0.1:8000/workspace/3/dtable/%E

7%94%9F%E4%BA%A7%E8%B0%83%E5%BA%A6%E6%8A%A5%E8%A1%A8/", host: "seatable.10an.fun", referrer: "https://seatable.10an.fun/"

上面这个错误日志看的出来问题吗？

6

终于弄好了。但是损失了36个小时中间的数据，还是蛮烦的。
1.按照官方的说明在原来的的服务器（CentOS）从seatable3.5上升到4.3，不知道为什么CentOS不能使用新的部署方案，升到4.3的时候使用老的部署方案，然后把数据库也升到4.3。
2.在conf中的dtable_web_setting.py中加上CSRF_TRUSTED_ORIGINS = ['YOU SERVER URL']
3.回到/opt/seatable文件夹把整个mysql-data和seatable-data复制到新的Ubuntu服务器中的/opt/seatable中去。然后使用官方教程 使用 Docker 部署 SeaTable 开发者版 - seatable-manual部署，顺便把Python服务器也部署上去。
4.这种方式不用备份数据库命令了，但是因为老的docker-compose.yml里面的数据库依赖的db，新的是mariadb，需要修改，这里官方有说明，国外的文档是把db都改成mariadb，我偷懒按国内的文档把mariadb改成了db，包括python-pipeline.yml里面也要改。
5.这样没有意外会部署成功，我出现的意外就是上文中的Library does not exist，能进入系统，点击表格的时候就报错，后来发现是我的数据量太大，最后一次没有成功从旧的服务器上传到新的服务器上导致的文件丢失。虽然整个文件夹里面看起来都有文件夹了，但是用du -sh查看大小才发现差文件，原始文件有3.6G。
6.终于用单位的旧电脑（好歹是个4核的，比我先的便宜VPS要好多了）迁移部署成功，直接部署也没有这么麻烦，但是如果不是用过之后，让领导看到这个项目好用，领导也不会单独批给我一台旧电脑，顺带升级到了4.3，Python服务器也能部署到同一台机器上了，以后就方便了。而且我把SSL取消了，直接使用cloudflare的tunnel模式加上原来的域名就可以使用了。
7.提点建议，官方升级的版本众多，各人部署的参数都有细微的差别，备份和迁移真的是太复杂了，还要考虑到镜像里面的nginx配置可能出错。我一般使用都不敢停机和升级，能不能简化一下备份和恢复的步骤和最少文件。其实最好是能让数据库和程序分离，这样升级的使用尽量就直接链接原数据库就好了。

1 个赞