我们来看另外一个问题，三副本的内容是怎么保持同步的？比如说t1(p0)有三个副本，默认只有主副本提供读写。它们之间的同步是靠主副本上面的事务日志，也就是clog。当主副本上一个事务要提交的时候，它会把clog同时发给两个备副本。然后三个副本会把日志持久化到磁盘上，当三个成员里面，绝大多数成员把这个事务日志写成功之后，主副本上的事务就可以提交了。这里协议使用了Paxos协议。
除了保持数据同步以外，当主副本出现故障时，OceanBase会自动的从两个备副本里选出一个新的主副本出来，并且会保证新选出来的主副本拥有全部的事务日志，所以数据是不会丢的。OceanBase的故障切换的力度很细，它是分区级别的，所以我们不会说某一台机器是主某一台机器是备，从这个图里面我们可以看出来有5台机器有主副本，凡是有主副本的机器都可以提供服务。当你的业务表很多的时候，每台机器上实际上都可以有主副本，所以OceanBase的机器是没有主备概念的。
接下来我们详细的讲解OBProxy的功能。OBProxy的功能其实说起来也很简单，它就是只做SQL路由，不参与运算。当收到业务的SQL请求，分析出里面要访问的表，然后找到表对应的分区的主副本在哪个机器上面，就把它转发过去，取出数据之后原路返回。对于用户来说，OBProxy就是OceanBase数据库的一个代理，所以OBProxy的可用性非常重要。通常情况下我们会部署多个OBProxy，然后把它们挂在用户已有的一个负载均衡设备上面，比如说F5上面，然后F5提供一个VIP给业务用，但F5的高可用是靠自身的备机去提供。
这里顺带提一下，除了OBProxy有路由功能以外，OBServer自身也是有路由功能的。
接下来我们来看一下OceanBase的SQL兼容性。
前面说OceanBase支持多租户，它可以兼容MySQL或者Oracle，实际上只能2选1不能同时兼容。下图左侧是MySQL常用的SQL功能，右侧是目前实现的Oracle常用的SQL功能。就Oracle功能这一块，现在是重点发展的方向。
数据类型的话，我们已经实现了75%的类型和86%的函数。存储过程也支持了不少功能，有些场景下业务客户的存储过程是可以平迁到OceanBase上的。在事务方面，OceanBase支持两种事务隔离级别，一个是读已提交，还有序列化隔离级别，这点是跟Oracle一致的。
OceanBase支持跨节点的分布式事务，内部原理是两阶段提交，强一致的，并且这个事务对业务是透明的。使用的时候，业务只要稍微注意一下额，这个事务一定要及时提交，以避免长事务在OceanBase里会超时报错。此外，OceanBase还支持自治事务。
下面为大家介绍OceanBase相关的解决方案。在OceanBase的周边生态产品中，除了OceanBase集群外，我们还开发了一款OceanBase运维平台——OCP（OceanBase Cloud Platform），这款产品的目标就是让运维人员绝大部分的工作都可以通过运维平台来自动化完成。
第二个产品是OceanBase开发者中心——ODC（OceanBase Developer Center），面向开发人员，目标是让开发人员能通过这个平台去连接数据库，而不用直连数据库，这样我们可以控制权限和审计功能。
第三个就是OceanBase的迁移服务——OMS（OceanBase Migration Service），我们重点看一下OceanBase的迁移服务。为大家分享一个客户案例，某银行有一个Oracle业务，有一个MySQL业务，我们现在需要把它迁移到OceanBase上来。刚开始的时候客户应用是读写Oracle和MySQL，然后我们部署OMS之后，就把Oracle和MySQL的数据分别同步到OceanBase的Oracle租户和MySQL租户。这个时候业务是不停的，这个同步是实时同步，它会同步增量。当增量追上的时候，我们再寻找一个业务低峰期的时候，让业务短暂的停写原来的数据库，这个时候OMS可以对两边的数据做一个全量的校验，确保两边数据是一致的，然后再做决定，即切换。所谓的切换就是OMS把数据同步的方向给调整一下，从OceanBase同步回原来的Oracle数据库，这时候客户的业务再把连接指向新的OceanBase数据库，那么这样的一个切换过程就完成了。这里我们会把OB的数据同步回Oracle，这个是为了方便回滚，一旦客户决定再切换回去的时候，我们只需要把这些操作反过来做一遍就可以。同样的在回切的时候，我们依然要两边做数据校验，校验一致之后，我们再把同步方向返回来应用，把连接改回去就可以了。
OceanBase的容灾方案常用的就是两地三中心。两地三中心中整个集群是三副本架构，分布在三个机房，其中同城两机房，延时是2毫秒，异地机房延时是7毫秒。任何一个机器或者机房故障的话，数据库的服务都可以很快的恢复，并且保证不丢数据。当然有个缺点，故障之后写性能会下降一点点，如果应用不能承受性能下降的话，我们通常会做5副本，也就是三地五中心。
最后我们来总结一下OceanBase的几个核心关键字，低成本、高可用、可扩展、高性能的分布式关系型数据库，同时它又像云数据库一样，并且适合金融行业的异地容灾和多活。OceanBase目标就是做一款分布式的Oracle。
