原因:腾讯云数据丢失,但是又有业务在腾讯云上,所以需要对数据库进行备份(自建从库,腾讯云的说法),做腾讯云数据库的从库
基于mysql 5.7实现.
1、首先用户通过在控制台创建一个用于复制的账户wjqrepl；

2、给wjqrepl用户赋予相应的权限

需要进入数据库命令行中，
grant replication slave on *.* to 'xxxxx'@'%' identified by '1234567';
flush privileges;

3、导出云数据库中的业务库数据

4、确认自建从库是否开启GTID 

show variables like '%gtid%'  查看gtid_mode 的value是否为on
如果没有，则修改my.cnf 在[mysqld]中增加如下内容：
gtid-mode=on
enforce-gtid-consistency=on

5、将上述导出的备份文件导入到自建的mysql数据库中；

带有 GTID 信息的备份 文件, 要求目标数据库实例必须开启 GTID 功能, 且当前数据库中无其他 GTID 信息. 如果目标数据库中已经记录了一条或一条以上的 GTID 信息, 那么在导入数据库时会上面类似的错误；
解决方法：

1、重新 dump 数据库, 使用--set-gtid-purged=OFF的参数禁止；
2、在目标数据库中执行 reset slave all;和 reset master;清空所有 GTID 信息之后就可以导入了；

6、在CVM自建mysql数据库配置主从同步关系，并启动slave;

change master to master_host='bj-cdb-d8xcsyv6..com', master_user='re49pl', master_port=63021, master_password='re43sswo@', master_auto_position=1;

7, 出现“The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.”

1、这个应该是由于你在主库上执行过purge binary logs，然后当从库change master的时候，却要执行那些事务。
你可以在主库上先查找哪些gtid被purge了。

show global variables like 'gtid_purged';

然后拿着这个value，去从库上依次

stop slave;

set global gtid_purged = '8170836d-8e48-11e0c29b48f84:1-2'; # xxx是你主库上查到的value。 如果有多个，就一起写在后面，用，隔开

start slave;

这样能跳过执行被主库已经purge的事务了。

附一张从腾讯云文档的截图比较清楚
腾讯云数据库备用-基于GTID复制的mysql作为CDB的从库_第1张图片