因为多库的Schema不完全一致，而报异常，有大神清楚，这种情况如何处理吗？

社区用户建议将分库分表单独拆分出来，目前分库分表会推导最宽的schema，也可以用datastream api 自己处理下这种schema不一致的case。如果是阿里云的实时计算flink版用户，可以考虑用CDAS语法做整库同步，后者也处理了这种情况。

楼主看看这个： CockroachDB在线Schema变更 CockroachDB参考Google F1在线异步Schema变更实现自己的在线schema变更.CockroachDB引入两个中间状态:

DELETE_ONLY状态: 变更的Schema只有删除权限, update语句拆解成delete+insert,只执行delete,丢弃insert.

WRITE_AND_DELETE_ONLY状态:变更的schema只有写权限,没有读权限.即变更只对insert, update, delete可见,对select不可见.

仍然以添加索引为例,CockroachDB的schema变更步骤如下:

第一步. 赋予删除权限,即状态DELETE_ONLY

第二步. 赋予写权限,即状态WRITE_AND_DELETE_ONLY

第三步. 回填索引数据

第四步. 赋予读权限,即状态PUBLIC

对于算法中提到的租约,CockroachDB引入了Table Lease机制.Table Lease分为Write Lease和Read Lease。

Read Lease：

对任一张表进行读写访问时，CockroachDB需要对该表的Schema申请一个Read Lease。申请Read Lease时，会向系统表system.lease中插入一条关于该表的Lease记录。

Write Lease：

执行Schema变更操作前，必须先获取Table的Write Lease。Write Lease确保针对同一张表同一时刻只能有一个schema变更任务运行。Write Lease会在schema变更任务执行过程中会不断被续租。

当Schema准备切换到下一个状态的时，Schema变更任务会检查前一个版本的Schema上的Read Lease，直到前一个版本的Schema上的Read Lease全部超时,这样CockroachDB就满足算法要求的集群中最多允许同时存在两个不同状态(这两个状态是递进的)的Schema。

正如算法中描述的那样,CockroachDB的节点上缓存了Schema,为了及时获得Schema变更,CockroachDB使用gossip协议在集群中广播Schema的变更.

在线schema变更通常是一个耗时较长的过程,不可避免的会出现各种异常导致中断,因此为了实现schema变更的高可用,schema变更会由Table lease holder节点负责执行,这个节点就是table的第一个range的leaseholder所在的节点.因此网关节点接收到一个DDL,会转发到table lease holder节点执行.如果table lease holder发生异常,那么新产生的table lease holder会重新加载变更任务,继续执行.如果变成schema失败,那么只要启动逆向回填任务就可以完成回滚.

在数据回填时,因为CockroachDB定位是支持EB级数据的存储,因此单表的数据量可能会非常大,因此回填也会转变成一个分布式任务,加快回填过程,多个节点并行执行回填,每个节点负责其中的一部分数据.数据回填过程为了尽量避免和正常业务发生事务冲突,会把回填过程拆分成很多小的事务去执行.