mysqlbinlog闪回数据

合集下载

binlog恢复日志原理

binlog恢复日志原理Binlog是MySQL的一种日志文件，它记录了MySQL服务器上执行的所有操作，包括增删改查等，因此Binlog是MySQL数据库的重要组成部分。

在数据库恢复过程中，Binlog经常被用来进行数据恢复，该文件包含了所有对数据库进行操作的语句，可以用来将数据库状态恢复到某个时间点。

Binlog恢复日志的工作原理如下：1. 在MySQL中，所有的操作都是以事务为单位来执行的，每个事务结束后，MySQL会将该事务的操作记录到Binlog中。

2. Binlog文件由多个日志块组成，每个日志块记录了多个语句的执行情况。

一个完整的日志块一般会包含多个事务的操作。

3. 在数据库出现故障后，需要进行数据恢复。

如果是大部分情况下的意外故障，MySQL会使用InnoDB或MyISAM日志来恢复数据。

但一些更严重的情况，比如硬件故障，需要使用Binlog来恢复数据。

4. Binlog在恢复数据时，一般使用MySQL的备份程序或者第三方工具来进行恢复。

备份程序会读取Binlog文件中的内容，并将其中的操作语句逐个执行，来将数据库状态恢复到某个时间点。

需要注意的是，Binlog恢复日志只适用于一些较小的数据库。

对于大型的数据库，恢复时间可能会非常漫长，并且在执行过程中可能会遇到很多问题。

在这种情况下，最好使用MySQL的其他恢复工具，比如Xtrabackup等。

除此之外，为了保证数据的安全性，建议经常对数据库进行备份，并将备份文件存放到多个地方，以防意外情况的发生。

同时，确保Binlog日志的定期清理，以防日志文件过大消耗过多的磁盘空间。

总之，Binlog恢复日志是MySQL数据库中非常重要的组成部分，它会被广泛地应用于数据库恢复的过程中。

因此，在使用Binlog进行数据库恢复时，需要掌握其基本原理，并根据实际情况进行选择和使用。

MySQLFlashback闪回功能详解

MySQLFlashback闪回功能详解1. 简介mysqlbinlog flashback（闪回）⽤于快速恢复由于误操作丢失的数据。

在DBA误操作时，可以把数据库恢复到以前某个时间点（或者说某个binlog的某个pos）。

⽐如忘了带where条件的update、delete操作，传统的恢复⽅式是利⽤全备+⼆进制⽇志前滚进⾏恢复，相⽐于传统的全备+增备，flashback显然更为快速、简单。

⽬前MySQL的flashback功能是利⽤binlog完成的，第⼀个实现该功能的是阿⾥云的彭⽴勋，他在MySQL 5.5版本上就已实现，并将其提交给MariaDB。

2. 闪回原理原理：flashback⼯具（-B 参数）可对rows格式的binlog可以进⾏逆向操作，delete反向⽣成insert、update⽣成反向的update、insert反向⽣成delete。

MySQL的binlog以event的形式，记录了MySQL中所有的变更情况，利⽤binlog我们就能够重现所记录的所有操作。

MySQL引⼊binlog主要有两个⽤途/⽬的：⼀是为了主从复制；⼆是⽤于备份恢复后需要重新应⽤部分binlog，从⽽达到全备+增备的效果。

MySQL的binlog有三种格式：statement，基于SQL语句的模式，⼀般来说⽣成的binlog尺⼨较⼩，但是某些不确定性SQL语句或函数在复制过程可能导致数据不⼀致甚⾄出错；row，基于数据⾏的模式，记录的是数据⾏的完整变化。

相对更安全，推荐使⽤（但通常⽣成的binlog会⽐其他两种模式⼤很多）；mixed，混合模式，可以根据情况⾃动选⽤statement抑或row模式；这个模式下也可能造成主从数据不⼀致。

它属于MySQL 5.1版本时期的过渡⽅案，已不推荐使⽤了。

注意：使⽤mysqlbinlog flashback ⼯具必须设置：binlog_format = row3. flashback安装下载flashback⼯具 mysqlbinlog ：，并将mysqlbinlog⽂件移⾄mysql安装路径的bin⽬录下(可备份原来的mysqlbinlog为mysqlbinlog_bak)，执⾏mysqlbinlog --help命令，可能会报错(系统版本为 CentOS 6.4_x64)：[root@centos64-slave1 bin]# mysqlbinlog --helpmysqlbinlog: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by mysqlbinlog)需要安装新版本的libstdc++.so.6，下载链接：[root@centos64-slave1 ~]# cp libstdc++.so.6.0.20 /usr/lib64/[root@centos64-slave1 ~]# cd /usr/lib64/[root@centos64-slave1 lib64]# mv libstdc++.so.6 libstdc++.so.6_bak[root@centos64-slave1 lib64]# ln -s libstdc++.so.6.0.20 libstdc++.so.6[root@centos64-slave1 lib64]# ll libstdc*lrwxrwxrwx 1 root root 19 4⽉609:30 libstdc++.so.6 -> libstdc++.so.6.0.20-rwxr-xr-x. 1 root root 987096 7⽉192013 libstdc++.so.6.0.13-rw-r--r-- 1 root root 1011824 4⽉609:28 libstdc++.so.6.0.20lrwxrwxrwx. 1 root root 19 1⽉1412:25 libstdc++.so.6_bak -> libstdc++.so.6.0.13安装完后执⾏mysqlbinlog --help，若报错：mysqlbinlog: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by/usr/lib64/libstdc++.so.6)，需要更新/lib64库⽂件。

mysql数据误删除恢复语句 -回复

mysql数据误删除恢复语句-回复我们都知道，在使用数据库中，数据的误删除是一个常见的问题。

当误删除发生时，如果没有备份，许多人会感到绝望。

然而，幸运的是，MySQL 数据库提供了一些恢复数据的方法。

在本文中，我们将详细介绍一些常用的MySQL数据误删除恢复语句。

MySQL是一个广泛使用的关系型数据库管理系统，它具有高性能、稳定性和易用性的特点。

但是，就像其他数据库管理系统一样，MySQL也不免遭遇误操作导致数据丢失的风险。

在这里，我们将介绍一些常见的数据误删除场景，并提供一些可行的恢复方法。

首先，让我们来看一个最常见的数据误删除场景：误执行了一个DELETE 语句。

当我们执行DELETE语句时，MySQL会将符合条件的行从表中删除。

如果我们在执行DELETE语句之前没有备份数据，那么就需要采取一些恢复措施来还原误删除的数据。

1. 首先，查看数据库是否启用了binlog功能。

binlog是MySQL的二进制日志，它记录了数据库中的所有操作。

在MySQL配置文件中，可以找到binlog的相关设置。

如果binlog功能被启用，那么我们就有希望通过binlog来还原误删除的数据。

2. 使用SHOW BINARY LOGS命令查看当前的binlog文件列表，并找到包含误删除操作的binlog文件。

在恢复过程中，我们将使用这个binlog 文件来还原数据。

3. 使用mysqlbinlog命令来解析binlog文件并生成SQL查询语句。

例如，我们可以使用以下命令来解析名为mysql-bin.000001的binlog文件：mysqlbinlog mysql-bin.000001 > restore.sql4. 编辑生成的restore.sql文件，找到并删除误删除的DELETE语句。

保存文件后，我们得到了一个只包含要还原的数据的SQL文件。

5. 使用mysql命令来执行restore.sql文件中的SQL语句，将误删除的数据还原到数据库中：mysql -u 用户名-p 密码数据库名< restore.sql通过上述步骤，我们可以通过binlog来还原误删除的数据。

mysql利用binlog恢复数据详细例子

