中间件 mysql 异地多活_数据库的异地多活分析和方案

前言

前文提到异地多活的几种型态和基于OceanBase实现方案。这里再总结一下基于其他分布式数据库(MySQL)实现异地多活时要考虑的点。本文不讨论为什么做异地多活，可以参考末尾的文章。

异地多活的目标

首先引用前文的分析。

异地多活的概念一直都有，只是内涵不断变化。以双机房多活为例，应用通常都是无状态的，可以多地部署。数据库有状态，传统数据库只有主库可以提供读写，备库最多只能提供只读服务(如ORACLE的Active Dataguard)： 1. 应用双活，数据库A地读写，B地不可读写。这种只有应用多活，数据库是异地备份容灾(无并发)。 2. 应用双活，数据库A地读写，B地只读。这种也是应用双活，数据库读写分离(实例级并发)。 3. 应用双活，数据库双活，两地应用同时读写不同表。这种数据库双向同步，应用同时错开写不同的数据(表级并发)。 4. 应用双活，数据库双活，两地应用同时读写相同表不同记录。这种数据库双向同步，应用同时错开写不同的数据(行级并发)。 5. 应用双活，数据库双活，两地应用同时读写相同表相同记录。这种数据库双向同步，应用同时写相同的数据，最终会因为冲突一方事务回滚(行级并发写冲突) 上面第1种情形，B地应用是跨地域远程读写数据库。两地距离较大的时候性能会很不好。2的B地应用是本地访问数据库。3，4，5三种情形两地数据库都提供读写服务，对应用而言是本地访问数据库，但到分布式数据库内部，其要读写的数据是否正好在本地就取决于业务和数据库的拆分设计。

首先确定要实现的异地多活目标肯定不是1和2这种。

其次，3，4，5都需要应用做水平拆分。