如何用mysql命令备份和恢复

Posted 2023-05-03

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了如何用mysql命令备份和恢复相关的知识，希望对你有一定的参考价值。

参考技术A mysql数据库备份和还原常用的命令是进行Mysql数据库备份和还原的关键，没有命令，什么都无从做起，更谈不上什么备份还原，只有给系统这个命令，让它去执行，才能完成Mysql数据库备份和还原的操作，下面为大家分享一下操作的常用的命令。
一、备份命令
1、备份MySQL数据库的命令
　　mysqldump-hhostname-uusername-ppassword databasename>backupfile.sql
2、备份MySQL数据库为带删除表的格式
备份MySQL数据库为带删除表的格式，能够让该备份覆盖已有数据库而不需要手动删除原有数据库。
　　mysqldump-–add-drop-table-uusername-ppassword databasename>backupfile.sql
3、直接将MySQL数据库压缩备份
　　mysqldump-hhostname-uusername-ppassword databasename|gzip>backupfile.sql.gz
4、备份MySQL数据库某个(些)表
　　mysqldump-hhostname-uusername-ppassword databasename specific_table1 specific_table2>backupfile.sql
5、同时备份多个MySQL数据库
　　mysqldump-hhostname-uusername-ppassword –databases databasename1 databasename2 databasename3>multibackupfile.sql
6、仅仅备份数据库结构
　　mysqldump –no-data –databases databasename1 databasename2 databasename3>structurebackupfile.sql
7、备份服务器上所有数据库
　　mysqldump –all-databases>allbackupfile.sql
二、还原命令
1、还原MySQL数据库的命令
　　mysql-hhostname-uusername-ppassword databasename<backupfile.sql
2、还原压缩的MySQL数据库
　　gunzip<backupfile.sql.gz|mysql-uusername-ppassword databasename
3、将数据库转移到新服务器
　　mysqldump-uusername-ppassword databasename|mysql –host=*.*.*.*-C databasename
总结
做好数据备份和还原，定好合适的备份策略，这是一个DBA所做事情的一小部分，万事开头难，就从现在开始吧!本回答被提问者和网友采纳参考技术B

前言

MySQL 5.6引入了GTID，每个事务都会产生一个GTID，我们可以通过验证主从GTID来验证主从数据的一致性。

为了叙述简便，定义一个量ALL_GTID: 表示某个数据库实例上所有存在过的或将要存在的事务的GTID（包括已经被purge掉的事务）。

在讨论数据库可用性的场景中, 当发生主备切换时, 需要进行数据补偿。通过比较主备的ALL_GTID，可以确定需要补偿多少数据:

在实例存活的情况，可以在实例状态中查询ALL_GTID。

在实例崩溃的情况，无法在实例状态中查询ALL_GTID。可以通过查询BINLOG中的Previous-GTIDs计算来获得ALL_GTID。

下面列举与ALL_GTID相关的变量。

与ALL_GTID相关的变量

Previous-GTIDs

Previous-GTIDs格式如下（环境为MySQL5.7，日志手动flush binary logs获得）：

查看新轮转出的BINLOG：

下面为mysql-bin.00001中包含的GTID：

请点击输入图片描述

然后再次flush binary logs:

请点击输入图片描述

mysql-bin.00002中是没有任何GTID的。

请点击输入图片描述

综上Previous-GTIDs是本身这个BINLOG文件前面的所有BINLOG的集合。

请点击输入图片描述

全局变量中的GTID相关的变量

请点击输入图片描述

变量解释:

gtid_executed 代表着server上所有事务执行产生的GTID（包含已经被purge的BINLOG中的GTID或者是手动set gtid_purged的GTID）。

gtid_purged 代表着已经被purge到的GTID。gtid_purged是gtid_executed的子集。

gtid_retrieved 是从机上relay_log中的GTID。

ALL_GTID 的计算

了解了GTID相关的变量之后，可以得到获得实例的All_GTID的集合的方法：

对象

方法

存活的Master实例 gtid_executed

存活的Slave实例 gtid_executed和gtid_retrieved的并集

非存活Master实例最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID

非存活Slave实例最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID

在获得非存活实例中的ALL_GTID时，最后一个BINLOG文件中的GTID可能不连续(比如事务同时来自于本实例客户端和复制回放)，所以需要扫描最后一个BINLOG文件。

