當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

MySQL-14-备份恢复

發布時間：2023/10/11 数据库 93 如意码农

生活随笔收集整理的這篇文章主要介紹了 MySQL-14-备份恢复小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

備份類型

1 熱備

在業務正常時,對數據庫進行備份數據,并且能夠一致性恢復（只能是innodb）

對業務影響非常小

2 溫備

鎖表備份,只能查詢不能修改（myisam）

影響到寫入操作

3 冷備

關閉數據庫業務,數據庫沒有任何變更的情況下,進行備份數據.

業務停止

常用備份工具

1 邏輯備份工具

基于SQL語句進行備份

mysqldump       *****

mysqlbinlog     *****

2 物理備份工具

基于磁盤數據文件備份

xtrabackup(XBK)：percona 第三方   *****

MySQL Enterprise Backup（MEB）

邏輯備份和物理備份的比較

1 mysqldump (MDP)

優點：

1.不需要下載安裝

2.備份出來的是SQL，文本格式，可讀性高，便于備份處理

3.壓縮比較高，節省備份的磁盤空間

缺點：

依賴于數據庫引擎，需要從磁盤把數據讀出，然后轉換成SQL進行轉儲，比較耗費資源，數據量大的話效率較低

建議：

100G以內的數據量級，可以使用mysqldump

超過1TB以上，我們也可選擇的是mysqldump，配合分布式的系統

1EB = 1024PB = 1000000TB

2 xtrabackup(XBK)

優點：

1.類似于直接cp數據文件，不需要管邏輯結構，相對來說性能較高

缺點：

可讀性差

壓縮比低，需要更多磁盤空間

建議：

數據庫容量 大于100G，小于1TB時，使用xbk備份方式

備份策略

備份方式：

全備:全庫備份，備份所有數據

增量:備份變化的數據

邏輯備份=mysqldump+mysqlbinlog

物理備份=xtrabackup_full+xtrabackup_incr+binlog或者xtrabackup_full+binlog

備份周期:

根據數據量設計備份周期

比如：周日全備，周1-周6增量

mysqldump備份工具

mysqldump (邏輯備份的客戶端工具)

客戶端通用參數

-u  -p   -S   -h  -P

本地備份:

mysqldump -uroot -p  -S /tmp/mysql.sock

遠程備份:

mysqldump -uroot -p  -h 10.0.0.51 -P3306

備份專用基本參數

-A 全備參數

[root@db01 ~]# mkdir -p /data/backup

[root@db01 ~]# mysqldump -uroot -p -A >/data/backup/full.sql

# 補充:建議不用加--set-gtid-purged=OFF

# 1.常規備份是要加 --set-gtid-purged=OFF,解決備份時的警告

# [root@db01 ~]# mysqldump -uroot -p123 -A  --set-gtid-purged=OFF  >/backup/full.sql

# 2.構建主從時,做的備份,不需要加這個參數

# [root@db01 ~]# mysqldump -uroot -p123 -A >/backup/full.sql

-B db1 db2 db3 備份多個單庫

說明：生產中需要備份，生產相關的庫和MySQL庫

[root@db01 ~]# mysqldump -uroot -p  -B mysql gtid >/data/backup/full.sql

備份單個或多個表

world數據庫下的city,country表

[root@db01 ~]# mysqldump -uroot -p world city country >/backup/bak1.sql

以上備份恢復時:必須庫事先存在,并且ues才能source恢復

高級參數應用*****

##特殊參數使用1（必須要加）

-R            備份存儲過程及函數

--triggers  	備份觸發器

-E            備份事件

[root@db01 backup]# mysqldump -uroot -p -A -R -E --triggers >/data/backup/full.sql

##特殊參數使用2

-F 在備份開始時,刷新一個新binlog日志

[root@db01 backup]# mysqldump -uroot -p  -A  -R --triggers -F >/bak/full.sql

##特殊參數使用3

--master-data=2 ***** 這個參數很重要，必須要加

以注釋的形式,保存備份開始時間點的binlog的狀態信息

[root@db01 ~]# mysqldump -uroot -p  -A  -R --triggers --master-data=2 >/back/world.sql

[root@db01 ~]# grep 'CHANGE' /backup/world.sql

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000035', MASTER_LOG_POS=194;

