原庫：*.*.101.73/74 ???

?? 系統環境: Suse 12.4

?? MySQL: 5.7.29

新庫：*.*.110.46/47

?? 系統環境：CentOS7.7 64位

?? MySQL版本: 5.7.30

[一、數據庫升級遷移場景]

因業務側在*.*.101.73/74 mysql數據庫服務器上部署了java應用程序、Hadoop+Hbase數據庫等大數據環境，導致主機內存突然暴增告急，經雙方排查，發現數據庫進程本身才占用內存8.5%，大部分都是由應用緩存占用了內存。經與局方及業務側溝通，局方敦促業務側將數據庫服務器從73/74服務器遷移到*.*.110.46/47服務器上，我方負責實施數據庫的遷移操作。

[二、遷移采坑問題表現]

本次遷移使用的MySQL自帶的備份工具mysqldump從原庫雙主(*.*.101.73/74)導出數據，通過nfs共享文件系統上傳到資源池新庫雙主(*.*.110.46/47)。

在資源池新庫分別將73、74數據庫的備份文件導入 46、47新庫，并啟動雙主復制進程：

mysql> change master to master_host='*.*.110.46',master_user='repl',master_password='xxxxxx',master_port=3306,master_auto_position=1;

結果報錯如下：

ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log

[三、遷移采坑問題分析過程]

從報錯信息來看，起初以為是執行復制的語句重復制賬號信息有誤，然后核對了repl賬號的口令是正確的，并查看了復制賬號repl的權限信息：

mysql>show grants for ‘repl’@’*.*.110.%’;

結果顯示沒有repl用戶的權限信息記錄。接著查看系統表user中數據信息，竟然沒有導入數據前創建的repl用戶記錄，哦，奇怪。

突然想到，由于我們備份的是原庫中所有表(--all-databases)，導出的dump文件中包含有重新創建表結構的語句，所以馬上在資源池雙主庫新建復制賬號repl：

grant? replication? slave? on *.* to? 'repl'@'*.*.110.%'? identified by? 'xxxxxx';

flush privileges;

然后重新執行復制語句并開啟復制進程依然報剛才的錯。然后就想到此次遷移是從Suse 12.4 ?MySQL-5.7.29 遷移到CentOS7.7 MySQL-5.7.30, 以為是版本不兼容。

接著將資源池46/47的MySQL版本降為 mysql 5.7.29。分別重新導入數據到新庫46/47上，導入數據庫的過程中46服務器導入正常，而發現47庫上通過source導入時非常的慢，每條執行返回10-30秒，當時沒有查具體原因，有可能是網絡卡頓吧。

最后查看原庫74/74的數據庫配置文件，返現沒有開啟GTID全局復制方式(說明，目前這邊項目MySQL數據庫幾乎都使用的基于GTID全局事務復制協議做的同步)，而我執行的復制語句中有“master_auto_position=1”，原來新庫上執行的復制機制跟原庫不一致，這就是剛才開啟復制進程報錯的根本原因。

[四、數據遷移采坑處理]

通過以上分析，我們得知，既然原庫使用的是binlog和pos做的同步，那么我們新庫也同樣按照這個方式來配置復制。其次由于剛才使用mysql內置工具導入數據時很緩慢，所以我們準備采用percona提供的xtrabackup 工具來做數據備份和恢復。

4.1、首先檢查新舊庫上是否有創建備份賬號，結果現實沒有新新建

? create user 'bkuser'@'localhost' identified by 'xxxxxx';

? grant reload,lock tables,replication client,process on *.* to 'bkuser'@'localhost';

? flush privileges;

4.2、原庫上使用xtrabackup備份雙主數據

分別在原庫73/74上使用xtrabackup做全量備份。

73服務器上：

innobackupex --defaults-file=/home/mysql/my_cnf/my.cnf --host=*.*.101.73 --user=bkuser --password=xxxxxx --port=3306 --socket=/app/gzyd/data/mysql/tmp/mysql.sock --no-timestamp /mysqlbackup/73_xtra_base_20200623

74服務器上：

innobackupex --defaults-file=/home/mysql/my_cnf/my.cnf --host=*.*.101.74 --user=bkuser --password=xxxxxx --port=3306 --socket=/app/gzyd/data/mysql/tmp/mysql.sock --no-timestamp /mysqlbackup/74_xtra_base_20200623

