根 DNS 服务器可能是最典型的主（非只读）DNS 服务器。目前有 13 个用于根 DNS 服务器的 IP 地址；但是，考虑到 IP 任播技术，全球部署了超过 13 个根 DNS 服务器。
如果有人想更新所有根 DNS 服务器的 DNS 记录，那么所有这些 DNS 服务器之间是否存在某种同步或复制机制？
更复杂的是，如果两个人要同时更新同一个DNS记录，DNS是如何解决潜在冲突的呢？
例如，人A将 DNS 记录更新r1为r2on a.root-servers.net.(deployed at region A)，同时，人B将同一 DNS 记录更新r1为r3on a.root-servers.net.(deployed at region B)；region A此外，假设和之间存在显着的网络延迟region B。
第二个问题类似于数据库集群，存在多个主数据库服务器，这些主服务器同步所有其他主服务器的数据。
我有一个 SQL Server 2019 的 AlwaysOn 集群，其中包含一个处于同步模式的 3 个副本的可用性组。根据微软文档：
- 辅助副本强化日志并向主副本返回确认。
- 在收到来自辅助副本的确认后，主副本完成提交处理并向客户端发送确认消息。
本文更详细地解释了这一点：
- 在辅助副本中，日志接收从主副本获取日志记录并写入日志缓存。在参与同步提交模式的每个辅助副本上重复此过程。
- 在每个从副本上，都存在重做线程，它将日志记录中提到的所有更改写入数据页和索引页。它刷新日志以强化辅助数据库日志。
- 如前所述，在同步数据提交中，主副本等待来自辅助副本的确认。在此阶段，辅助副本发送确认事务强化已在辅助副本上完成。
- 一旦主副本收到来自辅助副本的确认，它就会向客户端发送事务完成消息。
因此，如果我理解正确： 如果我通过主副本成功更新记录，则此更新后的值应该立即可供查询辅助副本的客户端使用。
但是，当我对此进行测试时，这不起作用。我运行一个简单的批处理文件，如下所示：
sqlcmd -E -S tcp:SQL-AG-Listener -d TestDB -Q "BEGIN TRANSACTION; UPDATE TestSyncTable SET CurrentTime='%currentTime%'; COMMIT TRANSACTION;"
sqlcmd -E -S tcp:SQL-Server01 -d TestDB -Q "SELECT * FROM TestSyncTable" -K ReadOnly
sqlcmd -E -S tcp:SQL-Server02 -d TestDB -Q "SELECT * FROM TestSyncTable" -K ReadOnly
sqlcmd -E -S tcp:SQL-Server03 -d TestDB -Q "SELECT * FROM TestSyncTable" -K ReadOnly
所以我CurrentTime通过主副本（托管 AG 侦听器）更新该字段，然后立即通过所有三个副本读取它。每个sqlcmd命令都是一个单独的客户端进程，因此它打开了自己独立的 TCP 连接。
然后我看到这样的东西：
SQL-Server01: CurrentTime = 20:02:19.93
SQL-Server02: CurrentTime = 20:02:16.94
SQL-Server03: CurrentTime = 20:02:19.93
（重新格式化输出以获得更好的可读性）
据我所见，主副本始终返回更新后的值。辅助节点也这样做 - 但只是一些短暂的延迟。
所以问题是：为什么？同步模式不应该保证读操作的结果与写操作的结果一致吗？如果辅助副本仅在其重做线程更新数据页面后才发送确认 - 那怎么可能呢？
谢谢，穆修斯。
我在我的硬盘上运行 Snapraid。但是，我想测试它的数据完整性功能，看看它们如何/是否真正起作用。
但我真的不明白如何“破坏”我的数据。我可以手动更改文件的内容。但是，Snapraid 只会正常同步此更改。并且 Snapraid 修复会自动将文件恢复到更改之前。
但是我如何测试实际的数据损坏，以及我如何知道 Snapraid 是否真的修复了它？
最近，由于一致性问题，我看到远程数据中心中机器的根文件系统以只读方式重新挂载。
重新启动时，显示此错误：
UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)
按照建议运行 fsck 并使用 手动接受更正后Y，错误已得到更正，系统现在正常。
现在，我认为如果将 fsck 配置为自动运行和修复所有内容会很有趣，因为在某些情况下（例如这种情况）唯一的选择是亲自前往远程数据中心并将控制台连接到受影响的机器。
我的问题是：为什么 fsck 默认要求手动干预？此类程序执行的更正如何以及何时不安全？在哪些情况下系统管理员可能希望将建议的更正搁置一段时间（以执行一些其他操作）或一起中止它？
我有一个无盘主机“A”，它的目录 NFS 安装在服务器“B”上。A 上的进程写入该目录中的两个文件 F1 和 F2，B 上的进程监视这些文件的更改。假设 B 轮询更改的速度比 A 预期的要快。进程 A 寻找文件的头部，写入数据并刷新。进程 B 寻找文件的头部并进行读取。
关于如何在 B 处检测 A 执行的更改的顺序，是否有任何保证？
具体来说，如果 A 交替写入一个文件，然后写入另一个文件，是否可以预期 B 会注意到 F1 和 F2 的交替变化？或者 B 可以想象地检测到 F1 上的一系列变化，然后是 F2 上的一系列变化？
我知道这个问题中有很多假设。例如，我几乎可以肯定，即使只对一个文件进行操作，如果 A 对文件执行 100 次操作，由于 NFS 之前缓存了 A 上的一些操作，B 可能会看到较少数量的更改而产生相同的结果它们被传达给 B。当然，即使不涉及 NFS 并且读取和写入过程都在同一个真实文件系统上运行，并发文件访问也会出现问题。
我什至在这里提出问题的原因是，似乎大多数时候，上述设置确实以与在 A 处所做的相同顺序检测到 B 处的更改，但偶尔会出现一些事件以转置的方式发生命令。那么，是否值得尝试完成这项工作？有没有办法调整 NFS 以使其工作，也许是缓存设置或其他什么？或者像这样的细粒度行为对 NFS 的期望太高了？