从“两地三中心”到“三地五中心”的升级
从“两地三中心”升级到“三地五中心”，是基础设施的重大升级，不只是简单的数据副本的增加。其带来的架构改善有以下几点。
（1）数据库具备了城市级容灾能力。
（2）应用具备了城市级容灾能力，应用的部署可以实现城市1与城市2双中心的模式，应用的容灾能力增强。
（3）数据库的容量提升，只读副本数量增加，服务能力增强。这种升级同时也对原数据中心架构引入了新的挑战。
（1）跨城带来的耗时增加，对业务的批处理、链路整体耗时、热点行等产生影响。
（2）数据同步副本数增加，原有机房间的网络需扩容。
（3）数据同步副本数增加，原有租户的硬件资源扩容。在架构升级的过程中，需始终保持容灾能力不降低：任何单个机房出现故障后，集群依然可用，且除了主库所在城市1之外的其他城市机房出现故障，集群依然可用，依然能够提供服务。其过程如下。
（1）初始状态，如图3-1-7所示。
（2）城市2新增一个副本，该副本用于数据异步式同步，不参与一致性投票，该副本对原集群结构稳定性无影响。参与投票的依然是机房1、机房2、机房3，容灾策略与“两地三中心”一致，数据同步耗时无增加。“两地四副本”模式如图3-1-8所示。
（3）城市3新增一个副本，该副本数据实时同步，参与一致性投票，但需限定在选主时不能作为主库，以避免耗时的增加，因应用部署还在城市1。在这种模式下，城市2、城市3的单个城市故障不影响集群的稳定性。“三地五中心”模式如前面的图3-1-1所示。
（4）城市2的不参与投票副本切换为实时同步，并开始参与投票，完成“三地五中心”的部署。在任意一个城市的机房出现故障时，都能够实现容灾切换。以上过程中，如果机房5不选择部署全量副本，只是参与投票的日志副本，那么建设周期会较短，可以直接在城市2建设全量副本，完成后立即进行机房5的配置。
应用耗时分析与优化
“三地五中心”带来的事务耗时增加了跨城耗时部分，会对业务全链路耗时、热点行、批处理产生影响，需要在架构升级前进行耗时分析，在升级后进行耗时的监控与验证。
基于分布式的trace中间件，使用实时计算对链路上的应用日志、数据库日志进行解析，分析出业务链路的不同场景中的库依赖、SQL模板、SQL执行顺序与次数。然后按照“三地五中心”建设的库关联、应用部署城市，分析会增加耗时的SQL，从而计算出整体链路的耗时增加。根据评估结果进行耗时的优化，可考虑的方向有：缓存、应用部署、SQL的优化，以及异步化改造等。
热点行也会因为单次事务的耗时增加导致锁冲突加剧，热点行问题更加明显。可以在建设完成后进行压测，识别热点行，并有针对性地解决热点问题。
单次耗时的增加，也会导致批处理整体完成的时间延长，需要评估是否会超出业务可接受的完成时间。可考虑的优化方案有调整批处理分组数、调整锁粒度等。