mysql利⽤binlog恢复数据详细例⼦模拟数据恢复的案例有些时候脑⽠就会短路，难免会出错场景：在⽣产环境中，我们搭建了mysql主从，备份操作都是在从备份数据库上前提：有最近⼀天或者最近的全备或者最近⼀天相关数据库的备份最重要的是，⼆进制⽇志必须完整服务器信息⾓⾊端⼝192.168.1.21 mysql主 30136 192.168.1.21 mysql从30236接下来，我们模拟下案例⼀、update未加where条件，误操作修改数据全备命令： mysqldump -uroot -p123456 --single-transaction --set-gtid-purged=OFF --master-data=2 -A > all_database.sql mysqldump -uroot -p123456 --single-transaction --set-gtid-purged=OFF --master-data=2 xcrm > xcrm.sql模拟灾难现场我这个是在k8s⾥⾯搭建了⼀个主从kubectl get all -o widekubectl exec -it mysql-master-659958ff4f-l4sgt bash #mysql主mysql -uroot -p123456mysql> show databases;+--------------------+| Database |+--------------------+| information_schema || mysql || performance_schema || sys || xcrm |+--------------------+5 rows in set (0.00 sec)mysql> use xcrmmysql> create table edai_test like ding_cun;mysql> insert into edai_test select * from ding_cun;⽐如凌晨全备是做到这⾥的命令：mysqldump -uroot -p123456 --single-transaction --set-gtid-purged=OFF --master-data=2 -A > all_database.sql早上九点的时候，⼜有新的数据进来mysql> insert into edai_test(nper,money) select nper,money from ding_cun;110 rows in set (0.00 sec)悲剧来了，上线中的sql，没有检查，where条件没加，直接执⾏mysql> update edai_test set money=0;Query OK, 110 rows affected (0.07 sec)Rows matched: 110 Changed: 110 Warnings: 0糟糕，⼀不⼩⼼⾦额被我修改为0了，偶my嘎，赶紧恢复，找出binlog点，根据之前的全备+binlog恢复恢复步骤：1.找出时间段root@mysql-master-659958ff4f-l4sgt:~/backu1.p# cat all_database.sql |grep -i 'CHANGE MASTER TO MASTER_LOG_FILE'|head -n1 -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;mysql -uroot -p123456 -e "show binlog events in 'mysql-bin.000001'"|tail -n1000找到了对应pos点：43262.mysql导⼊昨天晚上的备份数据，并且查看pos节点mysql -uroot -p123456 < all_databases.sql3.拷贝⼆进制⽇志⽂件到其他地⽅和⼆进制恢复cp /var/lib/mysql/mysql-bin.000001 .root@mysql-master-659958ff4f-l4sgt:~/backup# mysqlbinlog --start-position=154 --stop-position=4326 -d xcrm mysql-bin.000001|mysql -uroot -p123456 xcrm好了，数据恢复⼆、删库其实删除数据库都是⼀样的道理⽐如我们的备份是还是昨天晚上的，但是今天下午清理数据，删除⽆效的数据库，误删了恢复步骤和原理都是差不多的，我就不演⽰了，简单讲解下⽐如下午有新加了⼀些数据：mysql>create table customers(id int not null auto_increment,name char(20) not null,age int not null,primary key(id))engine=InnoDB;Query OK, 0 rows affected (0.35 sec)mysql>insert into customers values(1,"wangbo","24");Query OK, 1 row affected (0.07 sec)mysql>insert into customers values(2,"guohui","22");Query OK, 1 row affected (0.12 sec)mysql>insert into customers values(3,"zhangheng","27");Query OK, 1 row affected (0.06 sec)mysql>select*from customers;+----+-----------+-----+| id | name | age |+----+-----------+-----+|1| wangbo |24||2| guohui |22||3| zhangheng |27|+----+-----------+-----+3 rows in set (0.00 sec)然后我⼀不⼩⼼把数据库删除了mysql>drop database xcrm;Query OK, 5 rows affected (0.40 sec)删库恢复步骤到这⾥，如果是在⽣产环境，必须⽴刻做处理1.⽴刻设置全局只读进⼊数据库：set global read_only=1; #普通权限的⽤户只读，不能写数据mysql> show variables like '%read_only%';此时普通⽤户不能进⾏写操作啦，⽐如下⾯mysql -udemo -pdemo -P30136 -h192.168.1.21 xcrmmysql>select*from customers ;+----+-----------+-----+| id | name | age |+----+-----------+-----+|1| wangbo |24||2| guohui |22||3| zhangheng |27|+----+-----------+-----+3 rows in set (0.00 sec)mysql>delete from customers where id=3;ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement2.找到最近备份⽂件和⼆进制⽇志点root@mysql-master-659958ff4f-l4sgt:~/backup# mysql -uroot -p123456 -e "show binlog events in 'mysql-bin.000001'"|grep -i 'DROP DATABASE'mysql: [Warning] Using a password on the command line interface can be insecure.mysql-bin.000001 15035 Query 22 15127 drop database xcrm找到最近备份⽂件的最后pos位置root@mysql-master-659958ff4f-l4sgt:~/backup# cat all_database.sql |grep -i 'CHANGE MASTER TO MASTER_LOG_FILE'|head -n1 -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=13871;3.进⾏恢复先将今天凌晨备份的导进去mysql -uroot -p123456 < all_database.sql13871 15035查看数据中间还相差很多数据，没关系，再根据pos期间来恢复mysqlbinlog --start-position=13871 --stop-position=15035 -d xcrm mysql-bin.000001|mysql -uroot -p123456 xcrm进⼊数据库看看，数据是否正常mysql -uroot -p123456mysql>use xcrmReading table information for completion of table and column namesYou can turn off this feature to get a quicker startup with-ADatabase changedmysql> show tables;+------------------+| Tables_in_xcrm |+------------------+| customers || ding_cun || edai_app_version || edai_test |+------------------+4 rows in set (0.00 sec)mysql>select*from customers;+----+-----------+-----+| id | name | age |+----+-----------+-----+|1| wangbo |24||2| guohui |22||3| zhangheng |27|+----+-----------+-----+3 rows in set (0.00 sec)好了，没问题，drop数据库也可以恢复啦现在把全局锁解开：mysql>set global read_only=0;Query OK, 0 rows affected (0.00 sec)mysql> show variables like'%read_only%';+------------------+-------+| Variable_name | Value |+------------------+-------+| innodb_read_only |OFF|| read_only |OFF|| super_read_only |OFF|| tx_read_only |OFF|+------------------+-------+4 rows in set (0.00 sec)⼤家有没有什么疑问？再三强调：在⽣产环境误操作之后，应该⽴刻判断这个表或者库的重要性1.如果是不常⽤的数据库或者表，⼏乎没有数据更新，可以不⽤锁库，只读2.如果是很常⽤的数据库或者表，必须处理，设置为只读，如果更为严重，需要停⽌mysql服务器。

MyFlash闪回恢复数据

MyFlash闪回恢复数据笔记：网上查了一下，用的比较多的是美团的Myflash跟binlog2sql,做了一下实验,感觉Myflash稍微好用一点。

1、binlog格式必须为row,且binlog_row_image=full。

2、仅支持5.6与5.7。

3、只能回滚DML（增、删、改）。

4、mysqlbinlog版本请保持一致。

安装依赖包yum install glib2 glib2-devel gcc git mysql mysql-devel -yyum groupinstall"Development tools""Server Platform Development"下载myflash源码包。

下载地址：https:///Meituan-Dianping/MyFlash/tree/master编译安装myflash，此处采用静态编译方式。

cd /data/MyFlash-mastergcc -w -g `pkg-config --cflags glib-2.0`source/binlogParseGlib.c-o /data/flashback /usr/lib64/libglib-2.0.so -lrt参数解析：/data/MyFlash/source/binlogParseGlib.c：myflash c源码文件位置/data/flashback：编译完成myflash的可执行文件位置/usr/lib64/libglib-2.0.so：glib2.0的lib文件位置pkg-config --cflags glib-2.0：标明使用的glib版本使用说明：./flashback --helpUsage:flashback [OPTION...]Help Options:-?, --help Show help optionsApplication Options:--databaseNames databaseName to apply. if multiple,seperate by comma(,)#指定需要回滚的数据库名称。

