Question

mysql在dos命令下备份还原数据库

在CMD下输入c:\>mysql -h localhost -u root -p，输入密码，进入mysql>
在mysql>状态下，备份和还原数据库的命令正确书写格式是什么？备份到那个目录？
mysql>mysqldump -u root -p dbcurr> 20090219.sql； 这么写提示不对。

Answer 1

mysql>mysqldump -u root -p dbcurr> 20090219.sql；
上面这个是你写的，-p后面是密码还是数据库的名字，如果是数据库的名字，那么你没有指定备份到哪个目录里面自然报错
举例
mysql>mysqldump -uroot -p密码 dbcurr > /root/20090219.sql；

追问

举例
mysql>mysqldump -uroot -p密码 dbcurr > /root/20090219.sql；
/root/20090219.sql前边没有盘符啊还是不知道备份到哪里啊，是不是该这样:d:/root/20090219.sql

追答

是的，加上路径就行了，这个随意
我没有加盘符是因为我的是linux系统的

Answer 2

mysqldump不是mysql查询语言不能在mysql> 下面执行。
mysqldump【导出】 应该为一种dos命令【在成功安装来mysql的电脑上】，所以你在mysql\bin目录执行即可 如：........mysql\bin\ mysqldump -u root -p dbcurr> d:\20090219.sql

追问

你是说在：开始，cmd，c:/盘下运行mysql\bin\ mysqldump -u root -p dbcurr> d:\20090219.sql还是在mysql安装盘符下，比如d:盘。
或者是在dos下进入mysql安装目录下的bin目录，如：d:/mysql/bin下运行mysqldump -u root -p dbcurr> d:\20090219.sql
恢复数据库命令呢？

追答

上一句是导出   

下一句是导入

追问

不行

Answer 3

前言

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语句。