本文总结了集群节点不同步问题的排查思路，以便于大家更好的进行问题排查。

2.1 节点间同步的目的

节点间同步是保证多个节点之间的文件一致，基本逻辑是监控基准节点，如果有文件变动，就会把文件从基准节点同步到非基准节点。

2.2 文件同步方式

1）两节点的集群

2）三节点集群

3）Windows 集群

2.3 节点间同步涉及的文件夹

默认同步监控的文件有 WEB-INF/analyzer、WEB-INF/assets、WEB-INF/dashboards、WEB-INF/reportlets、WEB-INF/resources、WEB-INF/schedule、WEB-INF/treasures、WEB-INF/../backup

同步监控的文件可以自定义，在 finedb 的 fine_conf_entity 中找id是 ResourcePathConfig.paths.*** 开头的字段，*** 代表 WEB-INF 下面的文件名名字，对应字段的值分为 true 和 false，true 则为监控文件。

 注意： 默认plugins是没有同步的，如果是集群节点间同步，装插件的情况下，建议在插件管理里安装，如果更新文件，需要两个节点都放插件，然后是重启服务才能生效。

2.4 基准节点

开启集群按钮，并重启工程后，可以看到节点管理界面出现一个节点，并且当我们选用的是「节点间自动同步」时，第一个加入集群的节点会作为基准节点，数据库存在 fine_conf_entity 里 id 的名字是 ResourceSyncConfig.calibrationNode ，之后启动顺序不会影响基准节点，如果基准节点宕机，新加的模板到非基准节点，等基准节点上位后，新的模板不会同步到 基准节点，会把模板备份在  WEB-INF/../sync_bak/ 目录下， 这个时候有丢失模板的风险，需要手动在拷贝一下 

2.5 日志节点判断

1）文件同步日志查看：基准节点监控文件变动的日志关键词 ResourceWatcher；非基准节点同步文件的日志关键词 ResourceSyncReceiver 。

2）文件同步启动时日志查看：首先是基准节点启动,关键日志为 [Resource] Current node is Calibration Node;  非基准节点启动关键日志为 bootstrap Sync request send to 。

3）基准节点收到引导同步请求，对比本地文件和非基准节点文件结构 compares to  ; 非基准节点收到基准节点发来的文件， 对比自己本地文件保持跟基准同步，多余的备份起来 bootstrap sync files will send from 。

4）info 级别也会有日志输出，不过如果排查问题建议用 debug 模式，日志会更详细。

2.6 同步规则

1）使用节点间同步，要手动修改文件必须在基准节点上进行，才会同步到非基准节点，手动在非基准节点上的操作无效

2）节点启动的时候，必须基准节点第一个启动，启动完成后再依次启动其他节点，所有启动的节点都会在启动时与基准节点的文件保持一致，不一致的文件会被备份到 WEB-INF/../sync_backup/ 路径下

3）如果非基准节点先启动了，那基准节点启动的时候不会去同步手动修改的文件保持与基准节点一致，但工程自己生成的文件还是会同步一致，比如定时调度生成的结果文件，在基准节点没有启动的时候生成了一些结果文件，基准节点启动的时候会保持与基准节点一致，结果文件都被删掉备份起来

3.1 节点同步不生效（没有触发）

1）排查步骤一：检查用户权限，有可能启动用户没有权限

解决方案1：

将工程启动用户全部换成 root 启动，root 默认拥有所有权限。

解决方案2：

给工程启动用户，工程模板文件夹下所有文件的读写执行权限。

2）排查步骤二：集群间没有触发同步

解决方案：

权限充足的情况下，重启节点工程测试，重启服务器时 redis 也需要重启。

3）排查步骤三：个别节点读取不到模板文件

解决方案：

主被动模板，被动模板需要的端口比主动少，检查端口是否少开了。

4）排查步骤四：集群外接数据库不一致导致节点同步失败

解决方案：

外接库配置成同一个。

5）排查步骤五：检查基准节点，是否存在丢失

解决方案：

重新配置基准节点。

6）排查步骤六：检查节点服务器时间，是否为时间不一致导致的

解决方案：

检查各个节点的时间是否一致，当节点间系统时间误差超过30s时会进行报错提醒，因为包括登录等基础功能的使用可能会受到时间不一致的影响。windows系统可以手动将各个节点的系统时间调为一致，Linux系统调整节点间时间可以参考文档：Linux 系统如何配置各个节点的时间一致性。

7）排查步骤七：句柄数达到上限

解决方案：

报错“ERROR [standard] User limit of inotify watches reached”是集群的文件监视句柄达到上限，执行命令：echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p，增大上限值，再重启。

8）排查步骤八：监听文件数超上限

解决方案：

日志存在 http-nio-8080-exec-22 ERROR [standard] Not found data columnDQBLE 报错，说明是监听文件数超上限了，linux 环境执行命令：echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p 增大上限值，默认是 8192。

3.2 节点存在不一致文件

若开启了节点间同步，修改只能在基准接点下面修改。

3.3 同步异常丢失文件

1）排查步骤一：检查是否没有关闭 nginx 保护

解决方案：

关闭 nginx 保护后重新同步。

2）排查步骤二：检查 JAR包 版本，有可能为老版本bug

解决方案：

升级到 2021.04.30 以及之后的版本即可解决。

3）排查步骤三：检查 redis 是否存在脏数据

解决方案：

清理 redis 缓存和脏数据。

3.4 多节点（三节点及以上）同步失败

不可以使用除双节点外的节点间同步方式，目前结合多节点在普遍环境下的暴露出的问题：同步效率和出错概率会成几何倍增长。可以使用替代方案：推荐 HDFS 或 NAS 或 云存储。

集群为了便于及时发现并排查问题，针对异常情况也会进行异常通知，通知包括邮件通知、短信通知、消息通知，平台开通集群异常提醒即可收到。