confluence数据目录满了
# 操作
由于部署初期预估不足,使得 confluence 的应用数据写到了根分区当中,而根分区又只有 50G,现在附件越来越多,眼见磁盘将满,有句俗话说的好:我不来解决,谁又来解决!
事情可能不复杂,但是操作一旦出纰漏,也是非常重大的,因此写好操作流程,按章施工,以免出错。
发出维护通知,在夜深无人时操作。
先停止 NGINX,切断所有请求,以免有新的文章附件编辑提交。
提前将数据同步到将要迁移的目录之下,命令如下:
rsync -avz --delete /var/atlassian/ /confluence/atlassian/
操作之前,记得再次执行如上命令,以保证数据一致。
停止 confluence 服务,使用如下命令:
/opt/atlassian/confluence/bin/shutdown.sh
编辑 confluence 配置文件,更改如下内容:
vim /opt/atlassian/confluence/confluence/WEB-INF/classes/confluence-init.properties # 改写如下配置文件的路径为迁移后的路径 confluence.home = /var/atlassian/application-data/confluence
1
2
3启动 confluence,命令如下:
/opt/atlassian/confluence/bin/startup.sh
查看日志,启动是否有异常,如果没有问题,可以将 NGINX 启动。
注意启停命令不能用start/stop,否则会失败!
- 访问服务,验证功能是否正常。
注意
:如果相关权限不正确,可能会导致部分功能加载失败,比如我迁移完成之后,发现编辑页面的其他宏
功能点击无法正常使用,此时对比了老目录的权限,分别调整了属主属组,好像还不行,最后通过将 plugin 开头的目录全部给了 777 的权限(此操作可在服务运行期间执行,不必重启服务),然后才能正常使用。
cd /confluence/atlassian/application-data/confluence/
chmod 777 -R plugins-*
2
再到页面,发现其他宏
恢复使用。
加载失败的报错如下:
http://ex.confluence.com/plugins/macrobrowser/browse-macros.action?detailed=false¯oMetadataClientCacheKey=1589232968441] and may be stuck (configured threshold for this StuckThreadDetectionValve is [60] seconds). There is/are [15] thread(s) in total that are monitored by this Valve and may be stuck.
java.lang.Throwable
at java.net.PlainSocketImpl.socketConnect(Native Method)
2
3
# 补充
后来再经过几次迁移实践之后发现,confluence 启动之后,编辑文章时插入目录或者其他宏的确是无法使用的,而大约等个二十分钟左右之后,该功能正常,目前怀疑可能是服务启动之后会有一些之后的任务跑了之后,某些功能才能正常使用。
因此在操作迁移之类的工作时,要有一定的耐心来等待这个事情,同时也提供了一个经验:一些服务我们在运维维护的时候,通知出去的维护窗口应该尽可能大,比如你觉得只是简单的变更维护,十分钟足够了,然而当你重启之后,发现此功能无法正常使用,却只能回滚,没能达到变更的目的,但服务只不过是需要一些初始化的时间。