主 – 主与主 – 从数据库架构？
我听说过两种数据库体系结构。
-
主 – 主
-
主从
是不是主人更适合今天的networking，因为它就像Git，每个单位都有整套的数据，如果一个人倒下，这并不重要。
主从提醒我SVN（我不喜欢），你有一个中央单位处理的事情。
问题：
-
各有什么优点和缺点？
-
如果你想在iPhone这样的手机上有本地数据库，哪一个更合适？
-
这些select之一是否需要彻底考虑？
我们正在考虑可用性，一致性和复杂性。 首先解决最后一个问题：这很重要吗？ 非常好！ 关于如何pipe理您的数据的select是绝对必要的，并且没有“最佳实践”能够避开这些决定。 你需要了解你的特殊要求。
有一个基本的紧张：
一个副本：一致性很容易，但是如果发生故障，每个人都离不开水，而且如果人们偏远，那么可能会付出巨大的通信费用。 将可能需要断开连接的便携式设备带入图片中，并且一个副本不会将其剪下。
主站：一致性不是太困难，因为每一个数据只有一个拥有主人。 但是如果你看不到那个主人，你会怎么做，需要某种推迟的工作。
师父：好吧，如果你能做到这一点，那么它似乎提供了一切，没有单点失败，每个人都可以一直工作。 麻烦是很难保持绝对的一致性。 有关更多信息，请参阅wikipedia文章 。
维基百科似乎有一个很好的总结优点和缺点
优点
如果一个主人失败，其他主人将继续更新数据库。
大师可以位于几个物理站点，即分布在整个networking中。
缺点
大多数多主复制系统只是松散一致的，即惰性和asynchronous，违反了ACID属性。
急切的复制系统非常复杂，引入了一些通信延迟。
随着所涉及的节点数量的增加和所需等待时间的减less，冲突解决等问题可能变得棘手。
同时研究各种数据库体系结构。 我编写了一些可能与其他人在未来研究有关的信息。 我碰到
- 主从复制
- 主 – 主复制
- MySQL集群
我已经决定使用MySQL Cluster来处理我的用例。 不过，请看下面我已经编译的各种利弊
1.主从复制
优点
- 分析应用程序可以从从站读取而不影响主站
- 整个数据库的备份对主服务器没有什么影响
- 可以使从站脱机，并在没有任何停机的情况下将其同步回主站
缺点
- 在一个失败的情况下，一个奴隶必须晋升为掌握接pipe它的地位。 没有自动故障转移
- 主服务器出现故障时停机并可能丢失数据
- 所有写入也必须在主从devise中对主设备进行
- 每个附加的从站都会向主站添加一些负载，因为必须读取二进制日志并将数据复制到每个从站
- 应用程序可能需要重新启动
2.主 – 主复制
优点
- 应用程序可以从这两个主人读取
- 跨两个主节点分配写入负载
- 简单，自动和快速的故障转移
缺点
- 松散一致
- 不像主从configuration和部署那么简单
3. MySQL簇
基于MySQL集群devise的城里新来的孩子。 开发MySQL集群时考虑到高可用性和可扩展性，是用于不需要停机，高可用性和横向可伸缩性的环境的理想解决scheme。
有关更多信息，请参阅MySQL Cluster 101
优点
- （高可用性）没有单点故障
- 吞吐量非常高
- 99.99％的正常运行时间
- 自动分片
- 实时响应
- 在线操作（模式更改等）
- 分布式写入
缺点
- 查看已知的限制
您可以访问我的博客完整的详细信息，包括架构图，进一步的细节关于3提到的架构。
