mysql执行完的更新语句成功还能恢复原来的数据吗

Posted 2023-03-27

通过数据库备份跟binlog日志记录，可能恢复原来的数据

恢复步骤

        a)创建新的数据库 create database rollback_db;

        b)将数据库备份倒入新创建的rollback_db中

        c)找到数据库备份的最后时间点，并将mysqlbinlog中该时间点之后的命令操作记录通过mysqlbinlog工具保存为sql命令文本

        d)将sql命令文本倒入数据库，可能rollback_db就是需要恢复的db了

    3.mysqlbinlog介绍

binlog基本定义：二进制日志，也成为二进制日志，记录对数据发生或潜在发生更改的SQL语句，并以二进制的形式保存在磁盘中；

作用：MySQL的作用类似于Oracle的归档日志，可以用来查看数据库的变更历史（具体的时间点所有的SQL操作）、数据库增量备份和恢复（增量备份和基于时间点的恢复）、Mysql的复制（主主数据库的复制、主从数据库的复制）

二进制日志的信息：

文件位置：默认存放位置为数据库文件所在目录下

文件的命名方式： 名称为hostname-bin.xxxxx （重启mysql一次将会自动生成一个新的binlog）

状态的查看：mysql> show variables like '%log_bin%';

    4.利用bin_log恢复数据 

        a)最长用的就是回复指定数据端的数据了，可以直接恢复到数据库中： 
    mysqlbinlog  --start-date="2012-10-15 16:30:00" --stop-date="2012-10-15 17:00:00" mysql_bin.000001 |mysql -uroot -p123456 
      亦可导出为sql文件，再导入至数据库中： 
      mysqlbinlog  --start-date="2012-10-15 16:30:00" --stop-date="2012-10-15 17:00:00" mysql_bin.000001 >d:\\1.sql 
      source d:\\1.sql 
        b)指定开始\\结束位置，从上面的查看产生的binary log我们可以知道某个log的开始到结束的位置，可以在恢复的过程中指定回复从A位置到B位置的log.需要用下面两个参数来指定： 
    --start-positon="50" //指定从50位置开始 
    --stop-postion="100"//指定到100位置结束

参考技术A 当启动Binlog后，事务会产生Binlog Event，这些Event被看做事务数据的一部分。因此要保证事务的Binlog Event和InnoDB引擎中的数据的一致性。所以带Binlog的CrashSafe要求MySQL宕机重启后能够保证：

- 所有已经提交的事务的数据仍然存在。

- 所有没有提交的事务的数据自动回滚。

- 所有已经提交了的事务的Binlog Event也仍然存在。

- 所有没有提交事务没有记录Binlog Event。

这些要求很好理解，如果重启后数据还在，但是Binlog Event没有了，就没办法复制到其他节点上了。如果重启后，数据没了，但是Binlog Event还在，那么不存在的数据就会被复制到其他节点上，从而导致主从的不一致。

为了保证带Binlog的CrashSafe，MySQL内部使用的两阶段提交(Two Phase Commit)。

2 - MySQL的Two Phase Commit(2PC)

在开启Binlog后，MySQL内部会自动将普通事务当做一个XA事务来处理：
- 自动为每个事务分配一个唯一的ID
- COMMIT会被自动的分成Prepare和Commit两个阶段。
- Binlog会被当做事务协调者(Transaction Coordinator)，Binlog Event会被当做协调者日志。
想了解2PC，可以参考文档：【https://en.wikipedia.org/wiki/Two-phase_commit_protocol。】

- 分布式事务ID(XID)

使用2PC时，MySQL会自动的为每一个事务分配一个ID，叫XID。XID是唯一的，每个事务的XID都不相同。XID会分别被Binlog和InnoDB记入日志中，供恢复时使用。MySQ内部的XID由三部分组成：

- 前缀部分

前缀部分是字符串"MySQLXid"

- Server ID部分

当前MySQL的server_id
- query_id部分

为了保证XID的的唯一性，数字部分使用了query_id。MySQL内部会自动的为每一个语句分配一个query_id，全局唯一。

参考代码：sql/xa。h的struct xid_t结构。

- 事务的协调者Binlog

Binlog在2PC中充当了事务的协调者（Transaction Coordinator）。由Binlog来通知InnoDB引擎来执行prepare，commit或者rollback的步骤。事务提交的整个过程如下：

1. 协调者准备阶段(Prepare Phase)

