这个是不同的级别的问题，数据库双活保证的业务的持续性，但是灾难的发生往往是突然的，虽然说双活的情况下这个概率会比较低，但是还是需要防范于未然所以，即使数据库是双活，灾备也是必须的。...

在一个系统分析、设计阶段，因为数据量较小，负荷较低。我们往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低，这时再来考虑提高系统性能则要花费更多的人力物力，而整个系统也不可避免的形成了一个打补丁工程。 所以在...

高并发的问题确实很麻烦，特别是在双活的情况选，常规的而言，优化查询，特别是只读查询，对于查询可以通过读写分离或者缓存来处理，然后是双写的压力，这边可能会造成双向同步的压力过大，还有表的锁定问题，还有就是因为数据的延迟问题可能会造成数据短期的不一致，这个就需要结合业务了。...

mysql双活跟你说的有点区别就是，你说可能是单个数据中心的模式，如果做双活，肯定是多个数据中心的，还有就是，至于流量的切换可以在应用层这边做分流，至于你说的无人值守，其实在双活的理论上是不需要的，一个数据中心全都出问题，所有的流量走另外的数据中心...

数据同步逻辑错误问题：存储层面的复制技术基本以存储块为单位进行的数据复制，假设数据块发生了逻辑错误，那么存储是无法检测到的，它会继续将坏的数据块儿同步到灾备端，如果因此数据库发生宕机，那么灾备端的数据库也同样无法正常启动。多层次的防范机制，来保障数据的可靠性和安全...

应用的读写都指向最近的节点，避免不一致应用确定只向一个节点进行写，即使是重试也只对一个节点进行重试最安全就是不同节点的应用写不同的表，避免数据冲突尽可能避免手动设置自增ID的值，手动设置前一定要分配好，避免自增跳号的冲突...

mysql的半同步复制不能实现真正意义上的双活，只能是读写分离。

其实这个问题，看你站在什么样的角度，你是需要强自增还是弱自增，强自增的话，需要构建一个生成自增的服务，双活的两端应用，通过自增服务获取当前自增，然后生成相应的数据，这里面的构成会比较复杂，弱自增简单点的可以采用MySQL数据库自带的自增，因为是双活的架构，需要在两边设置自增起...

A,B两端数据库根据业务不同来划分主次对外提供服务，两端数据库都处于活动状态，都能独立工作且双向同步，举个例子，业务A，优先接入A端数据库，同时，A端的数据会同步到B端，B端会有少量业务A接入，同时也需要同步B端数据到A端数据库，当发生数据故障或者网络中断的时候，启用B端数据库作为唯...

目前一般的常用的模式主备模式，看似备份但真正到恢复阶段是有不确定性，只能保证数据不丢失，但无法做到在主机房重大故障时对业务没有影响，所以数据库双活是每个企业都需要考虑的一个问题，特别是重要业务，更是重中之重，大多数的双活方案是基于Binlog双向复制，Galera replication，Gr...