夢の終着駅

一、问题说明#

我们首先在A库中通过生成了文件，在导入B库时报错：

ERROR 1227 (42000) at line 18: Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation

一言以蔽之，我们的sql文件的第18行存在需要更高权限才能执行的语句。

使用记事本打开sql文件查看第18行：

可以发现这是一个有关GTID的语句。

什么是GTID？ GTID是MySQL自带的一套事务标识机制，当开启GTID模式，每个事务成功提交后都会分配一个全局唯一的ID。 不难发现，GTID是为了简化MySQL主从复制而生的。 传统主从复制依赖binlog文件名和position来标识复制位置，在主从切换或故障恢复时容易出现重复执行或漏执行事务的问题。而基于GTID的复制只需判断某个GTID是否已执行，从而显著降低复制管理的复杂度。

综上可知，GTID只在自动主从复制时能起到效果，对于我们当前使用mysqldump进行手动的时候则可有可无，因为使用逻辑导入的不会直接参与现有的GTID复制链路。

二、#

在生成sql文件时在额外参数中添加—set-gtid-purged=OFF即可。

关于如何使用mysqldump进行数据迁移可以参考以下文章： 记录使用datagrip备份数据库信息-CSDN博客

不过需要注意的一点是，DataGrip在mysqldump界面是默认勾选lock tables选项的：

该选项等同于—lock-all-tables参数，会在生成sql文件的期间会对整个库添加全局读锁，从而阻塞所有的写线程。由于该锁粒度较大且在读写并发的业务场景下，大量写请求被阻塞可能导致连接长期占用，进而使连接池耗尽，新请求无法获取连接，最终表现为MySQL伪宕机。 所以在实际迁移中，请切实考虑是否要勾选该选项，若否则可能会导致迁移空窗期的数据丢失，甚至造成业务逻辑错误的情况。 不过如果可以容忍短期数据丢失且使用的是InnoDB引擎的话更推荐使用—single-transaction方式，这个方式会通过InnoDB的MVCC机制获取当前数据库的一致性快照，不会添加全局读锁，对整体业务影响较小。

码文不易，留个赞再走吧

原文链接: 通过mysqldump进行数据迁移时权限不足的解决方案 作者: Yilena