最近接到一个业务自行运维的MySQL库迁移至标准化环境的需求,库不大,迁移方式也很简单,由开发用myqldump导出数据、DBA导入,但迁移过程坎坷十足,记录一下遇到的各项报错及后续迁移注意事项。
一、 概要
- 空间问题
- 源与目标库版本
- 脚本乱码(尤其是跨平台传输后)
- MySQL远程表
- DEFINER问题
- 字符集与排序规则
- 导入命令
- 权限问题
二、 问题详情
1. 空间问题
确保目标库空间不小于源库,尤其是在进行了多轮导入测试后,会生成大量binlog,可能导致空间不足,报错 The table xxx is full。
2. 源与目标库版本
一般来说要求源与目标库版本一致,若不一致需业务提前验证兼容性,避免迁移后连接报错。
迁移后应用启动报错 Could not retrieve transation read-only status server,查询资料发现与目标库版本有关:MySQL数据库服务为8.0.22,而在项目开发的过程中使用了低版本的MySQL驱动包
Could not retrieve transation read-only status server 的解决办法-CSDN博客
3. 脚本乱码
主要是Windows与Linux互传文件时,换行符可能被识别为乱码,需要替换处理
Linux、Windows、Mac换行符相互转换方法_windows换行符转linux-CSDN博客
4. MySQL远程表
导入后发现两张表数据为空,查看定义发现为MySQL远程表,需修改表定义语句
CONNECTION='mysql://目标库用户名:密码@ip:端口/目标库名/目标表名'
5. DEFINER问题
源端导出的视图、存储过程等可能带有DEFINER信息。若目标库不存在对应用户,会导致创建及查询报错。
导入报错
查询报错
可能直接报 Access denied for user test_read@'%',也可能报
查看DEFINER设置
cat pexetech.sql |grep DEFINER
替换为目标库DEFINER
sed -i 's/`root`@`%`/`app_rw`@`10.%`/g' pexetech.sql
6. 字符集与排序规则
导入报错
源库
目标库
由于utf8与utf8mb4对应字符长度不同,导致导入时报错字段太长。若为其他不兼容字符集,还可能导致乱码。
**解决方法:**使用与源库相同的字符集与排序规则。在本例中由于导出语句自带了字符集及排序规则,DBA不进行初始DB创建,直接使用脚本导入即可。
7. 导入命令
建议使用 mysql -uroot -p < pexetech.sql 方式,报错时可自动停止并显示报错语句
不建议使用 source pexetech.sql,在导入语句过多时会快速刷屏,且不会显示报错语句
8. 权限问题
确认目标库业务账号除标准权限外是否还需额外权限,避免报错。
例如本例中业务用户除标准权限外,应用还需要mysql.help_topic的读取权限,需要单独授予。
参考:
《乱码的前世今生 ------ 字符集和比较规则》