4.3、新庫上恢復雙主數據

1)導入數據前記錄binlog文件及同步位置(master_log_pos和master_log_file)

# 46/47庫上執行

mysql> flush table with read lock;

mysql> show master status;

注：記得記錄下master狀態信息，后面執行復制的時候要用到。

mysql> unlock table;

4.4、全量恢復

分別在原庫73/74上使用xtrabackup做全量恢復

1)在46庫上執行恢復操作

innobackupex --defaults-file=/home/mysql/my_cnf/my.cnf? --use-memory=2G --apply-log? /mysqlbackup/73_xtra_base_20200623

mysqladmin? --login-path=myconn shutdown immediate

mv /data/mysql/data /data/mysql/data-bak20200624

mkdir /data/mysql/data

innobackupex --defaults-file=/home/mysql/my_cnf/my.cnf? --copy-back /mysqlbackup/73_xtra_base_20200623

chown -R mysql.mysql?? /data/mysql/data???

mysqld_safe? --defaults-file=/home/mysql/my_cnf/my.cnf? &

2)在47庫上恢復操作同上

4.5、新庫上配置雙主復制

1)在46/47服務器上新建復制賬號

注：由于在原庫導出的是所有庫，備份文件中含有重新創建表結構的語句，所以在新庫恢復數據后需要重新創建復制賬號：

grant? replication? slave? on *.* to? 'repl'@'*.*.110.%'? identified by? 'xxxxxx';

flush privileges;

2)配置46->47方向主從

?登錄47服務器，執行復制語句：

stop slave;?

change master to master_host='*.*.110.46',master_user='repl',master_password='xxxxxx',master_port=3306,master_log_file='bin.000001',master_log_pos=448;

start slave;

show slave status\G;

3)配置47->46方向主從

?登錄46服務器，執行復制語句：

stop slave;

change master to master_host='*.*.110.47',master_user='repl',master_password='repQAv2wsx@gzydxk',master_port=3306,master_log_file='bin.000001',master_log_pos=1066;

start slave;

show slave status\G;??

4.6、新庫雙主測試

1)主主庫46上試著寫入測試數據

mysql> create database chg;

mysql> use chg;

mysql> create table t1(id int, name varchar(30));

mysql> insert into t1(id,name) values(1,'zhangsan');

mysql> insert into t1(id,name) values(2,'lisi');

然后到重復47上查看新插入的兩條數據是否同步過來：

mysql> show databases;

+--------------------+

| Database?????????? |

+--------------------+

| information_schema |

| chg??????????????? |

| mysql????????????? |

| performance_schema |

| smzrz????????????? |

| sys??????????????? |

+--------------------+

6 rows in set (0.00 sec)

mysql> use chg;

mysql> show tables;

+---------------+

| Tables_in_chg |

+---------------+

| t1??????????? |

+---------------+

1 row in set (0.00 sec)

mysql> select? * from t1;

+------+----------+

| id?? | name???? |

+------+----------+

|??? 1 | zhangsan |

|??? 2 | lisi???? |

+------+----------+

2 rows in set (0.00 sec)

2)主主庫46上試著寫入測試數據

mysql> create database chg2;

mysql> use chg2;

mysql> create table t2(id int,name varchar(20));

mysql> insert into t2(id,name) values(1,'derek');

mysql> insert into t2(id,name) values(2,'john');

然后到重復47上查看新插入的兩條數據是否同步過來：

mysql> use chg2;

mysql> show tables;

+----------------+

| Tables_in_chg2 |

+----------------+

| t2???????????? |

+----------------+

1 row in set (0.00 sec)

mysql> select * from t2;

+------+-------+

| id?? | name? |

+------+-------+

|??? 1 | derek |

|??? 2 | john? |

+------+-------+

[五、問題規避]

MySQL數據庫類似的升級遷移操作注意事項：

①升級遷移操作前仔細檢查當前數據庫配置文件(my,cnf)，關注關鍵性的參數配置。

②自此檢查數據庫的架構，如：具體使用哪種復制模式等。

③升級遷移變更前做好充分的數據測試。

總結

以上是生活随笔為你收集整理的centos7恢复mysql数据库_MySQL数据库升级迁移填坑记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。