数据库构架设计主要有Shared Everthting、Shared Nothing、Shared Disk

数据库构架设计

• Shared Everthting

  针对单机，完全透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的代表SQLServer。想象为启2个进程，一个为主对外服务，挂了切另一进程接管

• Shared Disk

  各机私有 CPU和Memory，共享磁盘系统

  典型代表Oracle Rac，可通过增加节点提高并行处理能力，但存储器达到瓶颈时，增加节点并不能获得更高的性能

• Shared Nothing

  各机器都私有的CPU/内存/硬盘等，不存在共享资源，各处理单元之间通过协议通信(比如 paxos之类)，并行处理和扩展能力更好

  典型代表hadoop ，各节点相互独立，各自处理自己的数据，处理后的结果可能向上层汇总或在节点间流转

  常说的 Sharding 其实就是Share Nothing架构，只需增加服务器数就可以增加处理能力和容量

RAC VS Gelera Cluster

RAC 无论 select 还是 update 都有节点间内部通信，block 在节点间传输

MariaDB Gelera Cluster 只有在 commit 发生时才发生节点间通信

RAC 添加新节点，无需同步数据

MariaDB Gelera Cluster 添加新节点要全量同步数据（SST）

MariaDB Galera Cluster

同步复制

真正的multi-master，即所有节点可以同时读写数据库

自动的节点成员控制，失效节点自动被清除

新节点加入数据自动复制

真正的并行复制，行级

使用与MySQL完全一致

优势

• 多主，不存在Slavelag(延迟)
• 不存在丢失事务的情况
• 同时具有读和写的扩展能力
• 节点间数据是同步的，而Master/Slave模式是异步的，不同slave上的binlog可能是不同的

缺点

• 加入新节点时开销大，需要复制完整的数据
• 写放大，所有的写都发生在所有的节点
• 有多少个节点，就有多少份重复的数据
• 由于事务提交需要跨节点通信，即涉及分布式事务操作，因此写入会比主从复制慢很多，节点越多，写入越慢，死锁和回滚也会更加频繁
• 对网络要求比较高，如果网络出现波动不稳定，则可能会造成两个节点失联，Galera Cluster集群会发生脑裂，服务将不可用

局限

Delete 不支持没有主键的表，没有主键的表在不同的节点上的顺序不同，select … limit …将出现不同的结果集

单表所锁支持有限

General Query Log只能保存到文件中

不能有大事务写入， 10w 行，且写入不能超过 1GB，否则客户端直接报错

由于集群是乐观锁并发控制，commit阶段会有事务冲突发生。如果两个事务在集群中的不同节点上对同一行写入并提交，则失败的节点将回滚，客户端返回死锁报错

XA分布式事务不支持Codership Galera Cluster，在提交时可能会回滚

整个集群的写入吞吐量取决于最弱的节点限制，集群要使用同一的配置