怎样构建灵活的数据库分库备份集群
我理解是这样的：比如A1坏了，由于备份数据全部在B1上，要复制一份A1的数据，只能从B1拷贝过来，受限于B1的带宽。如果拆分更多的子表，副本随机打散分布在所有机器上（比如A1.1，A1.2，A1.3的副本分别在B1，B2，B3上），那么A1机器坏了后，剩余的机器可以从B1，B2，B3来复制副本。
■网友
我个人的理解，比较常见的做法是数据盘与系统盘是分开的。如果系统崩溃了，只要找另一个主机重新启动实例即可。因为这样的话主机数据文件实际并未被破坏。只是迁移了一个入口。而一旦数据盘出现了损坏，就需要重新从冗余数据中构建新的数据实例，可能耗时较长。一般情况下，数据盘基本都采用磁阵。
■网友
实际上是JD的高可用方案，主要技术概念：分布式，复制分库分表多实例下面事务处理基本上一组服务器就是负载群，B是A的热备
图示A组实例实际上相当于master，B组是slave，并且主从分别部署在不同机器上。图上所示一台机器分别是两个实例，并且互相不为主从关系假设其中一个实例挂了，就选这个倒霉蛋吧
【怎样构建灵活的数据库分库备份集群】
相应的slave提权飘移过去，接替挂掉的实例，业务基本没有影响，后期恢复，就是原来挂掉的实例同步数据重做日志后再接替回去，slave降级。
这时候只要不是同一组倒霉蛋继续倒霉，其他的兄弟倒霉一下对业务也没什么影响。比如shard2的master跪了，没事shard2的slave提权顶上
整个集群还是有完整的shard1-8数据库实例跑着。然后是一台机器挂了的情况
直接就损失了两组主从，shard1的master和shard8的slave都跪了，恢复的时候最直接的影响就是主实例的事务日志传送，这个恢复量身上面情况的两倍。而且上面说坏实例和坏机器是两回事，实例挂了，起不来，修不掉，大不了干掉重做。机器坏了还得重新上架备机，以及备机环境搭建同步，耗费时间当然比坏实例高。
推荐阅读
- 聪明人养花，这3种“花”怎样也要养一盆，每年能省不少医药费
- 大别山区贫困村的致富经：筑牢产业根基构建乡村振兴高楼
- 废弃矿坑建乐园安徽马鞍山构建完善长三角生态屏障
- 上海构建现代环境治理体系集成示范区打造超大城市生态环境治理的“样本”
- 互联网怎样解决“家政服务上门速度慢”的问题
- 怎样看待从1月8号起，QQ钱包开始提现收费
- 银行it人怎样转型
- 汽车|冬天怎样让车内温度快速升高？座椅加热的最佳使用方式二，外循环的作用总结
- 怎样进入通信行业
- 怎样评价扶他柠檬茶的小说《云养汉》的结尾