临时表：A`
SET-1Online
同城备2
B园区
2、建立同城备1→同城备2的复制，保障本地高可用
路由控制
SET-1Batch
同城备1 V2.0
d、将临时表rename成正式表
主2
半同步
主 V1.0
本地备
本地备 V1.0
VIP
ACK
b、搭建DRP应用，选择主库为源端，主库为目标端，建立表A与临时表A`的对应复制规则（未开启）
同城备4
3、升级同城备库数据结构
b、删除或备份正式表
正式表：A
同城备1
10、建立原主园区两个数据库到新主库的复制，恢复同城高可用
主3
5、停联机服务器
生产DNS
回补程序
旧表：old_A
IDC1
b、搭建DRP应用，选择主库为源端，主库为目标端，建立表A与临时表A`的对应复制规则（未开启DRP即未写入消息）
投产前T-n日：
原表：A
DRP
9、启动联机服务器
A园区
6、Innodb Commit
a、停联机服务器
异步复制
主4
7、重建主备复制，基本服务数据增量复制
c、存量数据导入主库临时表A`，并对临时表数据进行移行处理
4、IO线程
SET-1Online V2.0
业务恢复阶段
kafka
c、将存量数据导入主库临时表A`，并对临时表数据进行移行处理
4、返回成功
d、开启DRP生产端，记录原表操作日志，并推送至kafka
VAIM
IDC 1
a、停联机服务器、批量服务器
2、数据库DDL新增非null表末尾字段
互联互通-交易转接互联互通-分控互联互通-信息采集
2、写入binnlog
2、数据库DDL新增非末尾字段
B应用
1.提交COMMIT
e、启动联机服务器、批量服务器
初始阶段
4、启动批量服务器
主1
8、对基本服务数据补移行
钱包后台
原主库 V1.0
新主库 V2.0
5、数据库DDL修改表字段类型
IDC2
配置中心
1、断同城主备
Master（主库）
本地IDC
旧表：old A
SET-1Batch V2.0
c、删除或备份正式表
3、Innodb Commit
重建复制阶段
d、启动联机服务器
异步
9、断开同城复制，启动联机服务器并指向同城备1，同城备1作为新主库
3、DUMP线程
停机阶段
a、在主库创建临时表A`（新表结构）
本地备 V2.0
e、开启DRP消费端，根据回补规则消费消息，同步至新表
投产日：
Relaylog
6、数据库DDL修改表字段长度
备份文件传输
本地备2
A应用
同城IDC
STEP 3
ACK=1
新主
备用DNS
同城备2 V2.0
准备阶段
c、将临时表rename成正式表
数据核对
6、切换生产DNS指向同城备库
增量复制阶段
存量数据处理阶段
同城备5
全量备份
1、表结构需存在主键或者唯一键
准备阶段
表重命名阶段
数据核对阶段
b、停止回补程序和DRP
应用启动，根据service-name拉取连接配置（类似jdbc连接字符串），并与其建立监听关系
Master及本地Slave宕，切同城Slave
数据回补阶段
SET-1Online 2.0
公共管理互联互通-准备金互联互通-总控
1、升级前需检查同城备库的复制延迟情况，保证延迟不能过大，必要时提前停止批量或提前offline联机服务。
文本
binnlog
3、APP感知连接变更，断开原连接，重新与新主建立连接
Master宕，切本地Slave
同城备2 V2.0
Master及本地Slave宕，手工配置域名切同城Slave
SQL线程
基本服务阶段
当前IDC
1、故障时，orchestrator选出新主
数据库升级
适用条件：
数据库升级
配置中心（注册cluster名字服务信息）
STEP 4
域名
原主
同城备3
b、搭建DRP应用，建立原表与新表的对应复制规则
数据复制
本地备6
应用日志
本地备4
IO线程
STEP 1
2、应用尽量避免使用replace into语句，避免切换到同城备库时触发mysql的bug。
2、orchestrator更新配置中心相关service-name信息
本地备3
DUMP线程
本地备5
由于基本服务升级后，同城备库将升级为主库，强依赖于主备数据一致性，因此：
同城备6
c、将存量数据导入临时表，对临时表数据进行移行处理
本地备1
3、数据库DDL删除非末尾表字段
主5
IDC 2
新表：A
Master宕，通过VIP切本地Slave
APP
Master、本地Slave、同城Slave宕，切异地Slave
ACK=2
异地IDC
4、数据库DDL重命名表字段
3、数据库DDL删除表末尾字段
7、返回成功
STEP 2
主6
Slave（备库）
全量回放