大数据培训 MyFlash美团点评的开源MySQL闪回工具_光环大数据培训

大数据培训 MyFlash美团点评的开源MySQL闪回工具_光环大数据培训由于运维、DBA的误操作或是业务bug，我们在操作中时不时会出现误删除数据情况。

早期要想恢复数据，只能让业务人员根据线上操作日志，构造误删除的数据，或者DBA使用binlog和备份的方式恢复数据，不管那种，都非常费时费力，而且容易出错。

直到彭立勋首次在MySQL社区为mysqlbinlog扩展了闪回功能。

在美团点评，我们也遇到过研发人员误删主站的配置信息，从而导致主站长达2个小时不可用的情况。

DBA同学当时使用了技术团队自研的binlog2sql完成了数据恢复，并多次挽救了线上误删数据导致的严重故障。

不过，binlog2sql在恢复速度上不尽如人意，因此我们开发了一个新的工具——MyFlash，它很好地解决了上述痛点，能够方便并且高效地进行数据恢复。

现在该工具正式开源，开源地址为：https:///Meituan-Dianping/MyFlash 。

闪回工具现状先来看下目前市面上已有的恢复工具，我们从实现角度把它们划分成如下几类。

mysqlbinlog工具配合sed、awk。

该方式先将binlog解析成类SQL的文本，然后使用sed、awk把类SQL文本转换成真正的SQL。

优点：当SQL中字段类型比较简单时，可以快速生成需要的SQL，且编程门槛也比较低。

缺点：当SQL中字段类型比较复杂时，尤其是字段中的文本包含HTML代码，用awk、sed等工具时，就需要考虑极其复杂的转义等情况，出错概率很大。

给数据库源码打patch。

该方式扩展了mysqlbinlog的功能，增加Flashback选项。

优点：复用了MySQL Server层中binlog解析等代码，一旦稳定之后，无须关心复杂的字段类型，且效率较高。

缺点：在修改前，需要对MySQL的复制代码结构和细节需要较深的了解。

版本比较敏感，在MySQL 5.6上做的patch，基本不能用于MySQL 5.7的回滚操作。

MySQL数据恢复的多种方法汇总

MySQL数据恢复的多种⽅法汇总⽬录1、前⾔2、直接恢复2.1 mysqldump 备份全量恢复2.2 xtrabackup 备份全量恢复2.3 基于时间点恢复3、恢复⼀个表3.1 从 mysqldump 备份恢复⼀个表3.2 从 xtrabackup 备份恢复⼀个表4、跳过误操作SQL4.1 使⽤备份⽂件恢复跳过4.2 使⽤延迟库跳过5. 闪回。

5.1 binlog2sql5.2 MyFlash1、前⾔数据恢复的前提的做好备份，且开启 binlog，格式为 row。

如果没有备份⽂件，那么删掉库表后就真的删掉了，lsof 中还有记录的话，有可能恢复⼀部分⽂件。

但若刚好数据库没有打开这个表⽂件，那就只能跑路了。

如果没有开启 binlog，那么恢复数据后，从备份时间点开始的数据都没了。

如果 binlog 格式不为 row，那么在误操作数据后就没有办法做闪回操作，只能⽼⽼实实地⾛备份恢复流程。

2、直接恢复直接恢复是使⽤备份⽂件做全量恢复，这是最常见的场景。

2.1 mysqldump 备份全量恢复使⽤ mysqldump ⽂件恢复数据⾮常简单，直接解压了执⾏：gzip -d backup.sql.gz | mysql -u<user> -h<host> -P<port> -p2.2 xtrabackup 备份全量恢复恢复过程：# 步骤⼀：解压（如果没有压缩可以忽略这⼀步）innobackupex --decompress <备份⽂件所在⽬录># 步骤⼆：应⽤⽇志innobackupex --apply-log <备份⽂件所在⽬录># 步骤三：复制备份⽂件到数据⽬录innobackupex --datadir=<MySQL数据⽬录> --copy-back <备份⽂件所在⽬录>2.3 基于时间点恢复基于时间点的恢复依赖的是 binlog ⽇志，需要从 binlog 中找过从备份点到恢复点的所有⽇志，然后应⽤。

Mysql之Binlog日志完全备份增量+binlog日志基于时间点恢复数据

Mysql之Binlog⽇志完全备份增量+binlog⽇志基于时间点恢复数据众所周知，binlog⽇志对于mysql数据库来说是⼗分重要的。

在数据丢失的紧急情况下，我们往往会想到⽤binlog⽇志功能进⾏数据恢复（定时全备份+binlog⽇志恢复增量数据部分），化险为夷！废话不多说，下⾯是梳理的binlog⽇志操作解说：MySQL的⼆进制⽇志binlog可以说是MySQL最重要的⽇志，它记录了所有的DDL和DML语句（除了数据查询语句select），以事件形式记录，还包含语句所执⾏的消耗的时间，MySQL的⼆进制⽇志是事务安全型的。

DDL----Data Definition Language 数据库定义语⾔主要的命令有CREATE、ALTER、DROP等，DDL主要是⽤在定义或改变表（TABLE）的结构，数据类型，表之间的链接和约束等初始化⼯作上，他们⼤多在建⽴表时使⽤。

DML----Data Manipulation Language 数据操纵语⾔主要的命令是SELECT、UPDATE、INSERT、DELETE，就象它的名字⼀样，这4条命令是⽤来对数据库⾥的数据进⾏操作的语⾔1 --start-datetime：从⼆进制⽇志中读取指定等于时间戳或者晚于本地计算机的时间2 --stop-datetime：从⼆进制⽇志中读取指定⼩于时间戳或者等于本地计算机的时间取值和上述⼀样3 --start-position：从⼆进制⽇志中读取指定position 事件位置作为开始。

4 --stop-position：从⼆进制⽇志中读取指定position 事件位置作为事件截⾄1）MySQL主从复制：MySQL Replication在Master端开启binlog，Master把它的⼆进制⽇志传递给slaves来达到master-slave数据⼀致的⽬的。

2）⾃然就是数据恢复了，通过使⽤mysqlbinlog⼯具来使恢复数据。

mysqlbinlog 恢复原理

mysqlbinlog 恢复原理mysqlbinlog 是 MySQL 数据库中的一个命令行工具，用于将二进制日志转换为文本格式，使得可以直接读取或编辑。

与此同时，mysqlbinlog 同时也可以用于数据恢复。

当 MySQL 服务器启用二进制日志（binary logging）时，它会记录不同的操作，例如插入（INSERT）和更新（UPDATE）等，将这些操作进行二进制编码，最终写入一个二进制日志文件中。

这些二进制日志文件可以用于数据恢复，如果数据出现了问题，可以使用二进制日志来恢复数据。

mysqlbinlog 恢复原理主要是利用数据库生成的二进制日志（binary logs）。

当 MySQL 数据库启用二进制日志后，将会不断向二进制日志文件中写入各种操作记录，该文件默认位置为 MySQL 数据库服务器数据目录下的 binlog 文件夹中（如果没有则需要手动创建）。

每个 binlog 文件都对应一个时间段内 MySQL 中所有数据操作的记录，也就是说，可以通过 mysqlbinlog 工具来读取这些文件并将其转换成文本格式。

借助 mysqlbinlog 工具，我们可以通过读取二进制日志文件来找到已经执行过的SQL 命令并将其恢复。