功能：

（1）在備份時，會自動記錄，二進制日志文件名和位置號

     0  默認值

     1  以change master to命令形式，可以用作主從復制

     2  以注釋的形式記錄，備份時刻的文件名+postion號

（2）自動鎖表

（3）如果配合 --single-transaction，只對非InnoDB表進行鎖表備份，InnoDB表進行熱備，實際上是實現快照備份

--single-transaction  這個參數配合上個參數一起使用

innodb存儲引擎開啟熱備(快照備份)功能

master-data可以自動加鎖

（1）在不加--single-transaction，啟動所有表的溫備份，所有表都鎖定

（1）加上--single-transaction，對innodb進行快照備份，對非innodb表可以實現自動鎖表功能

備份必加參數

mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql

##特殊參數使用4

--set-gtid-purged=auto   默認就行，一般不用加這個參數，了解一下

參數: auto, on, off

使用場景:

1. --set-gtid-purged=OFF,可以使用在日常備份參數中.

mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=OFF >/data/backup/full.sql

2. auto, on:在構建主從復制環境時需要的參數配置

mysqldump -uroot -p -A -R -E --triggers --master-data=2  --single-transaction --set-gtid-purged=ON >/data/backup/full.sql

備份小練習

實現所有表的單獨備份

提示：

information_schema.tables

mysqldump -uroot -p123 world city >/backup/world_city.sql

####

select concat("mysqldump -uroot -p123 ",table_schema," ",table_name," --master-data=2 --single-transaction --set-gtid-purged=0  -R -E --triggers>/backup/",table_schema,"_",table_name,".sql") from information_schema.tables where table_schema not in ('sys','information_schema','performance_schema');

壓縮備份并添加時間戳

[root@db01 backup]# mysqldump -uroot -p123 -A  -R  --triggers --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F).sql.gz

[root@db01 backup]# mysqldump -uroot -p123 -A  -R  --triggers --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F-%T).sql.gz

mysqldump備份的恢復方式（在生產中恢復要謹慎，恢復會刪除重復的表）

set sql_log_bin=0;

source /backup/full_2018-06-28.sql

set sql_log_bin=1;

注意：

1、mysqldump在備份和恢復時都需要mysql實例啟動為前提。

2、一般數據量級100G以內，大約15-45分鐘可以恢復，數據量級很大很大的時候（PB、EB）

3、mysqldump是覆蓋形式恢復的方法。

一般我們認為，在同數據量級，物理備份要比邏輯備份速度快.

邏輯備份的優勢:

1、可讀性強

2、壓縮比很高

備份時優化參數

(1) max_allowed_packet   最大的數據包大小

mysqldump -uroot -p123 -A  -R  --triggers --set-gtid-purged=OFF --master-data=2 max_allowed_packet=128M  --single-transaction|gzip > /backup/full_$(date +%F).sql.gz

(2) 增加key_buffer_size  (臨時表有關)

(3) 分庫分表并發備份

(4) 架構分離,分別備份      (架構拆分,分布式備份)

從mysqldump 全備中獲取庫和表的備份

1、獲得表結構

# sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `city`/!d;q'  full.sql>createtable.sql

2、獲得INSERT INTO語句，用于數據的恢復

# grep -i 'INSERT INTO `city`'  full.sqll >data.sql &

3.獲取單庫的備份

# sed -n '/^-- Current Database: `world`/,/^-- Current Database: `/p' all.sql >world.sql

企業故障恢復案例1（可以多參考案例2）

1 背景環境

正在運行的網站系統，mysql-5.7.20數據庫，數據量50G，日業務增量1-5M

2 備份策略

每天23:00點，計劃任務調用mysqldump執行全備腳本

3 故障時間點

年底故障演練:模擬周三上午10點誤刪除數據庫，并進行恢復

4 思路

  4.1、停業務，掛維護頁，避免數據的二次傷害

  4.2、找一個臨時庫，恢復周二23：00全備

  4.3、截取周二23：00 --- 周三10點誤刪除之間的binlog，恢復到臨時庫

  4.4、測試可用性和完整性

  4.5、

    4.5.1 方法一：直接使用臨時庫頂替原生產庫，前端應用割接到新庫

    4.5.2 方法二：將誤刪除的表導出，導入到原生產庫

  4.6、開啟業務

  處理結果：經過20分鐘的處理，最終業務恢復正常

