目前基本情况是共有>2 台的机器跑分布式服务，每日往磁盘上固化数据，需要在机器之间同步文件夹。对于文件夹下的同名文件，将更新时间最新的版本同步到其它机器上。
请教各位有什么现成的方案能实现这个功能吗？
非常感谢。
This topic created in 2842 days ago, the information mentioned may be changed or developed.
Supplement 1 · Jan 31, 2019
1. 每天自动同步一次，但如果是用户手动触发操作，可能任意次数，但一般不会超过 10 次
2. 自动同步数据量大约 500MB，平均单个文件大小 100MB 左右，如果是用户手动触发，总量可能增加到 10GB，极端情况下甚至可能达到 150GB，机器之间均为不低于千兆的专网互联
3. 一般情况下，同步需要在 5 分钟内完成，暂不考虑极端情况
4. 目前在有宕机的情况下，所有文件将生成在在线机器上，因此需要在机器恢复后能够恢复同步（可以在下次数据固化时恢复）
2. 自动同步数据量大约 500MB，平均单个文件大小 100MB 左右，如果是用户手动触发，总量可能增加到 10GB，极端情况下甚至可能达到 150GB，机器之间均为不低于千兆的专网互联
3. 一般情况下，同步需要在 5 分钟内完成，暂不考虑极端情况
4. 目前在有宕机的情况下，所有文件将生成在在线机器上，因此需要在机器恢复后能够恢复同步（可以在下次数据固化时恢复）
 |
1
rsync 啊
|
1 |
3
nas
|
 |
4
EFS
|
 |
5
|
|
6
感谢，没有额外的机器了，同时同步的文件后续需要使用，因此应该不能通过这两种方式。
|
 |
7
听上去就是个很普通的 Syncthing 的应用场景。
|
|
8
不过说实话，GlusterFS 这个分布式文件系统也可以看一下，说不定适合你们的使用场景。
|
 |
10
1、每日同步几次
2、每次同步数据的大小 3、对同步延迟的要求 4、是否容忍一台或多台宕机 把这四点好好介绍一下，别人能更好的给你方案 |
|
11
Syncthing 是按照修改时间决定谁最新的。第一次同步会把冲突都标记出来手动解决，以后就总是按照时间同步了。
|
|
14
暂不考虑用户手动更新，推测一下，楼主的同步数据应该可以理解为更新数据，数据应该是逐条更新的，此种情况数据量并不大，可以考虑两种方案：
1、采用 raft 协议，毕竟数据同步完之后还需要使用，此方案使用数据也一并解决了 2、可以采用类似 mysql binlog 的方式 上述两种方案核心都是主从同步，一主多从。 考虑用户手动触发，就需要考虑所说的数据是否存在冗余。如果大量的数据都是更新操作，那么上述方案完全没有问题。 |
|
15
@xkeyideal 好的我看下这两种方案，如果主从方式的话，可能无法满足从机文件更新了，需要反向同步到主机上的问题，我去了解下这种反向同步能否满足
|
|
16
@codingadog 建议先看看一些分布式的资料，据我的了解不存在你说的问题，主写成功，会自动同步给从
|
 |
17
我咋感觉最简单的就是某机器做主,开 nfs,然后挂载到从机上.
然后可以做个 rsync,夜间同步到某从机上.为了冗余,不考虑可不做. |
|
20
@codingadog 这个就需要你和你的团队从架构和需求上酌情处理了，别人也不了解你的业务场景，只能给出一些建议，上面也有很多人提供了同步的方案，都可以考虑，适合业务的才是最好的。
不可能别人给个方案，你目前的架构完全不需要变更就能直接使用的 |
|
21
@codingadog nfs 就是共用一个存储啊,把指定的存储挂载到剩下的 n-1 台机器上,一台更新,即所有都使用最新的.
对性能方面会受到网络的影响,然后没有冗余. 胜在简单.高级点,可以考虑 gfs |
 |
22
NFS 应该是可以的
|
 |
23
lsyncd
|
|
24
初步了解了一下各位的方案，正在尝试解决中😅非常感谢各位！
|
 |
25
...为啥不直接用 oss ？
|
|
26
@lynskylate 内网环境，无法连接到外网🙏
|
Select Language