操作

由于部署初期预估不足，使得 confluence 的应用数据写到了根分区当中，而根分区又只有 50G，现在附件越来越多，眼见磁盘将满，有句俗话说的好：我不来解决，谁又来解决！

事情可能不复杂，但是操作一旦出纰漏，也是非常重大的，因此写好操作流程，按章施工，以免出错。

1. 发出维护通知，在夜深无人时操作。

2. 先停止 NGINX，切断所有请求，以免有新的文章附件编辑提交。

3. 提前将数据同步到将要迁移的目录之下，命令如下： rsync -avz --delete /var/atlassian/ /confluence/atlassian/

4. 操作之前，记得再次执行如上命令，以保证数据一致。

5. 停止 confluence 服务，使用如下命令： /opt/atlassian/confluence/bin/shutdown.sh

6. 编辑 confluence 配置文件，更改如下内容：

   vim /opt/atlassian/confluence/confluence/WEB-INF/classes/confluence-init.properties
   # 改写如下配置文件的路径为迁移后的路径
   confluence.home = /var/atlassian/application-data/confluence
   

7. 启动 confluence，命令如下： /opt/atlassian/confluence/bin/startup.sh

8. 查看日志，启动是否有异常，如果没有问题，可以将 NGINX 启动。

注意启停命令不能用start/stop，否则会失败!

9. 访问服务，验证功能是否正常。

注意：如果相关权限不正确，可能会导致部分功能加载失败，比如我迁移完成之后，发现编辑页面的其他宏功能点击无法正常使用，此时对比了老目录的权限，分别调整了属主属组，好像还不行，最后通过将 plugin 开头的目录全部给了 777 的权限(此操作可在服务运行期间执行,不必重启服务)，然后才能正常使用。

cd /confluence/atlassian/application-data/confluence/
chmod 777 -R plugins-*

再到页面，发现其他宏恢复使用。

加载失败的报错如下：

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)

补充

后来再经过几次迁移实践之后发现，confluence启动之后，编辑文章时插入目录或者其他宏的确是无法使用的，而大约等个二十分钟左右之后，该功能正常，目前怀疑可能是服务启动之后会有一些之后的任务跑了之后，某些功能才能正常使用。

因此在操作迁移之类的工作时，要有一定的耐心来等待这个事情，同时也提供了一个经验：一些服务我们在运维维护的时候，通知出去的维护窗口应该尽可能大，比如你觉得只是简单的变更维护，十分钟足够了，然而当你重启之后，发现此功能无法正常使用，却只能回滚，没能达到变更的目的，但服务只不过是需要一些初始化的时间。