5 故障模擬演練

5.1 準備數據

create database backup;

use backup

create table t1 (id int);

insert into t1 values(1),(2),(3);

commit;

5.2 周二 23：00全備

mysqldump -uroot -p123 -A  -R  --triggers --set-gtid-purged=OFF --master-data=2  --single-transaction|gzip > /backup/full_$(date +%F).sql.gz

5.3 模擬周二 23：00到周三 10點之間數據變化

use backup

insert into t1 values(11),(22),(33);

commit;

create table t2 (id int);

insert into t2 values(11),(22),(33);

5.4 模擬故障,刪除表(只是模擬，不代表生產操作)

drop database backup;

6 恢復過程

6.1 準備臨時數據庫（多實例3307）

systemctl start mysqld3307

6.2 準備備份

（1）準備全備

    cd /backup

    gunzip full_2018-10-17.sql.gz

（2）截取二進制日志

     -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000036', MASTER_LOG_POS=793;

     #mysqlbinlog --skip-gtids --include-gtids='3ca79ab5-3e4d-11e9-a709-000c293b577e:6-7' /data/binlog/mysql-bin.000036 >/backup/bin.sql

6.3 恢復備份到臨時庫

mysql -S /data/3307/mysql.sock

set sql_log_bin=0;

source /backup/full_2018-10-17.sql

source /backup/bin.sql

6.4 將故障表導出并恢復到生產

mysqldump   -S /data/3307/mysql.sock backup t1 >/backup/t1.sql

#mysql -uroot -p123

>set sql_log_bin=0

>use backup

>source /backup/t1.sql;

企業故障恢復案例2

數據準備

利用mysqldump進行全備+binlog

創建數據庫

mysql> create database backup charset utf8mb4;

創建一張表

mysql> use backup;

mysql> create table t1 (id char(255));

寫一個shell腳本模擬業務一直在往表中插入數據

#!/bin/bashIP="10.0.0.51"USER="root"PWD="root123"DBNAME="backup"while true; do    sleep 1    insert_sql="insert into t1 values(`date +%s`)"    mysql -h${IP} -u${USER} -p${PWD} ${DBNAME} -e "${insert_sql};commit"    echo ${insert_sql}done

執行shell腳本，開始往數據庫插入數據

模擬在某個時間點對數據庫進行了全備

[root@db01 backup]# mysqldump -uroot -proot123 -A -R -E -F --triggers --master-data=2 --single-transaction >./full.sql參數解釋：-A						    對整個數據庫實例全備，里面有多少庫備份多少庫-R						    備份存儲過程和函數-E						    備份事件--triggers			  備份觸發器--master-data=2		記錄備份時刻的binlog信息，自動鎖表。不加--single-transaction ,溫備份。加了--single-transaction對于InnoDB表不鎖表備份(快照備份)--single-transaction  對于InnoDB的表,進行一致性快照備份,不鎖表.-F						    在備份開始時,刷新一個新binlog日志

模擬故障

全備完成以后，等幾分鐘，這時候又插入了新的數據。模擬數據庫出現故障，這里直接drop t1表mysql> drop table t1;

恢復

此時看到一直插入數據的腳本報錯了，代表業務出錯了

這里的數值是1576220628。待會恢復數據后最后一條數據要是這個1576220628，另外由于是快照備份，不鎖表。所以應該是每秒插入1條數據

找到最近的全備，這里是在 /backup/full.sql

[root@db01 backup]# ll

total 51088

-rw-r--r-- 1 root root 52313239 Dec 13 15:02 full.sql

[root@db01 backup]# pwd

/backup

把全備恢復到測試庫中。注意不要直接恢復到生產庫

mysql> show databases;

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

| Database           |

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

| information_schema |

| mysql              |

| performance_schema |

| sys                |

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

4 rows in set (0.04 sec)

# 恢復全備

mysql> set sql_log_bin=0;			# 臨時關閉二進制日志記錄，避免恢復的時候，記錄了大量的二進制日志

mysql> source /backup/full.sql;

mysql> set sql_log_bin=1;