告诉引擎做Prepare，InnoDB更改事务状态，并将Redo Log刷入磁盘。

2. 协调者提交阶段(Commit Phase)

2.1 记录协调者日志，即Binlog日志。

2.2 告诉引擎做commit。
注意：记录Binlog是在InnoDB引擎Prepare(即Redo Log写入磁盘)之后，这点至关重要。

在MySQ的代码中将协调者叫做tc_log。在MySQL启动时，tc_log将被初始化为mysql_bin_log对象。参考sql/binlog.cc中的init_server_components()：
if (opt_bin_log) tc_log= &mysql_bin_log;

而在事务提交时，会依次执行：
tc_log->prepare()；
tc_log->commit()；
参考代码：sql/binlog.cc中的ha_commit_trans()。当mysql_bin_log是tc_log时，prepare和commit的代码在sql/binlog.cc中：

MYSQL_BIN_LOG::prepare()；
MYSQL_BIN_LOG::commit()；

-协调者日志Xid_log_event
作为协调者，Binlog需要将事务的XID记入日志，供恢复时使用。Xid_log_event有以下几个特点：
- 仅记录query_id
因为前缀部分不变，server_id已经记录在Event Header中，Xid_log_event中只记录query_id部分。
- 标志事务的结束

在Binlog中相当于一个事务的COMMIT语句。

一个事务在Binlog中看起来时这样的：
Query_log_event("BEGIN");DML产生的events; Xid_log_event;

- DDL没有BEGIN，也没有Xid_log_event 。
- 仅InnoDB的DML会产生Xid_log_event
因为MyISAM不支持2PC所以不能用Xid_log_event ，但会有COMMIT Event。
Query_log_event("BEGIN");DML产生的events;Query_log_event("COMMIT");

问题：Query_log_event("COMMIT")和Xid_log_event 有不同的影响吗？

- Xid_log_event 中的Xid可以帮助master实现CrashSafe。
- Slave的CrashSafe不依赖Xid_log_event
事务在Slave上重做时，会重新产生XID。所以Slave服务器的CrashSafe并不依赖于Xid_log_event 。Xid_log_event 和Query_log_event("COMMIT")，只是作为事务的结尾，告诉Slave Applier去提交这个事务。因此二者在Slave上的影响是一样的。

3 - 恢复(Recovery)
这个机制是如何保证MySQL的CrashSafe的呢，我们来分析一下。这里我们假设用户设置了以下参数来保证可靠性：

- 恢复前事务的状态
在恢复开始前事务有以下几种状态：
- InnoDB中已经提交
根据前面2PC的过程，可知Binlog中也一定记录了该事务的的Events。所以这种事务是一致的不需要处理。
- InnoDB中是prepared状态，Binlog中有该事务的Events。
需要通知InnoDB提交这些事务。
- InnoDB中是prepared状态，Binlog中没有该事务的Events。
因为Binlog还没记录，需要通知InnoDB回滚这些事务。
- Before InnoDB Prepare
事务可能还没执行完，因此InnoDB中的状态还没有prepare。根据2PC的过程，Binlog中也没有该事务的events。 需要通知InnoDB回滚这些事务。

- 恢复过程
从上面的事务状态可以看出：恢复时事务要提交还是回滚，是由Binlog来决定的。
- 事务的Xid_log_event 存在，就要提交。
- 事务的Xid_log_event 不存在，就要回滚。

恢复的过程非常简单：
- 从Binlog中读出所有的Xid_log_event
- 告诉InnoDB提交这些XID的事务
- InnoDB回滚其它的事务 参考技术B 应该是不能了,这个是改变了存在硬盘上的数据..除非你有备份

MySQL二进制日志功能介绍

二进制日志记录所有更新数据的SQL语句，其中也包含可能更新数据的SQL语句，例如DELETE语句执行过程中无匹配的行。二进制日志中还包含了与执行SQL语句相关的内容，例如SQL语句执行的时间、错误代码等。

 二进制日志功能介绍

MySQL中的二进制日志主要有两个功能：数据恢复和数据复制。

数据恢复--MySQL本身具备数据备份和恢复功能。例如我们可以每天午夜12:00进行数据备份。但是，此类备份功能并不是对数据库的实时备份，如果数据库在下午17:00出现故障无法恢复，那么从前一天午夜12:00到当天下午17:00的数据库内容将丢失。通过二进制日志可以解决这个问题。可以通过前一天午夜12:00的数据库备份文件恢复数据库，然后使用二进制日志恢复从前一天午夜12:00到当天下午17:00的数据库内容。

