我们有 5 个岛屿,我们有 Galera 节点。岛上经常断网。当一个节点断开连接时,它的表会被锁定以进行读写。但它会在互联网恢复时同步并可用。在 MariaDB Replication 中,断开连接的节点可以读取和写入,但这不是一个好的解决方案。
是否可以在 Galera 断开连接的节点上进行读写?对于这种情况,还有其他可用的解决方案吗?
我们有 5 个岛屿,我们有 Galera 节点。岛上经常断网。当一个节点断开连接时,它的表会被锁定以进行读写。但它会在互联网恢复时同步并可用。在 MariaDB Replication 中,断开连接的节点可以读取和写入,但这不是一个好的解决方案。
是否可以在 Galera 断开连接的节点上进行读写?对于这种情况,还有其他可用的解决方案吗?
对于非常不稳定的网络,Galera 可能不是正确的解决方案。
如果每个岛屿都有自己的“足够”可靠的服务器,那么问题就解决了一半。将数据传入(和传出)其他岛屿需要使用方案背后的应用程序代码来完成。
架构和数据流设计需要避免在不同岛屿上同时创建 UNIQUE(或 PRIMARY)键的各种情况。UUID 是一种解决方案,但它不适用于大型数据库。
然后是“陈旧”数据的问题。如果一个孤岛上的服务器有来自其他岛屿的“旧”数据,用户是否会通过对这些陈旧数据采取行动来搞砸事情?
底线:要么努力使网络更加健壮,要么站在你的头上使应用程序健壮。
备择方案...
超过2个的循环真的很糟糕。任何中断都会使其余部分处于奇怪的状态——有些复制正在发生,有些则没有。如果服务器真的死了,那么修复它就是一场噩梦。
多源复制...鉴于您有小型数据库,并且跨岛访问是只读的,这可能是一个很好的解决方案。您有一台服务器是所有其他服务器的从属服务器。也就是说,每个 Island 都会有一个 Master,并且(当网络正常工作时)将内容复制到那个公共的 Slave。(一个岛是否更有可能保持联系?)
所有形式的复制/集群恢复复制并在网络再次活跃后很快“赶上”。
至于UUIDs
对比AUTO_INCREMENT
——如果对任何特定表和所有相关表的所有写入都只通过一个 Island 的服务器,那么我认为不需要 UUID。
(无论如何,只有 100MB/岛,UUID 可能不会从性能悬崖上掉下来。)