查看全備full.sql中正在使用的binlog文件是哪個，以及POS開始號（這里直接用POS號恢復了，沒用gtid）

-- CHANGE MASTER TO MASTER_LOG_FILE

# POS開始號

[root@db01 backup]# head -30 full.sql |grep "CHANGE MASTER TO MASTER_LOG_FILE"

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000014', MASTER_LOG_POS=194;

# POS結束號 直接查看DROP前10行

[root@db01 backup]# mysqlbinlog /data/mysql/binlog/mysql-bin.000014 |grep -B10 "DROP"

# at 29266

#191213 15:03:48 server id 6  end_log_pos 29297 CRC32 0x4d4926e4 	Xid = 6272

COMMIT/*!*/;

# at 29297

#191213 15:03:48 server id 6  end_log_pos 29362 CRC32 0x25b456a0 	GTID	last_committed=109	sequence_number=110	rbr_only=no

SET @@SESSION.GTID_NEXT= 'a4b648cb-11b8-11ea-8636-000c2990cef0:1196'/*!*/;

# at 29362

#191213 15:03:48 server id 6  end_log_pos 29481 CRC32 0x910720d6 	Query	thread_id=20	exec_time=1	error_code=0

use `backup`/*!*/;

SET TIMESTAMP=1576220628/*!*/;

DROP TABLE `t1` /* generated by server */

截取二進制日志。如果二進制文件過大也可以直接用grep過濾

[root@db01 backup]# mysqlbinlog --skip-gtids --start-position=194 --stop-position=29297 /data/mysql/binlog/mysql-bin.000014 >./binlog.sql

恢復二進制日志的數據

mysql> use backup;

mysql> set sql_log_bin=0;

mysql> source /backup/binlog.sql;

mysql> set sql_log_bin=1;

驗證數據這里最后一條數據是1576220628。剛好和業務中斷之前的對上，數據完美恢復

mysql> select * from t1 order by id desc limit 2;

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

| id         |

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

| 1576220628 |

| 1576220627 |

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

10 rows in set (0.00 sec)

導出該表

[root@db01 backup]# mysqldump -S /data/3308/mysql.sock  -R -E -F --triggers --master-data=2 --single-transaction backup t1 >./t1.sql

在生產中恢復該表

mysql> use backup;

mysql> source /backup/t1.sql;

mysql> select * from t1 order by id desc limit 5;

xtrabackup備份工具(XBK、Xbackup)

安裝

1 安裝依賴包：

wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo

yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL libev

2 下載軟件并安裝

wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.12/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm

https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/6/x86_64/percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm

yum -y install percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

常用備份命令

xtrabackup

innobackupex    ******

備份方式（物理備份）

（1）對于非Innodb表（比如 myisam）是，鎖表cp數據文件，屬于一種溫備份。

（2）對于Innodb的表（支持事務的），不鎖表，拷貝數據頁，最終以數據文件的方式保存下來，把一部分redo和undo一并備走，屬于熱備方式。

題：xbk 在innodb表備份恢復的流程

  0、xbk備份執行的瞬間,立即觸發Checkpoint,已提交的數據臟頁,從內存刷寫到磁盤,并記錄此時的LSN號

  1、備份時，拷貝磁盤數據頁，并且記錄備份過程中產生的redo和undo一起拷貝走,也就是checkpoint LSN之后的日志

  2、在恢復之前，模擬Innodb“自動故障恢復”的過程，將redo（前滾）與undo（回滾）進行應用

  3、恢復過程是cp 備份到原來數據目錄下

innobackupex使用

全備

[root@db01 backup]# innobackupex --user=root --password=123  /data/backup

自主定制備份路徑名

[root@db01 backup]# innobackupex --user=root --password=123 --no-timestamp /data/backup/full

備份集中多出來的文件：

-rw-r----- 1 root root       24 Jun 29 09:59 xtrabackup_binlog_info

-rw-r----- 1 root root      119 Jun 29 09:59 xtrabackup_checkpoints

-rw-r----- 1 root root      489 Jun 29 09:59 xtrabackup_info

-rw-r----- 1 root root     2560 Jun 29 09:59 xtrabackup_logfile

xtrabackup_binlog_info ：（備份時刻的binlog位置）

[root@db01 full]# cat xtrabackup_binlog_info

