开发者学堂课程【PolarDB-X 开源人才初级认证培训课程：数据导入与导出】学习笔记（二），与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1075/detail/15547
数据导入与导出
内容介绍：
一、PolarDB-X CDC
二、Global Binlog
三、Replica
四、Future Plan
二、Global Binlog
Demo
通过DEMO来看一下TraceId是如何工作的
左上角PolarDB-X控制台，右上角是一个DN，左下角又是一个DN。按照惯例，先看一下库，创建一个数据库，数据库名字为TraceId。再创建一张表，表的名字叫T1，按照有两个字段A和B，按照哈希的方式，以A作为拆分键来创建一张表
表已经创建好。看一下表的拓扑，show topology from是PolarDB-X私有的语法，名字为T1的表，它有16个分区，分别分布到了16个物理库，group就是一个分区名字，每一个group会对应一个物理的M有SQL库，即DN里边一个物理库表，因为没有分表，所以在每一个物理库上边就有一个物理表，看完拓扑之后，
DN里边正好是有八个库，135奇数的对应group奇数的1 3 5 7 11 15几个库
另外一个DN里边是也是有八个库是偶数，还有一个single。接下来准备了十条数据，往表里边插十条数据
数据已经插入，看一下数据，十条数据
其中a是拆分键，通过执行计划来看一下，因为选中了两条跨DN的数据，就是两条分布到不同的DN的数据，可以看a=1的数据看一下它的执行计划，它是分布在个0001物理库分区下边，2这条数据它是分布在002分区下边，两个数据一个是在001一个是在002，查看对应的DN是否一样，DN TraceId 001库下边有a=1的数据，DN2有a=2的数据
进行拆分键变更的操作，预先看一下各个DN的Binlog，因为操作完之后还要看它里边的内容。
执行拆分键的变更，把a=1的数据变成2，停一下，当a=1的数据变成2之后，数据会从DN1漂移到DN2，即数据在第一个库里边去查是没有的，在第二个库会有两条=2的数据，验证，可以看到DN1里边已经没有数据，DN2里边多了一条a=2的数据，符合预期。
接下来要看DN1 Binlog里面的内容，看一下拆分键变更一条SQL，因为这边只执行一条SQL，看一下它在DN里面的Binlog是什么样的，等待一下，因为里面有心跳，往上翻一下
可以看到有一个delete，因为数据要漂移，要从DN里边把数据删掉，从DN的Binlog里面看到，底下有一个delete的操作，内部Rows_query，常规的单机MySQL记录事务的查询日志，它在数据复制时没有太多的影响，通过Rows_query事件，把traceId已经记录，traceId有一个编号为2，记一下2的内容，delete操作的traceId序号是2，是一个 write row对应的是insert row，它的traceId是3
上面是2，是符合预期的，因为delete要在前面，insert在后面，在CDC内部程序处理的时候，会按照个2和3进行一个排序，在事务里保证这样的一个顺序
最后在Global Binlog可以看到是一个单机事务，里边记录的traceId 2 3是取自DN的两个Binlog里边的，做了一个排序，和原生的MySQL不一样的是一个update操作，在Global Binlog里边并不是一个update event，因为这是分布式的场景下规避不了的问题，所以会在一个事务里面把它拆分成delete和insert。
5.Online DDL&Event Reformat
对于分布式数据库，DDL变更其实是一个非常复杂的操作，因为它有非常多的节点，从控制台提交完一个DDL之后，后台内核内部在执行用户提交的DDL时是非常复杂的，因为它有非常多的节点，在每个节点之间在执行是异步的操作，分布式场景没有办法做到原子性，这是一方面，另外一方面对于Global Binlog CDC也更复杂，在DDL变更过程中，整个PolarDB-X所有的DDL都是一个online的DDL，online的意思是在执行DDL变更过程中，同时不能阻塞DML的操作，在各个方面上做变更时，DML的流量还在持续不断的进行操作，就会生成多版本的数据。
比如上图提交了一个DDL SQL，分片是在TSS 100的时间点完成的，第二个分片是在TSO 200，第三个是300 ，在不同的时间点完成了对应分片上的DDL变更，如果在整个100到300过程中，DML的流量还在持续不断的进入，在不同的分片上就会有不同的数据，比如在TSO 100这个时刻，分片1版本的数据是V2，比如操作是一个加列，V2的数据已经有新列的数据，但同样在分片2上，它没有执行加列操作，它里面的数据就是V1版本，在CDC汇总完所有DN数据之后，再往下游输出时，如果不做处理，它会产生一个形态，在100和300之间会同时穿插着V1和V2两个版本的数据，就会有问题，单机MySQL，如果下回挂的是单机MySQL，单机MySQL的schema是一个强校验的，schema还没有发生变更，收到了多列的数据，整个同步链路就报错，所以就要解这样的一个问题
有一个not online的方案，比如阻塞DML，让它规避在变更过程中有流量进来，肯定是可以实现的，但是这种方案是不可取的，因为站在现在角度阻塞DML执行是不现实的。选择了一个整形的方案，整形的方案的原理，有熟悉Flink会比较熟悉这个原理，会维护一个schema版本快照的历史，在CDC的内部对逻辑表维护一套快照，对每一个DN上所有的物理表也维护一份快照，维护两份快照，在消费各个DN的Binlog时，拿到了一个DN的数据，会去找当前在个时间线上逻辑schema的形态是什么样的，对应的物理Binlog的schema又是什么样的，二者之间的schema如果是一致的，可以放心的去对下游输出，如果之间的schema是不一样的，就要依照逻辑schema为依据来进行一个数据的整形。
DDL版本:一个时刻的Schema结构(包含表结构等）称为一个版本，DDL前的版本称为Vx，DDL操作后的版本称为Vy。
Vy兼容Vx的DDL类型︰
加列，新增列，如果插入老版本的数据，一般情况下是不会有问题的
列的长度变长，例如varchar(128)->varchar(1024)增加列的精度，例如double(10)->double(20)Vx兼容Vy的DDL类型
删除列
列的长度变短，例如varchar(1024)->varchar(128)删表
Vx兼容Vy的场景指的是变更后和变更前是不兼容的，比如删除列场景。
上图以常见的加列的场景来看，加列的场景就是用户提交了一个逻辑的DDL，加列的一个逻辑DDL，按照分布式的特性，它会在各个分片上分别在不同的时间点执行，执行完之后，内部设计了一个逻辑DDL打标的操作，等所有的DDL执行完之后，会做一个打标，打标它本质上就是一个分值事务，打标的目的是为了让事务产生TSO，会依据于个逻辑达标更新CDC里边的逻辑，schema的结构。
整形是无法规避在同一个时刻会出现双版本的数据，但是可以去对数据进行整形，比如在个某一时刻既收到了V1版本的数据，也收到了V2版本的数据，比如在提交加列操作DDL之前，表结构有ABC三列，CDC里边维护的逻辑表的原数据知道有三列，提交了加一个列，加一个D，加D列之后，在物理DDL加变更时，它是一个什么形态，比如执行完DDL的变更，它的版本就从V1变成了V2版本，在个物理DDL执行完之后，后边在收到的分片上面的物理Binlog里边已经有了D的一个列，并且物理DDL，它是一个auto table at column，CDC下边收到物理DDL变更之后，会把物理schema做一个实时更新，物理DDL同步给CDC之后，CDC逻辑schema有ABC，对应这个分辨的物理schema已经变成ABCD。
接下来会收到包含ABCD数据的event，会触发整形，因为整形的操作会完全以逻辑schema为基准，记录的逻辑schema还是ABC，会收到加列操作之后，会把里面D的操作以逻辑schema为基准，把D操作就会给它干掉，从而来保证在双版本数据期间，数据通过整形能始终一致的保证它是和逻辑schema保持一致，在CN内核内部会做完打标之后，CDC下游就会收到打标操作，打标操作会包含新增的D列，逻辑schema就变成了ABCD，各个分配的物理schema也是ABCD，逻辑的schema和物理schema是一致的，就不会再受到后面的数据也都是备案，不会触发数据整形的操作，从而保证在进行各种复杂的DDL变更的过程中，Global Binlog里边通过整形操作来保证，DML event里面的数据和schema是始终保持一致的，来实现下游消费时，能规避掉内部的各种细节，下游消费是完全无感知的，这个特性里边的一些处理还是比较复杂的，和分控分表的场景相比较，带来了非常大的收益。有过分控分表使用经验的同学应该知道，做DDL变更时是一个非常头疼的事情，各种运维操作会非常的繁琐，有的时候还要做上下游的各种数据的验证，是一个非常耗时耗力的形态。但如果用PolarDB-X对于DDL变更非常简单。
上图是DDL变更总体的操作流程块。
DEMO把上边的讲述通过具体的演示来呈现，还是四个窗口
左上角是一个CN，右上角是PolarDB-X元数据库，左下角是另外一个DN，先看一个库CDC，首尾有下划线
这个是CDC在PolarDB-X内部的内置的系统库，只有高权限的账户才可以看到，里边有三张系统表，一个是_cdc_ddl_record_，一个是heartbeat，一个是instruction，重点看_cdc_ddl_record，和CDC DDL达标相关的一个系统表，和DDL相关的也有两张表。一个是logical_meta_history，一个是phy_ddl_history，logical对应逻辑schema历史快照的信息表，phy是每一个分片上物理schema的快照历史表，现在有三张表，右边是在PolarDB-X里边的系统表，左边是在PolarDB-X元数据库数据库下边有两张表，一共是三张表
保证DDL变更中的整形操作，建立一个数据库，DDL test，创建一张表，表已经创建好
查看cdc_ddl record系统表里面的内容
已经有了一条记录叫create database DDL，是因为刚刚创建了一个DDL的库，后，每一个DDL操作都会有一个打标数据的，里面有一条数据，meta info是保存了库的所有信息，这个是建表，建了一张表，建表在打标，直观的来感受一下，表比较多错误比较多，因为物理表比较多，分期分的多。再看一下两张表里面的内容是什么样的
看到右边也有一条记录create table database，内容其实和打标的数据是非常类似的，里边limit一下
因为物理表非常多，分片非常多，上图是物理表的建表SQL，会维护到物理的DDL history表里面，上面DN1，有一个表。
上面DN2，DN就是一个节点，DN2有对应的建表操作，里面记录
TSO，打标是借用了一下分布式事务的东西，通过打标事务会取到TSO，因为TSO是一个逻辑时钟，逻辑时钟可以以它为基准在时间线上进行逻辑schema和物理schema的对比，做一些操作，T1表里边目前没有数据，给它不断的插入数据，脚本是启动了一个程序，程序会源源不断的往T1表里面插数据，目的是为了构造流量，DDL能力是online的，整形操作也是online，构造流量的目的是来触发一个整形的场景。
里边在已经插入了一部分数据，目前正在源源不断的往里面进行各种各样的插入操作，接下来要做一个add column c的DDL变更，已经变更完成
刚才时间是4.95秒，真正的生产环境不会慢，因为这个是一个测试实例，并且刚才建的逻辑表分区非常多，所以看起来比较慢一些，已经把流量停掉了，因为DDL变更已经操作完，在变更的过程中是有DML流量的，找了一个DN，左下角正在演示是一个DN的节点
去MySQL的Binlog里边看一下，右上角是刚才执行的SQL语句add column c，在打标之后，里边的TSO的情况，去拿到它的TSO，是一个虚拟TSO，从虚拟的TSO里边，要截取到高19位，因为是原始的TSO，基于原始的TSO去物理Binlog查看，因为物理Binlog里面会通过gcn event保存TSO，通过MySQL Binlog工具来解析MYSQL的Binlog，把它输出到一个3.log里边，通过TSO达标，看到有样的操作，有对应的个event、TSO和对应的打标，在逻辑地点打标之前，物理的表里面的数据，因为加了一个新的列式C列，可以看到C的默认值是0，在打标之前，各个物理DDL执行完之后，所有的物理分片就已经有C列，同时还有流量进入，在打标的之前，会有一些物理表里边已经有C列的数据，就是有C一列的数据了
找到一条数据，数据已经有C内容，它的内容是零。记录uuid，基于uuid做校验，登到CDC的节点，看一下Global Binlog里面的内容，输出1.1log，通过uuid Global Binlog里面查看，搜索一下已经找到数据
这条数据只有123，但是在这边是1234，刚才整形的操作已经生效，保证了schema和实际的数据之间的一致性。
6.Performance
CDC性能的情况，有一个指标event per second，Event是很多DEMO里边Binlog中的event，是每秒的event的写入的情况
CNDNCDC的配置，如上图展示，EPS在高点可以达到50万的水平，并且EPS不包含begin和个commit的，50万对于大部分场景，50万对应的流量是130兆，基本上可以支撑中型的一些互联网公司，延迟的情况就是在800毫秒到四秒之间的水平，中间会有一些抖动。
内容的目的是为了体现一下整个Global Binlog是经过了一系列的各种设计，一系列复杂的操作，给用户达到了非常透明的分布式的市场体验。整形过程中不会导致变更率的数据丢失，因为整形是以逻辑schema为基准做的整形，整形的些数据，都是，间数据都是没有用的，因为整形数据都是在DDL变更过程中产生的，打标完成之后才会返回给客户DDL是成功的，用户插入的才是正常的数据。因为在整形过程中，逻辑的表还没有生效，用户插入的字段就会报错，所以整形的数据不会导致变更，会保证数据一致
