clone插件实现

clone操作主要分为几个阶段：

1、初始阶段。

初始阶段，会开启页面跟踪（Page Tracking）。开启页面跟踪后，修改过的页面的编号会被记录下来。页面的修改可分为两个阶段：首先在内存中修改（也就是在InnoDB buffer pool中修改缓存的页面数据），然后被修改的页面会在一定的时机持久化到数据文件。页面跟踪机制大概是在页面持久化的时候记录页面的编号（页面的表空间ID和Page ID）。

2、文件复制阶段。

在这一阶段，clone插件会复制所有InnoDB文件。文件复制结束后，开启InnoDB Redo归档，关闭页面跟踪。

3、页面复制阶段

这一阶段，会将文件复制阶段内跟踪到的页面复制出来。

页面复制完成后，停止Redo归档。

页面复制阶段完成后，当时的lsn记录为CLONE Lsn，这也是clone出来的数据库的lsn。

这里还会记录实例当前的复制位点，如binlog位点和gitd信息。

4、Redo复制阶段

这一阶段，处理归档出来的redo日志。应用完归档日志后，clone的数据库就是一个可以直接启动的数据库。

clone如何保证数据一致性

clone插件如何保证最终得到的数据的一致性呢？

假设clone开始时的checkpoint为ckpt 0，clone文件复制结束时的checkpoint为ckpt 1。

1、首先在clone开始时（clone start lsn），先开启了页面跟踪。开启页面跟踪后，在此之后写入文件的页面都会被记录。

2、文件复制阶段会将所有已经完成持久化的数据复制出来。这一步保证ckpt 0之前修改的数据都被复制出来。

3、文件复制过程中，数据库文件会持续更新。由于开启了页面跟踪，数据文件中更新过的页面ID都会被记录下来。关闭页面跟踪时数据库checkpoint为ckpt 1，则ckpt 0和ckpt 1之间修改的页面，都会被记录下来，这些页面在页面复制阶段处理。

4、文件复制完成后、关闭页面跟踪前，会先开启redo归档。redo归档会将日志序列号(lsn)在当前checkpoint之后的redo日志都复制到归档REDO文件中。由于redo归档是在关闭页面跟踪前开启的，所以能保证ckpt 1之后的redo日志都会被复制到归档REDO文件中。

5、页面复制结束时，可能会有部分页面的数据修改还没有刷新到磁盘。这些页面修改的序列号都在ckpt 1之后。而ckpt 1之后的redo日志都在归档redo文件中，通过重用归档redo日志，就可以将数据库恢复到一个一致的时间点（clone lsn)，也就是停止redo归档时的那一刻。

参考文档：

https://dev.mysql.com/worklog/task/?id=9209