生产中我们使用Xtrabackup来产生一个从实例的流程如下：

拉取备份，进行还原

change master to

set @@global.gtid_purged='xxx';

set @@global.gtid_purged='xxx'; 的影响:

将从实例的ALL_GTID手工置为xxx, 在通过GTID方式建立复制时不会出错.

将更新Binlog中记录的Previous-GTIDs (由于Binlog不可改变, 将产生新的Binlog, 记录新的Previous-GTIDs).

MySQL 5.7中set gtid_purged的行为变更

问题描述

回顾一下备份恢复的流程:

拉取备份，进行还原

change master to

set @@global.gtid_purged='xxx';

现象: 发现有一台MySQL 5.7的Slave服务器恢复后没有产生正确的Previous-GTIDs。

分析

分析整个过程，解决问题应该分阶段进行手动模拟发现问题。以下为详细步骤：

手工还原备份

环境

BINLOG数量，Previous-GTIDs状态

Xtrabackup 2.4.2 & MySQL 5.6 1，空

Xtrabackup 2.4.2 & MySQL 5.7 1，空

Xtrabackup 2.2.9 & MySQL 5.6 1，空

Xtrabackup 2.2.9 & MySQL 5.7 1，空

可见: 恢复过程不会轮转BINLOG。

验证change master和set gtid_purged在不同的MySQL版本中执行的差异

环境

BINLOG数量，Previous-GTIDs状态

change master & MySQL 5.6 1，空

change master & MySQL 5.7 1，空

set gtid_purged & MySQL 5.6 2，正常

set gtid_purged & MySQL 5.7 1，空

可见: 执行set gtid_purged时不同版本的MySQL产生了差异

验证

对不同版本MySQL单独执行set @@global.gtid_purged='';语句。检查结果

环境

进行的操作

BINLOG数量，Previous-GTIDs状态

MySQL 5.7 reset master; set @@global.gtid_purged=”; 1，空

MySQL 5.6 reset master; set @@global.gtid_purged=”; 2，正常

结论

参考: http://bugs.mysql.com/bug.php?id=75767

官方解释: 在5.7版本中，执行SET GTID_PURGED语句后binlog_simple_gtid_recovery会给GTID_PURGED计算出一个错误的值。

由于5.7中新增了存储GTID的表。所以5.7版本中set @@global.gtid_purged='';语句被改成只修改存放GTID的表。

而5.6版本中会进行BINLOG轮转和向Previous_gtids_log_event中添加GTID。如果5.7需要产生和5.6相同结果的话，可以在SET GTID_PURGED语句后手动执行flush binary logs语句。

如何进行数据库备份和恢复 mysql

MySQL备份和还原,都是利用mysqldump、mysql和source命令来完成的。
1.Win32下MySQL的备份与还原
1.1 备份
开始菜单 | 运行 | cmd |利用“cd /Program Files/MySQL/MySQL Server 5.0/bin”命令进入bin文件夹 | 利用“mysqldump -u 用户名 -p databasename >exportfilename”导出数据库到文件，如mysqldump -u root -p voice>voice.sql，然后输入密码即可开始导出。

1.2 还原
进入MySQL Command Line Client，输入密码，进入到“mysql>”，输入命令"show databases；"，回车，看看有些什么数据库；建立你要还原的数据库，输入"create database voice；"，回车；切换到刚建立的数据库，输入"use voice；"，回车；导入数据，输入"source voice.sql；"，回车，开始导入，再次出现"mysql>"并且没有提示错误即还原成功。

2.Linux下MySQL的备份与还原
2.1 备份
[root@localhost ~]# cd /var/lib/mysql (进入到MySQL库目录，根据自己的MySQL的安装情况调整目录)
[root@localhost mysql]# mysqldump -u root -p voice>voice.sql，输入密码即可。
2.2 还原
法一：
[root@localhost ~]# mysql -u root -p 回车，输入密码，进入MySQL的控制台"mysql>"，同1.2还原。
法二：
[root@localhost ~]# cd /var/lib/mysql (进入到MySQL库目录，根据自己的MySQL的安装情况调整目录)
[root@localhost mysql]# mysql -u root -p voice<voice.sql，输入密码即可。参考技术A

前言

MySQL 5.6引入了GTID，每个事务都会产生一个GTID，我们可以通过验证主从GTID来验证主从数据的一致性。