mysql-bin.000003    536749

79de40d3-5ff3-11e9-804a-000c2928f5dd:1-7

記錄的是備份時刻，binlog的文件名字和當時的結束的position，可以用來作為截取binlog時的起點。

xtrabackup_checkpoints ：

backup_type = full-backuped

from_lsn = 0            上次所到達的LSN號(對于全備就是從0開始,對于增量有別的顯示方法)

to_lsn = 160683027      備份開始時間(ckpt)點數據頁的LSN

last_lsn = 160683036    備份結束后，redo日志最終的LSN。注意最終的last_lsn號要比to_lsn大9

compact = 0

recover_binlog_info = 0

（1）備份時刻，立即將已經commit過的，內存中的數據頁刷新到磁盤(CKPT).開始備份數據，數據文件的LSN會停留在to_lsn位置。

（2）備份時刻有可能會有其他的數據寫入，已備走的數據文件就不會再發生變化了。

（3）在備份過程中，備份軟件會一直監控著redo的undo，如果一旦有變化會將日志也一并備走，并記錄LSN到last_lsn。

從to_lsn  ----》last_lsn 就是，備份過程中產生的數據變化

全備的恢復

準備備份（Prepared）

將redo進行重做，已提交的寫到數據文件，未提交的使用undo回滾掉。模擬了CSR的過程

[root@db01 ~]# innobackupex --apply-log  /backup/full

恢復備份

前提：

1、被恢復的目錄是空

2、被恢復的數據庫的實例是關閉

systemctl stop mysqld

創建新目錄

[root@db01 backup]# mkdir /data/mysql1

數據授權

chown -R mysql.mysql /data/mysql1

恢復備份

[root@db01 full]# cp -a /backup/full/* /data/mysql1/

啟動數據庫

vim /etc/my.cnf

datadir=/data/mysql1

[root@db01 mysql1]# chown -R mysql.mysql /data/mysql1

systemctl start mysqld

innobackupex 增量備份(incremental)

（1）增量備份的方式，是基于上一次備份進行增量。

（2）增量備份無法單獨恢復。必須基于全備進行恢復。

（3）所有增量必須要按順序合并到全備中。

增量備份命令

（1）刪掉原來備份

略.

（2）全備（周日）

[root@db01 backup]# innobackupex --user=root --password --no-timestamp /backup/full >&/tmp/xbk_full.log

（3）模擬周一數據變化

db01 [(none)]>create database cs charset utf8;

db01 [(none)]>use cs

db01 [cs]>create table t1 (id int);

db01 [cs]>insert into t1 values(1),(2),(3);

db01 [cs]>commit;

（4）第一次增量備份（周一）

[root@db01 backup]# innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/backup/full  /backup/inc1 &>/tmp/inc1.log

（5）模擬周二數據

db01 [cs]>create table t2 (id int);

db01 [cs]>insert into t2 values(1),(2),(3);

db01 [cs]>commit;

（6）周二增量

 [root@db01 backup]# innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/backup/inc1  /backup/inc2  &>/tmp/inc2.log

（7）模擬周三數據變化

db01 [cs]>create table t3 (id int);

db01 [cs]>insert into t3 values(1),(2),(3);

db01 [cs]>commit;

db01 [cs]>drop database cs;

恢復到周三誤drop之前的數據狀態

恢復思路：

1.  掛出維護頁，停止當天的自動備份腳本

2.  檢查備份：周日full+周一inc1+周二inc2，周三的完整二進制日志

3. 進行備份整理（細節），截取關鍵的二進制日志（從備份——誤刪除之前）

4. 測試庫進行備份恢復及日志恢復

5. 應用進行測試無誤，開啟業務

6. 此次工作的總結

恢復過程

1. 檢查備份

1afe8136-601d-11e9-9022-000c2928f5dd:7-9

2. 備份整理（apply-log）+合并備份（full+inc1+inc2）

(1) 全備的整理

注意這里是要 --redo-only 參數的。需要模擬innodb引擎數據自動恢復

[root@db01 one]# innobackupex --apply-log --redo-only /data/backup/full

(2) 合并inc1到full中

[root@db01 one]# innobackupex --apply-log --redo-only --incremental-dir=/data/backup/inc1 /data/backup/full

