Master-master与主从数据库架构？

Question

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

• 主 - 主

• 主 - 从

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

Master-slave让我想起了SVN（我不喜欢），你有一个处理东西的中央单元。

问题：

1. 各自的优点和缺点是什么？

2. 如果您想在iPhone手机中安装本地数据库，哪一个更合适？

3. 选择其中一项是彻底考虑的关键因素吗？

Answer 1

同时研究各种数据库架构。我编写了一些可能与其他人研究相关的信息。我遇到了

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

我决定在我的用例中使用MySQL Cluster。但是请参阅下面我编写的各种优缺点

<强> 1。主从复制

赞成

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

缺点

• 在失败的情况下，必须将奴隶提升为主人以接管其位置。没有自动故障转移
• 主机发生故障时的停机时间和可能的数据丢失
• 所有写入也必须以主从设计的方式对主设备进行。
• 每个额外的从站都会向主站添加一些负载，因为必须读取二进制日志并将数据复制到每个从站
• 可能必须重新启动应用程序

<强> 2。 Master-Master复制

赞成

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

缺点

• 松散一致
• 不像主从配置和部署那样简单

第3。 MySQL群集

基于MySQL集群设计的小镇新人。 MySQL集群的开发考虑了高可用性和可扩展性，是用于不需要停机，高可用性和水平可扩展性的环境的理想解决方案。

有关详细信息，请参阅MySQL Cluster 101

赞成

• （高可用性）无单点故障
• 非常高的吞吐量
• 99.99％正常运行时间
• 自动分片
• 实时响应
• 在线操作（架构更改等）
• 分布式写入

缺点

• 请参阅known limitations

您可以访问我的Blog完整细分，包括有关上述3种架构的详细信息的架构图。

Answer 2

我们正在牺牲可用性，一致性和复杂性。首先解决最后一个问题：这有关系吗？非常好！关于如何管理数据的选择绝对是根本性的，并且没有“最佳实践”躲避决策。您需要了解您的特定要求。

存在根本的紧张局势：

一个副本：一致性很容易，但是如果碰巧失败了，那么每个人都会失控，如果人们偏远，那么可能会付出可怕的通信费用。将可能需要断开操作的便携式设备放入图片中，一份副本不会将其剪切掉。

Master Slave：一致性并不太难，因为每个数据都只有一个拥有主数据。但是，如果你看不到那个主人，你会怎么做，需要某种推迟的工作。

Master-Master：如果你能使它工作那么它似乎提供了一切，没有单点故障，每个人都可以一直工作。麻烦的是非常难以保持绝对一致性。有关详情，请参阅wikipedia article。

维基百科似乎对优缺点进行了很好的总结

  

优点

     

  

• 如果一个主人失败，其他主人将继续更新   数据库中。

  

• 大师可以位于多个物理站点，即   分布在整个网络上。

  

     

缺点

     

  

• 大多数多主复制系统只是松散一致，    即懒惰和异步，违反ACID属性。

  

• 渴望复制系统很复杂，并介绍一些    通信延迟。

  

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