一般来说，将 SQL 命令恢复的过程可以分为以下步骤：1. 使用 SHOW BINARY LOGS 命令查看所有已经记录的二进制日志文件列表，确定目标文件的名称和路径；2. 使用 mysqlbinlog 工具读取目标文件并输出二进制日志中的 SQL 命令，将其保存为文本格式；3. 将文本格式的 SQL 命令文件执行，即可对数据库进行数据的恢复操作。

在执行数据恢复操作时，需要注意以下几点：1. 数据库必须启用二进制日志功能才能恢复数据；2. 在执行 SQL 命令文件之前，需要确保所执行的命令不会影响数据的完整性；3. 在将 SQL 命令文件作为恢复数据的手段时，必须手动执行命令文件以复制所有的SQL 命令，因为 mysqlbinlog 工具在某些情况下可能无法生成完整的 SQL 命令文件。

mysql binlog回复数据方法

mysql binlog回复数据方法MySQL的二进制日志（binlog）记录了数据库的所有更改，主要用于数据恢复和主从复制。

如果你想从binlog中恢复数据，你可以使用以下方法：1. 使用mysqlbinlog工具：`mysqlbinlog` 是一个命令行工具，可以用来查看和操作二进制日志文件。

查看binlog内容：```bash`mysqlbinlog /path/to/binlog-file````将binlog内容导出到一个SQL文件：```bash`mysqlbinlog /path/to/binlog-file > ````2. 使用Percona Toolkit：Percona Toolkit是一组用于MySQL数据库管理和故障排除的命令行工具。

它包含一个名为`pt-mysql-summary`的工具，可以帮助你分析binlog并生成一个SQL文件，该文件可以用来恢复数据。

3. 直接从binlog解析并恢复数据：如果你知道你感兴趣的具体事件（例如，你只关心某个表的插入操作），你可以使用`mysqlbinlog`工具结合`--start-position`和`--stop-position`参数来只解析和恢复这些事件。

4. 使用第三方工具：市场上也有一些第三方工具，如`Binlog2sql`，可以帮助你从binlog中提取和恢复数据。

5. 直接从主库恢复：如果你正在使用主从复制，并且数据已经从主库复制到了从库，那么你可以考虑直接从从库恢复数据。

这样，你只需要找到对应的binlog位置，然后重新开始同步。

6. 使用备份：如果你有定期备份，那么最简单的方法是从最近的备份中恢复数据。

这通常是最快速和最可靠的方法。

7. 考虑其他数据恢复方法：在某些情况下，可能还有其他的恢复方法，例如从归档日志或第三方备份解决方案中恢复。

无论你选择哪种方法，都强烈建议在尝试任何恢复操作之前备份当前的数据和配置，以防进一步的数据丢失或配置问题。

mysqlbinlog 恢复数据库语句

mysqlbinlog 恢复数据库语句要使用 `mysqlbinlog` 恢复数据库，你需要执行以下步骤：1. 确保你拥有 `mysqlbinlog` 工具。

如果没有，可以通过 MySQL 官方网站或相应的包管理工具安装。

2. 找到要恢复的二进制日志文件。

这些文件通常位于 MySQL 的数据目录下的`binlog` 子目录中，并具有以 `mysql-bin` 开头的文件名。

3. 使用以下命令执行恢复操作：```sqlmysqlbinlog mysql-bin.000001 | mysql -u [user_name] -p [password] [database_name]```请将 `mysql-bin.000001` 替换为实际的二进制日志文件名。

如果有多个日志文件，你可以按顺序将它们连接起来，例如：```sqlmysqlbinlog mysql-bin.000001 mysql-bin.000002 | mysql -u [user_name] -p [password] [database_name]```其中，`[user_name]` 和`[password]` 是MySQL 数据库的用户名和密码，`[database_name]` 是要恢复数据的目标数据库名称。

4. 执行上述命令后，`mysqlbinlog` 工具将读取二进制日志文件中的 SQL 语句，并将其发送到 MySQL 服务器，以执行相应的操作来恢复数据库。

请注意，恢复操作将覆盖目标数据库中的现有数据。

因此，在执行恢复之前，请确保你已经备份了重要的数据或在测试环境中进行操作。

此外，确保恢复的二进制日志文件与目标数据库的版本兼容，并且在恢复过程中可能需要适当的权限。

如果你需要更详细或高级的恢复选项，你还可以使用其他 MySQL 工具或命令，如`mysqladmin` 或直接在 MySQL 命令行中执行恢复操作。

具体的命令和选项可能会有所不同，请根据你的需求和 MySQL 版本参考相应的文档。

mysql如何利用binlog进行数据恢复详解

mysql如何利⽤binlog进⾏数据恢复详解前⾔最近线上误操作了⼀个数据，由于是直接修改的数据库，所有唯⼀的恢复⽅式就在mysql的binlog。

binlog使⽤的是ROW模式，即受影响的每条记录都会⽣成⼀个sql。

同时利⽤了binlog2sql项⽬。

MySQL Binary Log也就是常说的bin-log, ,是mysql执⾏改动产⽣的⼆进制⽇志⽂件,其主要作⽤有两个:* 数据回复* 主从数据库。

⽤于slave端执⾏增删改，保持与master同步。

binlog基本配置和格式binlog基本配置binlog需要在mysql的配置⽂件的mysqld节点中进⾏配置：# ⽇志中的Serveridserver-id = 1# ⽇志路径log_bin = /var/log/mysql/mysql-bin.log# 保存⼏天的⽇志expire_logs_days = 10# 每个binlog的⼤⼩max_binlog_size = 1000M#binlgo模式binlog_format=ROW# 默认是所有记录，可以配置哪些需要记录，哪些不记录#binlog_do_db = include_database_name#binlog_ignore_db = include_database_name查看binlog状态SHOW BINARY LOGS; 查看binlog⽂件SHOW VARIABLES LIKE '%log_bin%' 查看⽇志状态SHOW MASTER STATUS 查看⽇志⽂件位置binlog的三种格式1.ROW针对⾏记录⽇志，每⾏修改产⽣⼀条记录。

优点：上下⽂信息⽐较全，恢复某条误操作时可以直接在⽇志中查找到原⽂信息，对于主从复制⽀持好。

缺点：输出⾮常⼤，如果是Alter语句将产⽣⼤量的记录格式如下：DELETE FROM `back`.`sys_user` WHERE `deptid`=27 AND `status`=1 AND `account`='admin' AND `name`='张三' AND `phone`='182********' AND `roleid`='1' AND `createtime`='2016-01-29 08:49:53' AND `sex`=2 AND `email`='sn93@' AND `birthday`=' 2.STATEMENT针对sql语句的，每条语句产⽣⼀条记录优点：产⽣的⽇志量⽐较⼩，主从版本可以不⼀致缺点：主从有些语句不能⽀持，像⾃增主键和UUID这种类型的格式如下：delete from `sys_role`;3.MIX结合了两种的优点，⼀般情况下都采⽤STATEMENT模式，对于不⽀持的语句采⽤ROW模式转换成sqlmysql⾃带的mysqlbinlog由于binlog是⼆进制的，所以需要先转换成⽂本⽂件，⼀般可以采⽤Mysql⾃带的mysqlbinlog转换成⽂本。

mysql5.7使用binlog恢复数据的方法

mysql5.7使⽤binlog恢复数据的⽅法第⼀步：保证mysql已经开启binlogshow variables like '%log_bin%';log_bin 为 on是开启。