数据复制--MySQL支持主从服务器间的数据复制功能，并通过该功能实现数据库的冗余机制以保证数据库的可用性和提高数据库的性能。MySQL正是通过主服务器的二进制日志来实现数据的传递。主服务器上的二进制日志内容会被发送到各个从服务器，并在每个从服务器上执行，从而保证了主从服务器之间数据的一致性。

在默认配置下，MySQL不记录二进制日志。可以通过设置参数--log-bin=[base_name]启用二进制日志功能，MySQL会将修改数据库内容的语句记录到以base_name-bin.0000X为名字的日志文件中。其中bin代表binary，后缀0000X为二进制日志文件顺序。每次MySQL启动时，日志文件顺序会自动加1。如果base_name未定义，MySQL将使用pid-file参数设置的值作为二进制日志文件的基础名字。

我们可以从前面介绍的二进制日志的功能(数据恢复和数据复制)看出，二进制日志主要是供MySQL内部使用的，并不是为了数据库管理员阅读使用。因此，二进制日志与前面介绍的几种日志一个重要的不同就是，二进制日志文件的格式不是文本格式，其内容不能通过记事本直接查看。但是，为了管理员的方便，MySQL也提供了一个名为mysqlbinlog的工具，用于查看和处理二进制日志文件的内容。mysqlbinlog的用法为直接在命令后面添加二进制日志文件作为参数，比如：$mysqlbinlog jason2-bin.000001，其中jason2-bin.000001为二进制日志文件。

该命令运行后的结果如下，为了方便阅读，只节选了一部分具有代表性的内容：

1. ...  
2. 1 #090713 17:20:08 server id 1  end_log_pos 199  
3. Query   thread_id=1    exec_time=0    error_code=0 
4. 2 use test/*!*/;  
5. 3 SET TIMESTAMP=1247476808/*!*/;  
6. 4 SET @@session.pseudo_thread_id=1/*!*/;  
7. 5 SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1,  
8. @@session.unique_checks=1, @@session.autocommit=1/*!*/;  
9. 6 SET @@session.sql_mode=0/*!*/;  
10. 7 SET @@session.auto_increment_increment=1,  
11. @@session.auto_increment_offset=1/*!*/;  
12. 8 /*!\\C latin1 *//*!*/;  
13. 9 SET @@session.character_set_client=8,  
14. @@session.collation_connection=8,@@session.collation_server=8/*!*/;  
15. 10 SET @@session.lc_time_names=0/*!*/;  
16. 11 SET @@session.collation_database=DEFAULT/*!*/;  
17. 12 insert into t values (\'12345\')  
18. 13 /*!*/;  
19. 14 # at 199  
20. ... 

从第1~14行记录了一条对数据库更改操作的SQL语句(第12行)：insert into t values (\'12345\')。第1行记录内容如表11-6所示。

表11-6  记录内容说明

日志的第2行表示切换到MySQL服务器的test数据库。第3~11行设置当前会话的一些环境变量，例如是否自动提交(session.autocommit)、是否检查外键约束(session.foreign_key_ checks)等。如果需要了解它们详细的参数和说明，可以参考MySQL使用手册的第5章第1小节。

日志第12行为该条记录的核心，即对数据库进行了更改操作的SQL语句(insert into t values (\'12345\'))。日志第14行表示该条日志记录的结束。

以上分析了MySQL二进制日志如何记录一条对数据库进行更改的SQL语句，对于其他SQL语句的记录格式与上面的类似。

前面提到，每次MySQL启动时，日志文件顺序会自动加1。例如当前二进制日志文件名为：jason2-bin.000001，停止并重启动MySQL后，二进制日志文件名为jason2-bin.000002，新的更改数据库的操作将被记录到新的文件中。旧的二进制日志文件用于进行数据库的复制或者恢复。

默认情况下，在数据库目录下还有一个索引文件用来记录已经使用的二进制日志文件的名字，该索引文件的名字为"hostname-bin.index"。下面是索引文件的内容：

1. jason@jason2:~/mysql-bin/var> more jason2-bin.index  
2. ./jason2-bin.000001  
3. ./jason2-bin.000002 

索引文件最后一行表示当前正在使用的二进制日志名字。