主从数据库结构?

我听说过两种数据库架构。

  • 大师,大师

  • 主仆关系

Master-master 不是更适合今天的网络吗? 因为它就像 Git,每个单元都有整套的数据,如果一个单元出了故障,那也没什么关系。

主从模式让我想起了 SVN (我不喜欢这种模式) ,其中有一个中央单元来处理事情。

问题:

  1. 每种方法的优点和缺点是什么?

  2. 如果你想在你的手机里有一个像 iPhone 这样的本地数据库,哪一个更合适呢?

  3. 选择其中一个是否是需要彻底考虑的关键因素?

99673 次浏览

我们正在权衡可用性、一致性和复杂性。首先回答最后一个问题: 这重要吗?是的,非常喜欢!关于如何管理数据的选择是绝对基本的,没有“最佳实践”可以回避这些决策。你需要了解你的特殊要求。

这里存在一种根本的紧张关系:

一个副本: 一致性是容易的,但如果它碰巧下降,每个人都离开了水,如果人们远离,那么可能支付可怕的通信成本。把可能需要断开连接才能操作的便携式设备带进来,一份拷贝是不够的。

主从: 一致性并不太困难,因为每个数据都有一个所有者。但是如果你看不到那位大师,你该怎么办呢? 需要一些延迟的工作。

大师-大师: 好吧,如果你能让它工作,那么它似乎提供了一切,没有单点的失败,每个人都可以工作所有的时间。问题是 非常很难保持绝对一致性。请参阅 维基百科文章了解更多信息。

维基百科似乎有一个很好的优点和缺点的总结

好处

  • 如果一个主服务器失败,其他主服务器将继续更新 数据库

  • 硕士可以位于几个物理位置,即。 分布在整个网络

缺点

  • 大多数多主复制系统只是松散地保持一致, 即延迟和异步,违反了 ACID 属性。

  • 急切的复制系统是复杂的,并引入了一些 通讯延迟

  • 冲突解决等问题可能变得棘手,如 所涉及的节点数量增加,所需的延迟减少

同时研究各种数据库体系结构。我已经收集了一些信息,这些信息可能与其他人将来的研究有关。我偶然发现的

  1. 主从复制
  2. 主-主复制
  3. MySQL 集群

我已经决定在我的用例中使用 MySQL 集群。然而,请看下面的各种利弊,我已经汇编

1. 主从复制

优点

  • 分析应用程序可以从从服务器读取数据,而不会影响主服务器
  • 整个数据库的备份对主机相对没有影响
  • 奴隶可以脱机,并在没有任何停机时间的情况下同步回主服务器

缺点

  • 在一个失败的例子中,一个奴隶必须被提升为主人来接管它的位置。没有自动故障转移
  • 当主服务器失败时,停机并可能丢失数据
  • 所有的写也必须在主从设计中写给主人
  • 由于必须读取二进制日志并将数据复制到每个从属服务器,因此每个附加的从属服务器都会给主服务器增加一些负载
  • 应用程序可能必须重新启动

2. 主-主复制

优点

  • 应用程序可以从两个主人阅读
  • 在两个主节点之间分配写入负载
  • 简单、自动和快速的故障转移

缺点

  • 不太一致
  • 配置和部署并不像主从机那样简单

3. MySQL 集群

基于 MySQL 集群设计的城市新生儿。MySQL 集群的开发考虑到了高可用性和可伸缩性,是无需停机、高可用性和水平可伸缩性的环境的理想解决方案。

有关更多信息,请参见 MySQL 集群101

优点

  • (高可用性)没有单点故障
  • 非常高的吞吐量
  • 99.99% 正常
  • 自动分片
  • 实时响应
  • 联机操作(模式更改等)
  • 分布式写入

缺点

您可以访问我的 博客完整细分,包括进一步详细介绍3个提到的体系结构的体系结构图。