开发者学堂课程【如何将PolarDB-X与大数据等系统互通：如何将 PolarDB-X 与大数据等系统互通】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/984/detail/14937
如何将 PolarDB-X 与大数据等系统互通
因为这里边有一个系统内置的一个心跳。在PolarDB-X上面来看一下目前有哪些连接，可以看到当前有四个连接，两个cdc可以忽略，这是系统内置的两个连接，一个是test，其实就是现在在之前面连接的。另外一个也就是刚才的一个 MySQL 的一个连接。接下来就可以开启刚才所说的转账测试，在开启之前检查一下端口映射是否正常，现在再次跑起转账测试，这次转账测试是在远端的 PolarDB-X 执行，然后下游的一个 MySQL 打了一个同步的链路，那么希望通过同步的机制，可以将 PolarDB-X 里面的增量变更正常给同步过去。在此启动转账测试，这边可以看到这张表已经成功的建出来了，里面有100个账户，并且已经开始了转账，那么来下路这边来看一下，这边来看一下下游好像挂了，那先把上游的停掉，检查一下哪里出问题了。可以看到上游已经没什么变化了，看着像是my SQL挂了，那就重新跑一个，现在PolarDB-X 这个容器是很好的， MySQL的容器不知道什么原因挂了，那就重新启动一个，等到 MySQL初始化完成之后，在重新尝试做一遍，先把之前的表再次删除，回到初始状态。
下游的 MySQL 因为是刚建的，肯定里面也是空的，再次执行 master 的指令，这次把它的那个位点设置的更往后一些，因为刚才已经执行了一堆那个他们从这个位置开始跑步，再次开启如果再崩就是什么地方真的有问题了，真的有问题，就跟昨天看到的结果不太一样，我去查一下原因，那么这个例子就便是了后面我找到原因之后再在下一次的那个演讲当中跟大家来讲一下这种问题，排查可能也是一个非常有意思的过程。
那今天讲解的第三部分就是全局 Binlog 的一个原理，就是它到底是怎么实现的。可能用户并不清楚 MySQL Binlog 是什么样子的，我这边也简单做一个介绍。
首先可以把它想象成一个很长事件，比如这样一个队列，那么它是按照以基本的一个事物为单位，也是这个事务涉及到哪些变更，他会把它记录下来，这样以事物为单位，一个一个的排队，把他们给记录下来，这样很长的一个单一的队列，那么也就是说如果你的数据库在实例创建的一开始就记住了 Binlog ，并且一直到现在也没有删除这个Binlog ，以及投放这个 Binlog ，它可以把数据原模原样的给还原出来，这就是 Binlog 这样的一种存在。
那么MySQL 的 Binlog有三种格式，一种格式叫做 statement ，就是也是基于你的SQL来记录的，它会把你历史以来所有的CQ 顺序把它给记录下来；那第二种叫做 Row based就是基于行变化的，也就是这个系统里面这行总 insert 一直到后面的update，一直到后面的 delete 整个变化过程，这是每一行都这样去记录的,这是第二种格式;那第三个其实是将这两个混合起来，既记录了那个 CQ 又记录了 Row 的变化，在它认为合适的地方，它用 Row 这样的一种方式。
这几种方式各有优缺点，但是目前就是从 MySQL 5点7.7以后官方默认的是 Row .因为它很简单，而且能够严格的保证数据的一个移植性，你这些像那个基于 SQL ，它可能会有些问题。你在下午再重发的时候，并不能严格保证数据的一致性，这样就是MySQL 的 Binlog。
也就是说可以从现在开始简单的认为MySQL 的 Binlog是一个单一的队列，这个队列按照它的每行数据的时间变化严格地把他们给记录下来了，这就是MySQL 的 Binlog。那 PolarDB-X里面它的那个增量的日志是什么样子的呢？
首先前面讲了一下 PolarDB-X 的一个架构，那么它的那个存储层（DN），可以无脑的认为它是一个 MySQL ，那就意味着在 PolarDB-X 里面也有一份MySQL 的 Binlog ，只不过是现在系统当中可能会有很多DN，也就有很多的 MySQL ，也就意味着有很多的 Binlog 的队列，那么如果想生成一个 MySQL 的 PolarDB-X 的兼容MySQL 的 Binlog 这样的一个增量日志，那是不是说只要比较简单的将这几条物理的MySQL 的 Binlog ，也就是DN的一个Binlog 进行一个合并，也是那个数据结构算法里面做了一个经典的题目，这样的一个过程那就可以了？
并不是这样的，为什么呢？因为PolarDB-X 的这个分布式的系统为了实现数据库的一些基本功能，比如说15，它引入了很多新的改变，那这些改变就会导致做的全局 Binlog 在实现的时候也有一定的复杂度。首先来看一下全局 Binlog 实现过程当中，因为和那个相关的英文分布式而已引入的一些协议、算法、设计等等。
那么讲数据库不得不讲这个话题就是事物，但在 PolarDB-X 里面也不例外，提供了一个分布式事物的能力，现在主流的分布式系统里面一般实现分布式事物，都是通过两阶段提交这样的一个方式进行的。那如果不清楚两阶段提交的，也就是这样的一个协议或者过程的，后面可以去网上搜索，这种讲解的资料是非常多的。简单来说，它要去达成一个目标，这个目标是什么呢？
就网络当中有对一个的，比如两个或者更多的这样的一些组建，它们之间要协商一本的数据，并且有一个一致的一个结果。这个时候就可以通过两阶段当中有两个角色，第一个叫协调者，第二个叫参与者，那么这两阶段大概的过程就是协调者首先向所有的参与者发起这样的东西叫 prepare ，就是准备好做这个变更，准备好接受新的一个数据，这就是第一个阶段。那么所有的参与者如果现在状态很好，它经过各种判断之后，可以接受这个新的数据，那么就会跟协调者之间返回一个 OK ，那么协调者在收到所有参与者返回的 OK 之后，它认为这个 Binlog 变更就可以做下去了，因为所有人都告诉他已经 OK 了。那么第二步，他就会再通知所有的参与者说现在把这个变更真实的把它给记录下来，那所有的参与者接收到了之后，他把这个变更再记录一下来，这样就完成了一个连阶段提交的过程，听上去是比较简单，也容易理解的，那么这里需要注意一些细节。第一个是如果有一些参与者在第一阶段的时候因为各种原因嗯回了个不 OK 或者因为网络的问题没有回，那这个时候协调者者会怎么办呢？那协调者只要满足说不是所有参与者告诉我 ok 了，那就把这件事情或者说在数据库里面这个事务回滚掉。
这是协调者要处理的一个问题，如果因为网络的原因，所以协调者这边同时会有一个超时的机制，那跟所有的参与者之间通信的时候，有一个网络超时，那如果在超时时间之内没有回复我，也认为它是失败了，这样就保证这件事情一定会达到一个最终状态，这就是简单来说所谓的两阶段提交。
那么在 PolarDB-X 里面同样也用了这样的一种提交的方式来进行分布式事物，因为 PolarDB-X 的 DN 是MySQL 的一个分支，那么 MySQL 在实现跟分布事物相关的能力的时候，它就实现了 XA 两阶段提交的这样一个规范，那么也就是说在 XA 这样的一个规范里面，它规定了连接提交里面的各种角色，应该在什么情况下应该怎么做，它是一个规范。
MySQL 是遵循这样一个规范的，所以PolarDB-X就直接去借用了MySQL 这样的一个规范，把 CN 层作为规范里面的事物的管理者，那么把 MySQL（DN）作为我的一个resource management，也就是两阶段当中的一个参与者。