(3) 合并inc2到full中

[root@db01 one]# innobackupex --apply-log  --incremental-dir=/data/backup/inc2 /data/backup/full

(4) 最后一次整理全備 這里不需要 --redo-only 參數

[root@db01 backup]#  innobackupex --apply-log  /data/backup/full

3. 截取周二 23:00 到drop 之前的 binlog

[root@db01 inc2]# mysqlbinlog --skip-gtids --include-gtids='1afe8136-601d-11e9-9022-000c2928f5dd:7-9' /data/binlog/mysql-bin.000009 >/data/backup/binlog.sql

4. 進行恢復

[root@db01 backup]# mkdir /data/mysql/data2 -p

[root@db01 full]# cp -a * /data/mysql/data2

[root@db01 backup]# chown -R mysql.  /data/*

[root@db01 backup]# systemctl stop mysqld

vim /etc/my.cnf

datadir=/data/mysql/data2

systemctl start mysqld

Master [(none)]>set sql_log_bin=0;

Master [(none)]>source /data/backup/binlog.sql

Master [(none)]>set sql_log_bin=1;

備份集中單獨恢復表

思考:在之前的項目案例中,如果誤刪除的表只有10M,而備份有500G,該如何快速恢復誤刪除表?

拷貝表相關的文件，然后CP到生產環境

提示：

drop table city;

create table city like city_bak;

alter table city discard tablespace;

cp /backup/full/world/city.ibd  /application/mysql/data/world/

chown -R mysql.mysql  /application/mysql/data/world/city.ibd

alter table city import  tablespace;

mysql升級遷移

遷移(5.6.44  --->  5.7.26)

1 搭建5.6的測試環境

(1)創建必須的目錄

[root@oldboyedu ~]# mkdir /data/mysql/data  -p

[root@oldboyedu ~]# mkdir /application/ -p

[root@oldboyedu ~]# mkdir /data/binlog -p

上傳軟件至 /application 下并解壓

(2) 建用戶,改權限

[root@oldboyedu ~]# useradd mysql

[root@oldboyedu ~]# chown -R mysql. /data/application/

(3) 修改環境變量

vim /etc/profile

export PATH=/application/mysql/bin:$PATH

source /etc/profile

(4)數據初始化

[root@oldboyedu ~]# yum remove mariadb-libs

[root@oldboyedu ~]# yum install -y libaio-devel

[root@oldboyedu ~]# \rm -rf /data/mysql/data/*

[root@oldboyedu ~]# /application/mysql/scripts/mysql_install_db --user=mysql --basedir=/application/mysql --datadir=/data/mysql/data

(5) 準備配置文件和啟動腳本

cat > /etc/my.cnf <<EOF

[mysqld]

basedir=/application/mysql

datadir=/data/mysql/data

server_id=99

user=mysql

log_bin=/data/binlog/mysql-bin

binlog_format=row

socket=/tmp/mysql.sock

[mysql]

socket=/tmp/mysql.sock

EOF

[root@oldboyedu data]# cp  /application/mysql/support-files/mysql.server /etc/init.d/mysqld

(6) 啟動數據庫

[root@oldboyedu data]# /etc/init.d/mysqld start

[root@oldboyedu data]# mysqladmin -uroot -p password 123

2 遷移5.6 數據到 5.7  (擴展)

(1) 5.6 數據庫備份

[root@oldboyedu ~]# mysqldump -uroot -p123 -A --master-data=2 --single-transaction -R -E --triggers >/tmp/full.sql

[root@oldboyedu ~]# scp /tmp/full.sql 10.0.0.51:/data/3308

(2)準備5.7數據庫

[root@db01 /]# systemctl start mysqld3308

[root@db01 /]# mysql -S /data/3308/mysql.sock

mysql> source /data/3308/full.sql

[root@db01 /]# mysql_upgrade  -uroot -p123 -S /data/3308/mysql.sock

(3) binlog的持續追加

(4) 停業務,恢復剩余的binlog

(5) 業務割接

總結

以上是生活随笔為你收集整理的MySQL-14-备份恢复的全部內容，希望文章能夠幫你解決所遇到的問題。

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

备份
MySQL

上一篇： APMServ升级PHP至5.3
下一篇： C++Builder 也有StringB