第⼆步：进⼊binlog⽂件⽬录，找到⼆进制⽇志⽂件mysql> show binary logs; #获取binlog⽂件列表mysql> show master status； #查看当前正在写⼊的binlog⽂件mysql> reset master; 重置binlog第三步：通过mysqlbinlog⼯具命令查看数据库增删改查记录（必须切换到mysqlbinlog⽬录才有效）或者直接指定binlog例⼦1：查询2021-3-12 14:00:00到2021-3-12 14:03:00 数据库为 g_xinxiangshop的操作⽇志，输⼊如下命令将数据写⼊到⼀个备⽤的txt⽂件中/usr/local/mysql/bin/mysqlbinlog --no-defaults --database=g_xinxiangshop --start-datetime=“2021-3-12 14:00:00” --stop-datetime=“2021-3-12 14:03:00” /usr/local/mysql/data/mysql-bin.000001 >/tmp/binlog.txt例⼦2：查询2021-3-12 14:00:00到2021-3-12 14:03:00 数据库为 g_xinxiangshop的操作⽇志，并且过滤出只包括 g_user表数据的操作记录，输⼊如下命令将数据写⼊到⼀个备⽤的txt⽂件中/usr/local/mysql/bin/mysqlbinlog --no-defaults --database=g_xinxiangshop --start-datetime=“2021-3-12 14:00:00” --stop-datetime=“2021-3-12 14:03:00” /usr/local/mysql/data/mysql-bin.000001 | grep g_user > /tmp/binlog.txt例⼦3：查询2021-3-15 15:25:00到2021-3-15 15:35:00 数据库为 g_shoptest 的操作⽇志，并输出到屏幕上/usr/local/mysql/bin/mysqlbinlog --no-defaults --database=g_shoptest --start-datetime=“2021-3-15 15:25:00” --stop-datetime=“2021-3-15 15:35:00” /data/mysql/mysql-bin.000001 |more图⽚和例1、例2内容⼀样看到了truncate操作和记录点就可以做恢复操作了！第四步：测试利⽤bin_log恢复数据登录mysql测试：1、 reset master; 重置binlog并重新⽣成记录⽇志2、测试某个表插⼊⼀条数据然后不⼩⼼删除了。

Mysql通过binlog日志恢复数据

Mysql通过binlog⽇志恢复数据转⾃：Binlog⽇志，即binary log，是⼆进制⽇志⽂件，有两个作⽤，⼀个是增量备份，另⼀个是主从复制，即主节点维护⼀个binlog⽇志⽂件，从节点从binlog中同步数据，也可以通过binlog⽇志来恢复数据1，登录mysql查看binlog⽇志的状态，输⼊show variables like ‘%log_bin%’;查看binlog为off关闭状态配置开启binloglog_bin=/usr/local/mysql/data/binlog/mysql‐bin注意5.7以及更⾼版本需要配置本项：server‐id=123454（⾃定义,保证唯⼀性）;#binlog格式，有3种statement,row,mixedbinlog_format=ROW#表⽰每1次执⾏写⼊就与硬盘同步，会影响性能，为0时表⽰，事务提交时mysql不做刷盘操作，由系统决定sync_binlog=12，开启mysql binlog⽇志，进⼊mysql配置⽂件(vi /etc/f) 在mysqld区域内添加如下内容，①server-id = 1(单个节点id) ②log-bin=/var/lib/mysql/mysql-bin(位置⼀般和mysql库⽂件所在位置⼀样) ③expire_logs_days = 10(表⽰此⽇志保存时间为10天),重启mysqld,再次查看binlog⽇志开启状态为ON3，Binlog⽇志包括两类⽂件；第⼀个是⼆进制索引⽂件(后缀名为.index),第⼆个为⽇志⽂件(后缀名为.00000*),记录数据库所有的DDL和DML(除了查询语句select)语句事件4，查看所有binlog⽇志⽂件列表:show master logs;5，查看最后⼀个binlog⽇志的编号名称及其最后⼀个操作事件pos结束点的值：show master status;6，Flush logs 刷新⽇志，此刻开始产⽣⼀个新编号的binlog⽂件，例如：每当mysqld服务重启时，会⾃动执⾏刷新binlog⽇志命令，mysqldump备份数据时加-F选项也会刷新binlog⽇志7，清空所有binlog⽇志命令:reset master;8，查看binlog⽂件内容，使⽤查看⼯具mysqlbinlog来查看(cat/vi/more都是⽆法打开的)9，上⾯的⽅法读取内容较多不易观察，以下命令更为⽅便查看命令：show binlog events in ‘mysql-bin.000003’; mysql> show binlog events [IN 'log_name'][FROM pos][LIMIT [offset,] row_count];选项解析：IN'log_name'指定要查询的binlog⽂件名(不指定就是第⼀个binlog⽂件)FROM pos 指定从哪个pos起始点开始查起(不指定就是从整个⽂件⾸个pos点开始算)LIMIT [offset,]偏移量(不指定就是0)row_count 查询总条数(不指定就是所有⾏)10，指定查询,从pos点406开始查询，如下：11，指定查询，从pos点154开始查询，中间跳过2⾏，查询4条数据，如图：12，利⽤binlog⽇志恢复mysql数据，例如，现有⼀张数据表如图：此表位于hello数据库现在将此数据库备份到本地(模拟每周的备份情况)，备份命令如下可以在数据备份之前或者之后执⾏flush logs重新⽣成⼀个binlog⽇志⽤来记录备份之后的所有增删改操作(重新⽣成⽇志更好找pos点)，由于业务需求，现在对表进⾏插⼊数据，修改数据，如图新增了两条数据id 为5和6，修改后数据如图，6的年龄修改成了3013，由于操作失误，误删除了数据库，所有数据都不见了,此时可以通过binlog⽇志恢复数据，由于之前有做了数据库备份，所以可以先将备份的数据导⼊进去，剩下缺少的就是备份之后操作所产⽣的内容(备份之后执⾏了插⼊内容以及更改内容)，先恢复备份的数据：创建库hello 并选择库(use hello)，通过命令source /root/hello.sql将数据库内容导⼊，然后执⾏14，恢复的内容如下所⽰：15，上⾯恢复的数据只是截⽌到备份时间的数据，剩下缺少的数据可以通过binlog⽇志来恢复，由于我们备份数据库之前重新创建了mysql-bin.000006⽇志，所以备份后的所有操作都保存在这个⽇志中，可以先备份下这个⽇志⽂件，cp mysql-bin.000006 /root/ 接着执⾏flush logs 刷新⽇志，重新创建了⼀个binlog⽇志716，重新创建⼀个⽇志7的⽬的：接下来所有操作的数据都会写⼊到⽇志7中，⽇志6中不会在写⼊任何数据(⽅便根据⽇志6的内容恢复数据，因为⽇志6的数据就是备份之后到删库之前的所有操作⽇志，重建⽇志7不会有过多的数据影响恢复)17，登录mysql 查看⽇志6: show binlog events in ‘mysql-bin.000006’;结果如下：查看⽇志发现，在备份数据后⾸先执⾏的是插⼊数据操作(在⼀个事务内)，此时可以通过指定pos结束点恢复(部分恢复)，如图，pos结束点位435(事务已提交表⽰结束)，执⾏命令如下, /usr/bin/mysqlbinlog --stop-position=435 --database=hello /var/lib/mysql/mysql-bin.000006 | /usr/bin/mysql -uroot -p密码 -v hello (其中整个命令的含义是通过mysqlbinlog读取⽇志内容并通过管道传给mysql命令，-v表⽰执⾏此mysql 命令)执⾏后查询表发现如下：备份之后插⼊的数据都出现了，⽬前还差⼀次修改的数据没有找回来，接着看⽇志6如图，发现执⾏更新操作的事务区间为573到718，所以可以执⾏以下命令来恢复这段数据，/usr/bin/mysqlbinlog --start-position=573 --stop-position=718 --database=hello /var/lib/mysql/mysql-bin.000006 | /usr/bin/mysql -uroot -p密码 -v hello注意其中的符号都是英⽂状态下(只恢复这段事务区间的数据也就是更新的数据)，恢复结果如下：更改的数据回来了，也可以最开始的时候直接通过最终的pos结束点718来恢复18，还有⼀种通过时间来恢复，还是先备份当前数据库(备份之前先flush logs创建⼀个新的binlog⽇志⽂件9)，然后修改数据插⼊数据后如图，修改后将当前数据库删除，(删除库之后再执⾏⼀下flush logs创建⼀个新的⽇志⽂件，这样新的操作都写⼊到这个⽂件中，上个⽇志⽂件只⽤来恢复数据，不会有其余数据混⼊)现在我们通过时间点来恢复从备份数据后到删除数据库这期间所有操作的数据，⾸先通过mysqlbinlog 来了查看⽇志⽂件9如图所⽰，19，执⾏命令：/usr/bin/mysqlbinlog --start-datetime="2018-04-27 20:57:55" --stop-datetime="2018-04-27 20:58:18" --database=hello /var/lib/mysql/mysql-bin.000009 | /usr/bin/mysql -uroot -p8856769abcd -v hello 更改的数据得到了恢复20，插⼊数据的⽇志时间如图：执⾏命令/usr/bin/mysqlbinlog --start-datetime="2018-04-27 20:58:18" --stop-datetime="2018-04-27 20:58:35" --database=hello/var/lib/mysql/mysql-bin.000009 | /usr/bin/mysql -uroot -p8856769abcd -v hello 插⼊的数据得到了恢复，如图，。

