关系数据库的事务（transaction）是一组操作序列，比如读，插入，删除，更新等等。事务有四个基本要素，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），即ACID：
原子性：事务的所有修改操作，要么全部都执行，要么全部都不执行。在任何情况下，都不能出现一个事务的部分操作执行、部分操作没有执行的情况，比如一笔从账户A到账户B的转账，如果账户A状态异常或者余额不足，那么转账压根就不会发生，如果账户A状态正常且余额充足，那么就可以对账户A进行扣款，但如果账户B状态异常比如限额超出，那么转账无法进行，账户A的扣款必须回滚。任何情况下都不应该出现账户A已扣款、账户B却没有入账，或者账户A没有扣款、但账户B却已经入账的情况。
一致性：每一笔事务都把数据库从一个一致的状态变成另一个一致的状态，比如新增一笔交易使得数据库增加了一条交易记录，但不论是交易前还是交易后，每一笔交易的“交易号”依然是唯一的。这种一致性也称为数据库内部的一致性。出于容灾等因素的考虑，数据库通常采用“主库+备库”的方案，一致性也指备库的数据与主库的数据的一致性，为了区别，这种一致性也称为主备一致性。
隔离性：通常情况下，数据库常常有多个事务同时在执行，这些事务之间可能相互影响，从而产生预期之外的效果：例如账户A的余额是80，事务1拟从A转50到B，账户2拟从A转70到C，两个事务同时执行，它们分别检查账户A的余额的时候都是可以扣款的，但两笔扣款后，账户A的余额变成了负数，这显然是不应该的，因此需要对并行执行的事务进行一定的隔离。最高级别的隔离是可串行化（serializable），即一个数据库上所有并行执行的事务的结果等价于这些事务按某个顺序一个一个地串行执行。可串行化的隔离最彻底，但常常对数据库处理事务的性能产生较大的影响，因此SQL标准还定义了几种隔离级别，即可重复读（repeatable read），读已提交（read committed），读未提交（read uncommitted），其中读已提交（read committed）较好地平衡了隔离效果和性能，因此在实际生产系统中普遍使用。此外，快照读（snapshot isolation）隔离级别的隔离效果略低于可串行化，除了几种特殊情况外基本等同于可串行化，因为实现简单、效率高、隔离效果较好而常常采用。
持久性：事务成功提交后，它对于数据库的影响是永久性的，即使提交后出现了停电或者设备故障等。为了防止断电导致事务丢失，事务在提交前通常持久化事务日志（redo log）到硬盘，为了避免硬件故障或损坏导致事务丢失，数据库系统通常采用“主库+备库”（即主备镜像）来进一步保证持久性。
事务的ACID特征是关系数据库区别于其他数据存储系统的根本点，也是金融、通信、交通、电力、商业等系统采用关系数据库的根本原因，这使得关系数据库成为了当今社会十分关键的信息基础设施，因此关系数据库系统的高可用至关重要。传统关系数据库的高可用机制主要是主备镜像，银行系统的两地三中心（主库+同城热备库+异地灾备库）是主备镜像的一种形式。
主备镜像的基本原理是：数据库主库提供读写服务（即执行事务），并同步事务日志（redo log）到备库，备库通过回放日志来保持与主库一致，通常情况下备库不提供服务，但备库可以升级为主库，比如主备切换或者主库因灾难无法恢复时升级备库为主库等，如下图：
数据库主备同步有三种模式：
最大保护模式（max protection）：每一笔事务在主库执行后，事务日志（redo log）必须同步到备库才提交事务并应答客户。这种模式下备库与主库是完全同步的，问题是，一旦主备之间的网络异常或是备库异常，则主库的写入（增删改）操作就会被阻塞，数据库服务的可用性受到很大的影响，因此实际生产中极少采用。
最高性能模式（max performance）：主库执行完事务后就提交事务并应答客户，事务日志（redo log）异步传输到备库。这种模式下数据库的性能更好，但备库数据相比主库有少量延迟，主库故障后备库数据不完整。
最大可用模式（max availability）：主库执行完事务后，事务日志（redo log）尽量同步到备库后再提交事务并应答客户，如果备库应答超时，则主库也会提交事务并应答客户。这种模式下多数情况下备库与主库是同步的，但异常情况下（例如网络抖动等）还是会导致备库与主库不同步，因此备库与主库的一致性无法完全保证。
以上分析发现主备镜像下数据库的主备一致性与可用性是冲突的，两者无法同时保证。本质的原因是传统关系数据库软件假设其所依赖硬件设备（服务器、存储等）是相当可靠的，其高可用完全依赖于这些可靠的硬件，数据库软件本身在高可用上其实是缺失的。
传统数据库软件本身高可用的缺失导致了以下的缺陷：
传统数据库无法做到主库备库完全一致：这个已经在前面进行了分析。众所周知，就像为了消防安全必须经常进行消防演习一样，银行等关键行业和领域为了应对可能出现的电力、网络、火水、地震等灾难也必须经常进行容灾演习，但由于数据库主库备库不一致，容灾演习时的主备切换对用户是有损的，需要人工对账等手段控制因此而导致的资产损失和对用户的影响，这使得容灾演练相当困难和繁琐。
传统数据库系统的成本高昂：数据库软件本身高可用的缺使得传统数据库完全依赖于数据库服务器、存储及网络等硬件的高可用，特别是存储和网络，其五个九（即99.999%的年可用率）的高可用是数据库五个九可用性的基础和前提，这导致传统数据库系统的整体成本居高不下。
分布式OLTP数据库缺失：99.999%年可用率的硬件几乎是当今单个硬件可用性的顶峰，然而当100台99.999%年可用率的硬件在一起同时提供服务时，整个系统的可用率大约只有99.9%，这完全无法满足业务系统的高可用需求。这导致了分布式OLTP数据库的缺失，并使得高并发的业务不得不使用昂贵的大型服务器，进一步增加了成本。
传统数据库无法水平伸缩：这其实是分布式OLTP数据库缺失的必然结果。这使得传统数据库缺乏弹性，面对秒杀和双11等场景传统数据库扩容后无法缩容，导致资源浪费。
