MySQL数据库升级迁移填坑记

本文将分享一个近期在升级迁移MySQL数据库过程中遇到的问题和采取的解决方案。由于业务侧部署了大量应用程序和大数据环境，原数据库服务器内存不足，迫切需要将数据库迁移到新服务器上。具体操作过程中，我们遇到了如下几个问题。

MySQL数据库升级迁移填坑记

迁移采坑问题表现

本次迁移使用MySQL自带的备份工具mysqldump从原库双主(*.*.101.73/74)导出数据，通过nfs共享文件系统上传到资源池新库双主(*.*.110.46/47)。在资源池新库分别将73、74数据库的备份文件导入46、47新库，并启动双主复制进程。结果报错如下：ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log。

迁移采坑问题分析过程

从报错信息来看，起初以为是执行复制的语句重复制账户信息有误，核对了repl账号的口令是正确的，并查看了复制账号repl的权限信息，结果显示没有repl用户的权限信息记录。接着查看系统表user中数据信息，竟然没有导入数据前创建的repl用户记录，奇怪。突然想到备份的是原库中所有表(–all-databases)，导出的dump文件中包含有重新创建表结构的语句，所以在资源池双主库新建复制账号repl后，重新执行复制语句并开启复制进程，仍然报刚才的错。然后想到此次迁移是从Suse12.4 MySQL-5.7.29迁移到CentOS7.7 MySQL-5.7.30，以为是版本不兼容。将资源池46/47的MySQL版本降为mysql5.7.29，重新导入数据到新库46/47上，此时导入数据库过程中47服务器导入速度非常慢，每条执行返回10-30秒。最后查看原库74/74的数据库配置文件，返现没有开启GTID全局复制方式，而我执行的复制语句中有”master_auto_position=1″，原来新库上执行的复制机制跟原库不一致，这就是上面复制进程报错的根本原因。

数据迁移采坑处理

通过以上分析，我们得知既然原库使用的是binlog和pos做的同步，那么我们新库也同样按照这个方式来配置复制。其次由于刚才使用MySQL自带工具导入数据时很缓慢，我们准备采用Percona提供的xtrabackup工具来做数据备份和恢复。首先检查新旧库上是否有创建备份账号。原库上使用xtrabackup备份双主数据分别在原库73/74上使用xtrabackup做全量备份。全量恢复分别在46/47服务器上执行，然后配置双主复制。

以上就是在MySQL数据库升级迁移过程中遇到的问题和解决方案的分享。在进行任何数据库升级迁移操作前，务必充分测试，仔细检查参数配置和数据库架构，以免遇到类似的问题。

原创文章，作者：小编小本本，如若转载，请注明出处：https://www.benjiyun.com/yunzhujiyunwei/vps-yunwei/5842.html