MySQL数据库恢复（使用mysqlbinlog命令）

MySQL数据库恢复（使⽤mysqlbinlog命令）1：开启binlog⽇志记录修改mysql配置⽂件mysql.ini，在[mysqld]节点下添加复制代码代码如下:# log-binlog-bin = E:/log/logbin.log路径中不要包含中⽂和空格。

重启mysql服务。

通过命令⾏停⽌和启动mysql服务复制代码代码如下:c:\>net stop mysql;c:\>net start mysql;进⼊命令⾏进⼊mysql并查看⼆进制⽇志是否已经启动Sql代码复制代码代码如下:mysql>show variables like 'log_%';⽇志成功开启后，会在E:/log/⽬录下创建logbin.index和logbin.000001两个⽂件。

logbin.000001就是数据库的备份⽂件，以后就可以通过此⽂件对数据库进⾏恢复操作。

2：查看备份的⼆进制⽂件Sql代码复制代码代码如下:c:\mysql\bin\>mysqlbinlog e:/log/logbin.000001⽇后记录的操作多了，命令⾏⽅式基本就⽤不上了。

可以使⽤将⽇志导出⽂件的⽅式来查看⽇志内容2.1 导出Xml代码复制代码代码如下:c:\mysql\bin\>mysqlbinlog e:/log/logbin.000001 > e:/log/log.txt">": 导⼊到⽂件中; ">>": 追加到⽂件中如果有多个⽇志⽂件Sql代码复制代码代码如下:c:\mysql\bin\> mysqlbinlog e:/log/logbin.000001 > e:/log/log.sqlc:\mysql\bin\> mysqlbinlog e:/log/logbin.000002 >> e:/log/log.sq2.2 按指定位置导出：Sql代码复制代码代码如下:c:\mysql\bin\>mysqlbinlog --start-position=185 --stop-position=338 e:/log/logbin.000001 > e:/log/log3.txt2.3 按指定时间导出：Xml代码复制代码代码如下:c:\mysql\bin\>mysqlbinlog --start-datetime="2010-01-07 11:25:56" --stop-datetime="2010-01-07 13:23:50"e:/log/logbin.000001 > e:/log/log_by_date22.txt3：从备份恢复数据库做了⼀次更新操作，之后⽇志的内容如下：Sql代码复制代码代码如下:/*!40019 SET @@session.max_insert_delayed_threads=0*/;/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;DELIMITER /*!*/;# at 4#110107 13:23:50 server id 1 end_log_pos 106 Start: binlog v 4, server v 5.1.53-community-log created 110107 13:23:50 at startup# Warning: this binlog is either in use or was not closed properly.ROLLBACK/*!*/;BINLOG 'ZqMmTQ8BAAAAZgAAAGoAAAABAAQANS4xLjUzLWNvbW11bml0eS1sb2cAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABmoyZNEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC'/*!*/;# at 106#110107 13:26:58 server id 1 end_log_pos 185 Query thread_id=44 exec_time=1 error_code=0SET TIMESTAMP=1294378018/*!*/;SET @@session.pseudo_thread_id=44/*!*/;SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1, @@session.unique_checks=1,@@session.autocommit=1/*!*/;SET @@session.sql_mode=1344274432/*!*/;SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;/*!\C utf8 *//*!*/;SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/; SET @@session.lc_time_names=0/*!*/;SET @@session.collation_database=DEFAULT/*!*/;BEGIN/*!*/;# at 185#110107 13:26:58 server id 1 end_log_pos 338 Query thread_id=44 exec_time=1 error_code=0use ncl-interactive/*!*/;SET TIMESTAMP=1294378018/*!*/;UPDATE `t_system_id` SET `id_value`='3000' WHERE (`table_name`='t_working_day')/*!*/;# at 338#110107 13:26:58 server id 1 end_log_pos 365 Xid = 8016COMMIT/*!*/;DELIMITER ;DELIMITER /*!*/;DELIMITER ;# End of log fileROLLBACK /* added by mysqlbinlog */;/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;/*!40019 SET @@session.max_insert_delayed_threads=0*/;/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;DELIMITER /*!*/;# at 4#110107 13:23:50 server id 1 end_log_pos 106 Start: binlog v 4, server v 5.1.53-community-log created 110107 13:23:50 at startup# Warning: this binlog is either in use or was not closed properly.ROLLBACK/*!*/;BINLOG 'ZqMmTQ8BAAAAZgAAAGoAAAABAAQANS4xLjUzLWNvbW11bml0eS1sb2cAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABmoyZNEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC'/*!*/;# at 106#110107 13:26:58 server id 1 end_log_pos 185 Query thread_id=44 exec_time=1 error_code=0SET TIMESTAMP=1294378018/*!*/;SET @@session.pseudo_thread_id=44/*!*/;SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1, @@session.unique_checks=1,@@session.autocommit=1/*!*/;SET @@session.sql_mode=1344274432/*!*/;SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;/*!\C utf8 *//*!*/;SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/; SET @@session.lc_time_names=0/*!*/;SET @@session.collation_database=DEFAULT/*!*/;BEGIN/*!*/;# at 185#110107 13:26:58 server id 1 end_log_pos 338 Query thread_id=44 exec_time=1 error_code=0use ncl-interactive/*!*/;SET TIMESTAMP=1294378018/*!*/;UPDATE `t_system_id` SET `id_value`='3000' WHERE (`table_name`='t_working_day')/*!*/;# at 338#110107 13:26:58 server id 1 end_log_pos 365 Xid = 8016COMMIT/*!*/;DELIMITER ;DELIMITER /*!*/;DELIMITER ;# End of log fileROLLBACK /* added by mysqlbinlog */;/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;3.1 恢复：Sql代码复制代码代码如下:c:\mysql\bin\>mysqlbinlog e:/log/logbin.000001 | mysql -u root -p3.2 按指定位置恢复：Sql代码复制代码代码如下:c:\mysql\bin\>mysqlbinlog --start-position=185 --stop-position=338 e:/log/logbin.000001 | mysql -u root -p3.3 按指定时间恢复：Xml代码复制代码代码如下:c:\mysql\bin\>mysqlbinlog --start-datetime="2010-01-07 11:25:56" --stop-datetime="2010-01-07 13:23:50"e:/log/logbin.000001 | mysql -u root -p3.4 通过导出的脚本⽂件恢复Sql代码复制代码代码如下:c:\mysql\bin\>mysql -e "source e:/log/log.sql"4.其他常⽤操作4.1 查看所有⽇志⽂件Sql代码复制代码代码如下:mysql>show master logs;4.2 当前使⽤的binlog⽂件Sql代码复制代码代码如下:mysql>show binlog events \g;4.3 产⽣⼀个新的binlog⽇志⽂件Sql代码复制代码代码如下:mysql>flush logs;4.4 删除所有⼆进制⽇志，并从新开始记录（注意：reset master命令会删除所有的⼆进制⽇志）Sql代码复制代码代码如下:mysql > flush logs;mysql > reset master;4.5 快速备份数据到sql⽂件Sql代码复制代码代码如下:c:\mysql\bin>mysqldump -u root -p --opt --quick interactive > e:/log/mysqldump.sql为了⽅便查看，把从脚本恢复的命令在写⼀次Sql代码复制代码代码如下:c:\mysql\bin\>mysql -e "source e:/log/mysqldump.sql"。

