处理方式：
第二段：问题原因我们先来看下为啥会出现这个报错,那就得说下 MySQL 中一个很特别的权限控制机制,像视图、函数、存储过程、触发器等这些数据对象会存在一个?DEFINER?和一个?SQL SECURITY?的属性,如下所示：
--视图定义CREATE?ALGORITHM?=?UNDEFINED?DEFINER?=?+root+@+%+?SQL?SECURITY?DEFINER?VIEW?v_test
--函数定义CREATE?DEFINER=+root+@+%+?FUNCTION?+f_test()+?RETURNS?varchar(100)?SQL?SECURITY?DEFINER
--存储过程定义CREATE?DEFINER=+root+@+%+?PROCEDURE?+p_test+()?SQL?SECURITY?DEFINER
--触发器定义CREATE DEFINER=+root+@+%+ trigger t_test
--事件定义CREATE DEFINER=+root+@+%+ EVENT +e_test+
DEFINER：对象定义者,在创建对象时可以手动指定用户,不指定的话默认为当前连接用户；
SQL SECURITY：指明以谁的权限来执行该对象,有两个选项,一个为?DEFINER,一个为?INVOKER,默认情况下系统指定为 DEFINER；DEFINER：表示按定义者的权限来执行；?INVOKER：表示按调用者的权限来执行.
如果从库上表 t 数据与主库不一致,导致复制错误,整个库的数据量很大,重做从库很慢,如何单独恢复这张表的数据?通常认为是不能修复单表数据的,因为涉及到各表状态不一致的问题.下面就列举备份单表恢复到从库会面临的问题以及解决办法：
场景 1
如果复制报错后,没有使用跳过错误、复制过滤等方法修复主从复制.主库数据一直在更新,从库数据停滞在报错状态（假设 GTID 为 aaaa:1-100）.
修复步骤：
在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000）；
恢复到从库；
启动复制.
这里的问题是复制起始位点是 aaaa:101,从库上表 t 的数据状态是领先其他表的.aaaa:101-10000 这些事务中只要有修改表 t 数据的事务,就会导致复制报错 ,比如主键冲突、记录不存在（而 aaaa:101 这个之前复制报错的事务必定是修改表 t 的事务）
解决办法：启动复制时跳过 aaaa:101-10000 这些事务中修改表 t 的事务.
正确的修复步骤：
① 在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000）,恢复到从库；
CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db_name.t');
START SLAVE UNTIL SQL_AFTER_GTIDS = 'aaaa:10000';
如果复制报错后,使用跳过错误、复制过滤等办法修复了主从复制.主、从库数据一直在更新.
在主库上备份表 t （假设备份快照 GTID为 aaaa:1-10000）；
恢复表 t 到从库；
正确修复步骤：
对表 t 加读锁；
在主库上备份表 t；
停止从库复制,恢复表 t；
启动复制；
解锁表 t.
如果是大表,这里可以用可传输表空间方式备份、恢复表,减少锁表时间.
我知道的
有四种方法.
①.、全备份,可以直接把
data目录下该数据库目录直接打包保存.
保存成sql文件.
以上就是土嘎嘎小编为大家整理的mysql怎么拷贝数据库相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！