对于双活数据库的一致性备份如何解决？分布式的数据库呢？

数据同步逻辑错误问题：存储层面的复制技术基本以存储块为单位进行的数据复制，假设数据块发生了逻辑错误，那么存储是无法检测到的，它会继续将坏的数据块儿同步到灾备端，如果因此数据库发生宕机，那么灾备端的数据库也同样无法正常启动。
多层次的防范机制，来保障数据的可靠性和安全性，存储双活技术只是其中的一个层次，要辅以备份技术、数据库复制技术，连续性数据保护，建立了完善的数据保障体系。
（1）备份系统按照一定的时间频率对数据库做全量和增量备份，在遇到数据逻辑错误时，通过恢复将数据回退到最后一个备份版本。如TSM、NBU、COMMVAULT和国内备份软件。
（2）数据库复制技术有实时同步、准同步、异步等方式，保障主数据库逻辑错误无法正常运行时，切至备数据库，回退到备库前一个日志COMMIT后的版本。如DB2 HADR、ORACLE ADG、MYSQL主从复制等。
（3）连续性数据保护技术也是准/实时对存储数据块做快照，源端数据无法继续使用时，通过快照回退至前一个数据可用版本。如CDP。
分布式数据库的一致性解决：
1、数据分布的模式
a、主从复制
主从模式是最常用的一种模式，从机保存有主的全量数量，常用在主提供写，多个从提供读的场景。主从数据的一致性，可以实现为强一致，也可以实现为最终一致，具体看应用的具体要求（一致性和可用性的折中）。
       基于弱一致性的场景中，考虑可用性的要求，采用异步的记录日志的方式，如mysql中的replication机制的binlog,oracle的archive log，mongodb中的oplog等。
b、sharding机制
      当单个节点无法承载所有的数据量时，需要对数据进行切分，也就是sharding机制，数据的切分有很多种如concurrent hash，以及自定义的路由策略。
      一致性hash，优点是数据节点的加入和退出，受影响的数据的范围比较小。要考虑加入节点和节点宕机时，数据的迁移；当然基于可用性的考虑，在数据切分的基础上，需要数据的多个备份。采用了Hinted Handoff的技术，用来保证在有节点故障后系统的写操作不受太大影响。为了数据的均匀分布，可以把每个物理节点虚拟成多个逻辑节点，以逻辑节点作为环上的节点。节点的健康探测，可以基于gossip，也可以基于zookeeper进行管理维护。dynamo和cassandra中数据的切分分布是利用一致性hash。
       自定义路由策略，可以设定主节点对数据进行路由，可以基于表的数据规则，如日期，或者连续的范围分区；对于节点的迁入和迁出，需要路由节点自己维护，并且由主节点对数据进行迁移，节点健康状态由主节点（或者zookeeper）进行维护。HBase中的数据分布就是定义了一个META表，涵盖了key的范围所在分区，就是类似这种策略。
c、多主模式
     多主模式在平时用的不多，且数据的一致以及冲突，数据的合并比较复杂，这里不做阐述
2、一致性的解决方案
a、强一致性：
R+W>N，建设有3个节点，每次读时，读2个节点并且数据一致；写时，写2个节点都成功才算写成功。这种是强一致性。
2PC，3PC 多个节点都成功时，才算成功，否则进行回滚操作。
PAXOS，类似于2PC,解决分布式系统如何就某个值（决议）达成一致，进行投票选举。是一种无主的节点的算法。分布式的协调服务zookeeper就实现了这个算法，保障一致性。mongodb中的集群方案replicaset也实现了类似的算法。
b、 弱一致性（最终一致）：
由于分布式系统在数据同步时的网络延迟等等因素，无法保证副本数据和主节点时刻保持一致，当出现不一致的时，可以采用以下几种策略保证最终一致性
Gossip（Cassandra，Dynamo），是带冗余容错算法，也就是最终一致性的算法，无法保证某时刻所有节点数据一致，它是一个去中心化的部署方式，集群中每个节点维护一组状态，状态可以用key,value，外带一个版本号表示，版本大的比版本小的数据新，节点之间相互交流数据的版本信息，并更新数据，类似病毒式的传递，这样数据可以达到最终一致。Cassandra就是采取这种策略来进行数据的同步,并且维护节点的健康状态。