MySQL通过binlog恢复数据

MySQL通过binlog恢复数据⽬录mysql ⽇志⽂件binlog⽇志binlog⽇志开启⽇志开启⽅式：binlog ⽇志格式binlog⽇志查看⼯具：mysqlbinlog使⽤binlog恢复数据线下实操⼩结mysql ⽇志⽂件任何成熟软件都会有⼀套成熟的⽇志系统，当软件出现问题时，这些⽇志就是查询问题来源的宝库。

同样，mysql也不例外，也会有⼀系列⽇志记录mysql的运⾏状态。

mysql主要有以下⼏种⽇志：错误⽇志：记录mysql运⾏过程中的错误信息⼀般查询⽇志：记录mysql正在运⾏的语句，包括查询、修改、更新等的每条sql慢查询⽇志：记录查询⽐较耗时的SQL语句binlog⽇志：记录数据修改记录，包括创建表、数据更新等这些⽇志均需要在f⽂件进⾏配置，如果不知道mysql的配置⽂件路径，可以使⽤mysql命令进⾏查找，mysql --verbose --help|grep -A 1 'Default options' #该命令会罗列出f顺序查找的路径。

binlog⽇志binlog就是binary log，⼆进制⽇志⽂件，记录所有数据库更新语句，包括表更新和记录更新，即数据操纵语⾔(DML)，binlog 主要⽤于数据恢复和配置主从复制等；数据恢复：当数据库误删或者发⽣不可描述的事情时，可以通过binlog恢复到某个时间点的数据。

主从复制：当有数据库更新之后，主库通过binlog记录并通知从库进⾏更新，从⽽保证主从数据库数据⼀致；mysql按照功能分为服务层模块和存储引擎层模块，服务层负责客户端连接、SQL语句处理优化等操作，存储引擎层负责数据的存储和查询；binlog属于服务层模块的⽇志，即引擎⽆关性，所有数据引擎的数据更改都会记录binlog⽇志。

当数据库发⽣崩溃时，如果使⽤InnoDB引擎，binlog⽇志还可以检验InnoDB的redo⽇志的commit情况。

binlog⽇志开启⽇志开启⽅式：1、添加配置log_bin=ONlog_bin_basename=/path/bin-loglog_bin_index=/path/bin-log.index2、仅仅设置log-bin参数log-bin=/path/bin-log当开启binlog⽇志之后，mysql会创建⼀个 log_bin_index指定的 .index ⽂件和多个⼆进制⽇志⽂件，index中按顺序记录了mysql使⽤的所有binlog⽂件。

MySQL的binlog数据如何查看

MySQL的binlog数据如何查看⼀、binlog介绍binlog,即⼆进制⽇志,它记录了数据库上的所有改变.改变数据库的SQL语句执⾏结束时,将在binlog的末尾写⼊⼀条记录,同时通知语句解析器,语句执⾏完毕.binlog格式基于语句,⽆法保证所有语句都在从库执⾏成功,⽐如update ... limit 1;基于⾏,将每⼀次改动记为binlog中的⼀⾏.在执⾏⼀个特别复杂的update或者delete操作时,基于⾏的格式会有优势.⼆、登录到mysql查看binlog1、只查看第⼀个binlog⽂件的内容show binlog events;2、查看指定binlog⽂件的内容show binlog events in 'mysql-bin.000002';3、查看当前正在写⼊的binlog⽂件show master status\G;4、获取binlog⽂件列表show binary logs;三、⽤mysqlbinlog⼯具查看注意:不要查看当前正在写⼊的binlog⽂件不要加--force参数强制访问如果binlog格式是⾏模式的,请加 -vv参数本地查看binlog⽇志1、基于开始/结束时间mysqlbinlog --start-datetime='2019-02-17 00:00:00' --stop-datetime='2019-02-19 01:01:01' -d 库名⼆进制⽂件mysqlbinlog --start-datetime='2019-03-25 00:00:00' --stop-datetime='2019-03-25 10:00:00' -d silugo var.0013352、基于pos值mysqlbinlog --start-position=107 --stop-position=1000 -d 库名⼆进制⽂件mysqlbinlog --start-position=177 --stop-position=989 -d silugo var.0013353、转换为可读⽂本mysqlbinlog –base64-output=DECODE-ROWS -v -d 库名⼆进制⽂件mysqlbinlog --base64-output=DECODE-ROWS -vv -d silugo var.001335远程查看binlog⽇志1、指定开始/结束时间,并把结果重定向到本地t.binlog⽂件中.mysqlbinlog -u username -p password -h192.168.56.101 -P3306 \--read-from-remote-server --start-datetime='2018-09-10 23:00:00' --stop-datetime='2018-09-10 23:30:00' mysql-bin.000001 > t.binlog。

MySQL数据误删除的快速解决方法（MySQL闪回工具）

MySQL数据误删除的快速解决⽅法（MySQL闪回⼯具）概述Binlog2sql是⼀个Python开发开源的MySQL Binlog解析⼯具，能够将Binlog解析为原始的SQL，也⽀持将Binlog解析为回滚的SQL，去除主键的INSERT SQL，是DBA和运维⼈员数据恢复好帮⼿。

⼀、安装配置1.1 ⽤途数据快速回滚(闪回)主从切换后新master丢数据的修复从binlog⽣成标准SQL，带来的衍⽣功能⽀持MySQL5.6，5.71.2 安装⼆、使⽤⽅法2.1 使⽤前配置2.1.1参数配置[mysqld]server_id = 1log_bin = /var/log/mysql/mysql-bin.logmax_binlog_size = 1Gbinlog_format = rowbinlog_row_image = full2.1.2 user需要的最⼩权限集合select, super/replication client, replication slave建议授权select, super/replication client, replication slave权限说明select：需要读取server端information_schema.COLUMNS表，获取表结构的元信息，拼接成可视化的sql语句super/replication client：两个权限都可以，需要执⾏'SHOW MASTER STATUS', 获取server端的binlog列表replication slave：通过BINLOG_DUMP协议获取binlog内容的权限2.2 基本⽤法2.2.1基本⽤法解析出标准SQLshell> python binlog2sql.py -h127.0.0.1 -P3306 -uadmin -p'admin' -dtest -t test3 test4 --start-file='mysql-bin.000002'输出：INSERT INTO `test`.`test3`(`addtime`, `data`, `id`) VALUES ('2016-12-10 13:03:38', 'english', 4); #start 570 end 736UPDATE `test`.`test3` SET `addtime`='2016-12-10 12:00:00', `data`='中⽂', `id`=3 WHERE `addtime`='2016-12-10 13:03:22' AND `data`='中⽂' AND `id`=3 LIMIT 1; #start 763 end 954DELETE FROM `test`.`test3` WHERE `addtime`='2016-12-10 13:03:38' AND `data`='english' AND `id`=4 LIMIT 1; #start 981 end 1147解析出回滚SQLshell> python binlog2sql.py --flashback -h127.0.0.1 -P3306 -uadmin -p'admin' -dtest -ttest3 --start-file='mysql-bin.000002' --start-position=763 --stop-position=1147输出：INSERT INTO `test`.`test3`(`addtime`, `data`, `id`) VALUES ('2016-12-10 13:03:38', 'english', 4); #start 981 end 1147UPDATE `test`.`test3` SET `addtime`='2016-12-10 13:03:22', `data`='中⽂', `id`=3 WHERE `addtime`='2016-12-10 12:00:00' AND `data`='中⽂' AND `id`=3 LIMIT 1; #start 763 end 9542.2.2 选项mysql连接配置-h host; -P port; -u user; -p password解析模式--stop-never 持续解析binlog。

