我正在寻找一个类似这样的（SQL / RDB）数据库设置：
注意：这是一个用例非常重读且写入很少（写入延迟就可以了）
这样的事情存在吗？我看到了各种带有数据库HA配置的解决方案，但大多数都建议写入主节点或进行被动备份
或者我可以设置一个自定义应用程序，并让每个应用程序与1个数据库进行对话，并获得类似的结果，但我希望类似的东西已经存在
所以我的问题是：这样的事情存在吗？如果没有，有什么技术/架构原因，为什么不呢？
P.S。 - 我不会使用SAN，所有数据库都可以存储/访问相同的数据
编辑：就我正在寻找的内容进行更多说明： 1.我还没有选择数据库，但是我对MySQL / SQL Server / Oracle比较熟悉，所以我对这些数据库有一点小小的倾向。 2.如果大多数节点关闭（或者单个节点无法与集合通信），那么我希望来自该节点的所有写入都失败，并接受它可能提供旧的/过时的信息
失败/恢复情景预期： 1.节点关闭：它将在其恢复时从其他节点查询并获取更新 2.节点失去与集合体的连接：它将提供可能的旧数据来读取请求，并拒绝任何写入 3.节点与其他节点的数据存储不一致：多数规则 4. 4.多数规则不起作用：与任何拥有最新数据的人一起去（尽管这不应该发生） 5.条目是插入/更新/只读，即没有删除（手动ofc除外），所以我不需要担心删除后的更新，但在这种情况下我会选择删除记录并忽略更新 6.我错过了任何其他场景？
更新：我最接近我正在寻找的东西似乎是使用了一个法定数量+ 2个数据库，但我更喜欢我可以使用3个数据库，这样我就可以随时查询它们中的任何一个（进一步分发读数，并保留数据的另一个副本）
答案 0 :(得分：1)
您需要定义“最近”。在大多数具有插入复制的环境中，所有数据库在插入的几秒钟内将具有相同的数据（并且几秒钟似乎是悲观的）。
另一种方法是“从一个读取/全部写入”方法。在这种情况下，读取通过系统传播。然后，应用程序（或应用程序使用的公共层）将写入发送到所有节点。
但请记住，数据库复制的问题是不它的工作原理。问题在于它在失败时如何恢复，甚至如何识别失败。您需要确定节点发生故障时会发生什么，恢复丢失的事务的方式，以及您如何确定节点是否真正同步。我建议您仔细阅读您实际使用的数据库文档，并了解该平台提供的复制机制。