为了叙述简便，定义一个量ALL_GTID: 表示某个数据库实例上所有存在过的或将要存在的事务的GTID（包括已经被purge掉的事务）。

在讨论数据库可用性的场景中, 当发生主备切换时, 需要进行数据补偿。通过比较主备的ALL_GTID，可以确定需要补偿多少数据:

在实例存活的情况，可以在实例状态中查询ALL_GTID。

在实例崩溃的情况，无法在实例状态中查询ALL_GTID。可以通过查询BINLOG中的Previous-GTIDs计算来获得ALL_GTID。

下面列举与ALL_GTID相关的变量。

与ALL_GTID相关的变量

Previous-GTIDs

Previous-GTIDs格式如下（环境为MySQL5.7，日志手动flush binary logs获得）：

查看新轮转出的BINLOG：

下面为mysql-bin.00001中包含的GTID：

请点击输入图片描述

然后再次flush binary logs:

请点击输入图片描述

mysql-bin.00002中是没有任何GTID的。

请点击输入图片描述

综上Previous-GTIDs是本身这个BINLOG文件前面的所有BINLOG的集合。

请点击输入图片描述

全局变量中的GTID相关的变量

请点击输入图片描述

变量解释:

gtid_executed 代表着server上所有事务执行产生的GTID（包含已经被purge的BINLOG中的GTID或者是手动set gtid_purged的GTID）。

gtid_purged 代表着已经被purge到的GTID。gtid_purged是gtid_executed的子集。

gtid_retrieved 是从机上relay_log中的GTID。

ALL_GTID 的计算

了解了GTID相关的变量之后，可以得到获得实例的All_GTID的集合的方法：

对象

方法

存活的Master实例 gtid_executed

存活的Slave实例 gtid_executed和gtid_retrieved的并集

非存活Master实例最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID

非存活Slave实例最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID

生产中我们使用Xtrabackup来产生一个从实例的流程如下：

拉取备份，进行还原

change master to

set @@global.gtid_purged='xxx';

set @@global.gtid_purged='xxx'; 的影响:

将从实例的ALL_GTID手工置为xxx, 在通过GTID方式建立复制时不会出错.

将更新Binlog中记录的Previous-GTIDs (由于Binlog不可改变, 将产生新的Binlog, 记录新的Previous-GTIDs).

MySQL 5.7中set gtid_purged的行为变更

问题描述

回顾一下备份恢复的流程:

拉取备份，进行还原

change master to

set @@global.gtid_purged='xxx';

现象: 发现有一台MySQL 5.7的Slave服务器恢复后没有产生正确的Previous-GTIDs。

分析

分析整个过程，解决问题应该分阶段进行手动模拟发现问题。以下为详细步骤：

手工还原备份

环境

BINLOG数量，Previous-GTIDs状态

Xtrabackup 2.4.2 & MySQL 5.6 1，空

Xtrabackup 2.4.2 & MySQL 5.7 1，空

Xtrabackup 2.2.9 & MySQL 5.6 1，空

Xtrabackup 2.2.9 & MySQL 5.7 1，空

可见: 恢复过程不会轮转BINLOG。

验证change master和set gtid_purged在不同的MySQL版本中执行的差异

环境

BINLOG数量，Previous-GTIDs状态

change master & MySQL 5.6 1，空

change master & MySQL 5.7 1，空

set gtid_purged & MySQL 5.6 2，正常

set gtid_purged & MySQL 5.7 1，空

可见: 执行set gtid_purged时不同版本的MySQL产生了差异

验证

对不同版本MySQL单独执行set @@global.gtid_purged='';语句。检查结果

环境

进行的操作

BINLOG数量，Previous-GTIDs状态

MySQL 5.7 reset master; set @@global.gtid_purged=”; 1，空

MySQL 5.6 reset master; set @@global.gtid_purged=”; 2，正常

结论

参考: http://bugs.mysql.com/bug.php?id=75767

官方解释: 在5.7版本中，执行SET GTID_PURGED语句后binlog_simple_gtid_recovery会给GTID_PURGED计算出一个错误的值。

由于5.7中新增了存储GTID的表。所以5.7版本中set @@global.gtid_purged='';语句被改成只修改存放GTID的表。

以上是关于如何用mysql命令备份和恢复的主要内容，如果未能解决你的问题，请参考以下文章

mysql mysqldump如何用