MySQL的clone(克隆)要注意的点

    MySQL的克隆功能对于数据库来说建立主从太方便了。在实际工作中解决了不少问题，但是有一次的经历让我也感受到了其中有些需要注意的地方。如果不注意这些，会带来问题。本案例来说明一下，这不是bug，但是的确是一个问题。

    首先初始化一个MySQL8的数据库。MySQL安装软件过程省略，然后直接service mysqld start。MySQL就会初始化一个数据库。图1

                                                                                                     图1  

通过检查mysql的log看到了初始化的密码，如图2

                                                                                                     图2

然后用这个初始化的随机密码登录数据库。给root修改密码，这里改成了我的名字。红框。然后再去掉密码复杂度，绿框。改成“1”篮框。最后用1这个简单密码登录（黄框）。整个过程如图3.因为做实验环境，所以简单一点。正式环境不推荐这样。

                                                                                       图3

安装克隆组件，如图4

                                                                                                                 图4

创建克隆组件以及授权必要的权限，backup的权限，主从复制的权限，克隆的权限。如图5

                                                                                                      图5

然后创建表，并且打开调度参数。本案例产生的问题，全部在于这个定时任务。如果没有定时任务，则不会产生问题。如图6. event_scheduler=1,并且设置一个每10分钟写入一条数据的定时任务

                                                                                              图6

如下图图7，数据开始写入。写入的数据库是10.60.143.32。

图7

接下来，我们在10.60.143.33上，用上面相同的方法初始化一个新的数据库，用来搭建高可用的主从。如图8

                                                                                         图8

设定好clone的源头10.60.143.32，然后执行clone命令。如图9

                                                                                                           图9

执行4秒过后，图10.数据库clone完毕。克隆完毕，数据库是一个重启过程，所以再次执行select，会显示原有连接中断。clone是物理备份，所以是完全主库的镜像，那么定时任务也被带来过来。

                                                                                                             图10

然后建立主从关系。图11

                                                                                                               图11

开启主从的线程如图12

                                                                          图12

在10.60.143.32上写入数据，如图13

                                                                  图13

在10.60.143.33上，看到数据同步成功。图14

                                                                      图14

这个时候我们等待定时任务在10.60.143.32上发起写入，如图15

                                                   图15

然后这个时候观察10.60.143.33上，主从出现问题。因为定时任务两边同时执行，导致数据冲突。这就是我们在clone数据库上遇到的问题的复现。如图16

                                                                                                 图16

那么解决方案就是在从库上关闭定时任务。使用跳过出错的数据后，主从恢复。如图17和图18

                                                                 图17

                                                                    图18

                                                                    图19

那么使用clone数据库的时候，一定要确定有没有定时任务。如果有，那么clone database以后一定要把从库的定时任务全部停止。或者在clone database之前做出干预。或者设计的时候避免使用定时任务。

以上问题就是在工作遇到的定时任务对于clone database带来的影响和注意的点。