【MySQL】MySQL回滚工具

【MySQL】MySQL回滚⼯具1、mysqlbinlog把事务从binlog中导出2、从导出的binlog中找到要回滚的事务，去掉第⼀个DML语句前和最后⼀个DML语句后与DML⽆关的binlog信息3、在⽬录中新建⼀个f，把表结构以@1=columns这样的顺序⼀⾏写⼀列4、update回滚⽀持选择条件列和回滚的数据列，把回滚时不需要的条件（列）写到not_used.set和not_used.where中例如：⽂件 f@1=id@2=column_a@3=column_b@4=time⽂件not_used.set##写到这个⽂件⾥⾯的是update回滚时不需要更新的列##例如假设回滚不恢复id列，⽂件中应该如下@1=⽂件not_used.where##写到这个⽂件⾥⾯的是update回滚时条件忽略的列##例如假设回滚时不需要列time和 column_b 作为回滚条件，⽂件中应该如下，顺序不敏感@=3@=4⽂件not_used.values##写到这个⽂件⾥⾯的是delete回滚时不⾃动插⼊的列，例如⾃增列或者TIMESTAMP##例如假设回滚时不需要列 time 和 id 作为回滚条件，⽂件中应该如下，顺序不敏感@4=@1=有的表列⽐较多，写个脚本⾃⼰拼配置⽂件mysql⾥⾯show create table，把结果写到table.txt#!/bin/bashawk'{print $1}' ./table.txt >./table.inin=`wc -l ./table.ini`i=1cat ./table.ini | while read columns_namedoecho""@"$i"="$columns_name" >> ./fi=$[$i+1]donerm -rf ./table.txt ./table.ini然后not_used.where、not_used.set、not_used.values也可以⽤f转换⼀下编辑awk -F '`''{print $1}' f > ./not_used.set脚本：表名⾃⼰写吧#!/bin/bashtable_name="$2"### DELETE DML 2 rows in binlogdelete=2### UPDATE DML 3 rows in binlogupdate=3### How many columns for this rollback tabletable_columns=`wc -l ./f | awk'{print $1}'`### Format binlogecho -e "\033[47;30m wait for change binlog format \033[0m"#cat ./mysql-bin.txt | awk'{$1="";print>"./bin.log"}'echo -e "\033[47;30m change binlog format OK \033[0m"### Count for DMLdml_delete_count=`cat ./bin.log | grep DELETE | wc -l `dml_update_count=`cat ./bin.log | grep UPDATE | wc -l `echo -e "\033[47;30m dml_delete_count $dml_delete_count \033[0m"echo -e "\033[47;30m dml_update_count $dml_update_count \033[0m"### How many rows for one DMLdml_delete_row=`echo |awk'{print "'$delete'"+"'$table_columns'"}'`dml_update_row=`echo |awk'{print "'$update'"+"'$table_columns'"+"'$table_columns'"}'`dml_update_where_row_begin=3dml_update_where_row_finish=`echo |awk'{print 2+"'$table_columns'"}'`dml_update_set_row_begin=`echo |awk'{print 4+"'$table_columns'"}'`dml_update_set_row_finish=$dml_update_rowecho -e "\033[47;30m dml_delete_row $dml_delete_row \033[0m"echo -e "\033[47;30m dml_update_row $dml_update_row \033[0m"fun_delete(){b=''for((i=1;i<=${dml_delete_count};i++))dosed -n '1,'$dml_delete_row'p' ./bin.log > ./bin.tmpsed -i '1,'$delete'd' ./bin.tmpcat ./not_used.values | while read columns_valuesdosed -i '/'$columns_values'/d' ./bin.tmpdonedata=`awk -F '=''{$1="";print}' ./bin.tmp | awk'{print $1}' | tr"\n""," | sed's/,$//' `cp ./f ./dml_columns.tmpcat ./not_used.values | while read columns_valuesdosed -i '/'$columns_values'/d' ./dml_columns.tmpdonedml_columns=`awk -F '=''{print $2}' ./dml_columns.tmp | tr"\n""," | sed's/,$//'`echo"insert into $table_name($dml_columns) values ($data);" >> ./rollback.sqlsed -i '1,'$dml_delete_row'd' ./bin.logrm -rf ./bin.tmp ./sql.tmph=`echo | awk'{print int("'$i'"/"'$dml_delete_count'"*"100%")}'`printf "progress:[$h%%]\r"donerm -rf ./bin.logecho -e "\n"echo done}fun_update(){if [ $dml_update_count -lt 5000 ]thenfile=1elsefile=1000fifile_count=$[${dml_update_count}/${file}]file_mod=$[${dml_update_count}%${file}]file_dml_pos_begin=1file_dml_pos_finish=$[${file_count}*${dml_update_row}]for((f=1;f<=$[${file}+1];f++))dosed -n ''$file_dml_pos_begin','$file_dml_pos_finish'p' ./bin.log > ./bin.log.$frows_no_update_begin=1rows_no_update_finish=$dml_update_rowfor((i=1;i<=${dml_update_count};i++))dosed -n ''$rows_no_update_begin','$rows_no_update_finish'p' ./bin.log.$f > ./bin.tmpsed -n ''$dml_update_set_row_begin','$dml_update_set_row_finish'p' ./bin.tmp > ./bin.wheresed -n ''$dml_update_where_row_begin','$dml_update_where_row_finish'p' ./bin.tmp > ./bin.set### data have been set,and this data make to search for new data in rollback SQL,choose columnscat ./not_used.where | while read columns_wheredosed -i '/'$columns_where'/d' ./bin.wheredonedml_where=`awk'{print $1}' ./bin.where | tr"\n""," | sed's/,$//'`### data will be update,all columns or part of themcat"./not_used.set" | while read columns_setdosed -i '/'$columns_set'/d' ./bin.setdonedml_set=`awk'{print $1}' ./bin.set | tr"\n""," | sed's/,$//'`echo"update $table_name set $dml_set where $dml_where;" >> ./rollback.sql # delete big bin.log too slow# sed -i '1,'$dml_update_row'd' ./bin.logrows_no_update_begin=$[$[${dml_update_row}*${i}]+1]rows_no_update_finish=$[${dml_update_row}*$[${i}+1]]# change columns'namecat ./f | while read t_tmpdot_1="`echo $t_tmp | awk -F '=' '{print $1}'`="t_2="`echo $t_tmp | awk -F '=' '{print $2}'`="sed -i 's/'$t_1'/'$t_2'/g' ./rollback.sqldonedonefile_dml_pos_begin=$[$[${file_count}*${f}*${dml_update_row}]+1]file_dml_pos_finish=$[${file_count}*$[${f}+1]*${dml_update_row}]rm -rf ./bin.log.$fh=`echo | awk'{print int("'$f'"/"'$dml_update_count'"*"100%")}'`printf "progress:[$h%%]\r"echo -e "\n"doneecho done}case $1indelete)echo -e "\033[47;32m begin fun_delete \033[0m";sleep2;fun_delete;;update)echo -e "\033[47;32m begin fun_update \033[0m";sleep2;fun_update;;*)echo -e "\033[47;31m err input,please choose delete or update,quit \033[0m";exit 1 esac。