数据库的倒退始终与用户需要变迁严密相干。近年来，数据上云的趋势愈演愈烈，越来越多的企业抉择把数据库迁徙上云，这对云上数据库的产品性能，尤其在可靠性和安全性方面，提出了更高的要求。
而现实情况是，企业在云上应用自建数据库的过程中，因为原生开源 MySQL 的事务能力并不欠缺，事务可能面临失落的危险，难以保障事务执行前后数据的可靠性和一致性。事务失落给企业造成的损失，也加大了局部企业对数据上云的担心。
什么是“事务”？事务是指数据库中对数据进行一个或者多个简单操作的根本单元，它承载着业务继续倒退的使命，不容有失。
以购物场景为例，一个残缺的购物过程通常包含买家付钱、卖家交付商品并在库存中减掉本次发售商品的数量、卖家收款三个操作。这三个操作是独立的，然而这三个操作须要都实现后，整个购物操作才算实现。这样的三个操作，就能够看作是一个事务，即一个事务中蕴含很多操作，要么都实现，要么都不实现。数据库中事务的失落，可能会导致很多简单数据的失落。
天翼云关系型数据库 MySQL 具备高牢靠个性，基于主备架构，可能在最大水平兼顾主库效率的同时保障主库解体时服务不中断，做到事务零失落，进而保障企业业务稳固间断，将故障影响降至最小，为企业排忧解难。
精准判断主库解体时的复制状态
天翼云关系型数据库 MySQL 半同步复制，是基于状态通道和工夫戳的高牢靠个性来实现的，其总体工作流程为：
数据库管控平台高可用模块（HA）保留主库末位的复制状态和工夫戳，备实例保留主库末位的复制状态和工夫戳，而后通过比拟二者的状态与工夫戳值来精准判断主库解体时的复制状态。
从原理上来看是绝对简略的，但在落地时并不容易，天翼云团队通过大量实际验证做到了精准判断。
依据主库解体状态自行复原服务
此前，天翼云关系型数据库 MySQL 半同步复制状态下绝大多数状况是同步复制状态，极少数状况下（如执行大事务时）会转换到异步复制状态，而后主动转换回同步复制状态。
当初，天翼云关系型数据库 MySQL 半同步复制凭借高牢靠个性可能精准判断主库解体时的复制状态，并依此依照以下四种状况精确复原服务：
1. 在同步复制状态下主库产生解体。此时先尝试拉起主库，拉起主库胜利，保障事务不失落，在这个过程中可实现秒级复原服务。
2. 在同步复制状态下主库产生解体，且拉起主库失败。此时主备数据统一，会将服务平滑切换到备库，保障事务不失落，并且秒级复原服务。
3. 在异步复制状态下主库产生解体，不能切换到备库，拉起主库胜利，保障事务不失落，在这个过程中能够实现秒级复原服务。
4. 在异步复制状态下主库解体后，不能切换到备库，且不能拉起主库，会在原来的数据上复原主库，保障事务不失落，在这个过程中能够实现分钟级复原服务。
天翼云关系型数据库 MySQL 半同步复制高牢靠个性，能最大水平保障主库效率，是因为主库的事务提交齐全依赖于备库的信号，而备库把事务写入中继日志后也会立刻返回一个 ACK（即确认字符），没有强同步复制备库回放事务带来的主从时延。
场景利用
机房故障断电
用户应用天翼云关系型数据库 MySQL，主备机跨 AZ（可用区）部署，如果主库所在的 AZ（可用区）机房故障断电不可用，主库因而产生故障，用户服务产生中断，此时天翼云关系型数据库 MySQL 凭借高牢靠个性能够使服务在秒级实现主备切换，并且做到服务与中断前的数据视图完全一致，不会有任何事务失落。
大事务执行期间数据库宕机
用户应用天翼云关系型数据库 MySQL 半同步复制模式时，当主库正在执行大事务，并且复制状态从同步复制转换到异步复制时，主库忽然宕机，服务因而被迫中断，天翼云关系型数据库 MySQL 主库会在数秒内被拉起并对外提供服务，并且与中断前的数据视图完全一致，不会有任何事务失落。
天翼云关系型数据库 MySQL 的高牢靠个性在保障事务不失落的前提下，可能同时做到秒级复原（极其状况下，分钟级复原），从而确保主备实例的数据一致性，极大进步了数据可靠性。这是天翼云为企业数据保驾护航，践行“致力于打造企业级数据底座”的无力体现。