㈠ mysql binlog可否恢复删除数据
MySQL开启binlog后,写入操作都会记录到二进制日志里,可以使用mysqlbinlog查看/导出/恢复数据.
假设你之内前进行了 mysqlmp全量备份容,和binlog增量备份(在mysqlmp全量备份时使用参数--flush-logs清除全量备份前的binlog).
先恢复之前用mysqlmp进行的全量备份,然后用 mysqlbinlog进行时间点还原:
?
mysql -uroot -prootpwd db_name < db_name.sql
mysqlbinlog --stop-datetime="2013-10-12 12:30:00" /var/log/mysql/mysql-bin.000001 | mysql -uroot -prootpwd
这里假设你的误操作发生在 2013-10-12 12:30:00之后.
如果你既没有进行mysqlmp全量备份,也没有开启binlog安全日志,那真的就悲剧了.
㈡ mysql表误删 怎么恢复 未 开启binlog
mysql binlog没有开启数抄据恢复袭 mysql 不小心误删了一个数据表的数据，通过delete，没有开启binlog，如何才可以恢复数据。MYI MYD文件还是原大校 SQL code? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 MariaDB [(none)]> show varia...
㈢ mysql的binlog可以删除吗
怎么样安全删除mysql下的binlog日志_网络经版验：权
http://jingyan..com/article/60ccbceb11477d64cab197cf.html
㈣ 怎样打开查看mysql binlog
1 在my.ini(window)配置文件里面来
[mysqld]
log-bin=mysql-bin(名字可以随自便起)
我们每次进行操作的时候，File_size都会增长
2、show binlog events
4. 用mysqlbinlog 工具来显示记录的二进制结果，然后导入到文本文件，为了以后的恢复。
详细过程如下：
bin>mysqlbinlog --start-position=4 --stop-position=106 mysqlbin-log.000001 > D:\\test1.txt
或者全部导出:
bin>mysqlbinlog mysqlbin-log.000001 >D:\\test1.txt
㈤ mysql 如何复制表 binlog最小
复制之所以工作得益于MySQL把对数据库的变更都记录在 binlog中，然后主库把它读出来，放到从库上去应用。当然binlog 的用途不仅限于此，比如 PITR等
在5.1.4版本以前，binlog格式只能是 statement -based replication ,在以后的版本中引入了 row-based replication 以及 mixed-based replication。
下面我会简单的介绍一下SBR、RBR、MBR 这三种格式下binlog是如何组织的，更重要的是在这三种格式下，replication是如何进行工作的。当然我主要介绍 RBR模式下的复制，因为RBR模式下我们的复制是认为是最安全的方式，即使是使用MBR也会有可能踩到坑。
在MySQL中，Binlog有两类文件，一类文件用于记录数据变更，一类文件用于记录binlog list。
Binlog list文件就是 ${HOSTNAME}-bin.index ；用于记录当前有哪些binlog
binlog的数据文件名字类似于 ${HOSTNAME}-bin.00001,这类文件是我们重点关注的对象。
先来大概的看看binlog 的文件内容：
svan-mac:mydata xiean$ mysqlbinlog -vvvv mysql-bin.000010
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#151218 15:19:30 server id 5331 end_log_pos 123 CRC32 0xd483743a Start: binlog v 4, server v 5.7.9-log created 151218 15:19:30
# Warning: this binlog is either in use or was not closed properly.
BINLOG '
grNzVg/
oAEjQA
ATp0g9Q=
'/*!*/;
# at 123
#151218 15:19:30 server id 5331 end_log_pos 154 CRC32 0x622c3733 Previous-GTIDs
# [empty]
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
抽一段binlog出来看看：
# at 141
#151218 15:19:30 server id 5331 end_log_pos 245
Query thread_id=3350 exec_time=11 error_code=0
at 141
当前事件在文件中的起始位置，单位bytes
#151218 15:19:30
当前事件开始时间
Server id
当前事件在哪个Server 执行的
End_log_pos
下一个事件在文件中的开始位置，即当前事件内容为 4~end_log_pos-1范围
exec_time
执行所花费的时间(如果是Master )；
error_code
执行该事件时的结果
我们把Binlog 文件拆分成3个部份
简单描述 －－>
{
"header": "desc …",
"event": "xxxxxxx",
"footer": "log rotat"
}
第一部份： 由 4-bytes 开始，这4-bytes 表明它是一个MySQL binlog 文件（由log_event.h 这个文件常量：BINLOG_MAGIC (0xfe 0x62 0x69 0x6e = 0xfe 'b''i''n') 表示），这也就能解释我们的第一个event 为什么 起始位置是 4 了原因了。
第二部份： 一个一个的 event ，每个event 根据binlog版本不同，解释出来的含义有所不同(在MySQL 5.0＋ binlog版本都使用的是 V4版本)
第三部份：也就是文件最后event用于记录log-rotation 事件，表明了接下来的日志将写入哪个文件。
Event 是binlog 记录的最小单位，event 的上一级是event group ，复制或者恢复的时候基于 event group 来重放日志。对于一个组来说，要么都执行， 要么都不执行。而对于DML来说一个 event 包含多个event，而对于DDL 来说，一个event 就是一个 event group。对于每个Event里边有哪些东西，以及event group 是如何划分的我们将在下面讨论。
触发器，存储过程，函数在MySQL里边是如何处理的呢？
触发器，存储过程，函数 在创建的时候都会记录Binlog
触发器在执行的时候 Master、Slave 都会被调用，Master上的触发器将会在Master上被调用，Slave上的触发器将会在Slave上被调用。
存储过程在执行的时候，Master上会被转化成具体的SQL语句存储在Binlog里边，因此在binlog里边是看不到任何 call 来调用存储过程的event 。
函数在执行的时候并不会被解析成为具体的语句，相反函数执行时和触发器比较相像，在Master上和Slave都会被调用。
三种模式下Binlog 是如何记录的
基于语句的复制 ： 是MySQL 5.7.7 版本以前默认配置，它将SQL语句（而不是实际的数据变化）从主服务器复制到从服务器。
优点 ：在某些情况下，最终写入日志文件的数据更少，例如更新或者删除许多行时。对于只影响几行数据的简单语句，基于行的复制占用的空间更少。
缺点 ： 最明显的是它不支持不确定性的语句，例如当前时间函数。
基于行的复制 ： 使用单个的表行记录变化，而不是语句。主服务器将消息，也就是事件写入二进制日志，表示单个表行的变化。这与其他RDBMS中更加传统的复制方式类似。
优点：需要更少的锁定，意味着能够达到更高的并发。
缺点：它会产生更多需要记录的数据，占用的空间大。
混合模式日志 ： 可以根据要记录的事件实时改变二进制日志格式。使用混合模式复制时，默认采用基于语句的复制，但是在某些情况下自动切换到基于行的复制
㈥ mysql怎样通过binlog恢复被恶意删除的数据
1. 以前我错误的认为mysql的日志可以恢复到任何时间的状态，其实并不是这样，这个恢复是有前提的，就是你至少得有一个从日志记录开始后的数据库备份，通过日志恢复数据库实际上只是一个对以前操作的回放过程而已，不用想得太复杂，既然是回放你就得注意了，如果你执行了两次恢复那么就相当于是回放了两次，后果如何你自己应该清楚了吧。
2. 要想通过日志恢复数据库，在你的my.cnf文件里应该有如下的定义，log-bin=mysql-bin，这个是必须的.binlog-do-db=db_test,这个是指定哪些数据库需要日志，如果有多个数据库就每行一个，如果不指定的话默认就是所有数据库.
[mysqld]
log-bin=mysql-bin
binlog-do-db=db_test
binlog-do-db=db_test2
3.删除二进制日志:
a.mysql> system ls -ltr /var/lib/mysql/bintest*;
mysql>reset master(清空所有的二进制日志文件)
b.purge master logs to 'bintest.000006';(删除bintest.000006之前的二进制日志文件)
c.purge master logs before '2007-08-10 04:07:00'(删除该日期之前的日志)
d.在my.cnf 配置文件中[mysqld]中添加:
expire_logs_day=3设置日志的过期天数,过了指定的天数,会自动删除
4.下面就是恢复操作了
特别提示，mysql每次启动都会重新生成一个类似mysql-bin.000003的文件，如果你的mysql每天都要重新启动一次的话，这时候你就要特别注意不要选错日志文件了。
(注意：下面有一些技巧，这些东西才是最宝贵的哟，普通的东东手册上都有，这可是我摸索出来的哟，别人我都不告诉他。
技巧1 :
在下面你将看到 mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd 类似的语句，但是它一次只能操作一个日志文件，如果你变通一下变成这样 mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.0* | mysql -u root -pmypwd 那么它基本上就会表示出的所有的日志文件了，这样可解决你忘记在哪一个日志文件中的问题，当然你也可以用这种写法更完美,mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.[0-9]* | mysql -u root -pmypwd ，看到[0-9]*这个东东了吧，它表示以数字开头的任何字符，方便吧！
技巧2:
你可以通过--one-database 参数选择性的恢复单个数据库，example在下面，爽吧。
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd --one-database db_test
技巧3:
如果你老人家已经使用过 /usr/local/mysql5/bin/mysqlbinlog --start-date="2005-04-20 9:55:00" /var/data/mysql5/mysql-bin.0* > /home/db/tt.sql 类似的语句将日志导成了ASCII文本文件，那么你就可以直接在phpmyadmin或者其它什么乱七糟八的的客户端里执行这个文件文件就行了，因为它本身就是一个标准的sql文件，比如想让文件里面的某些语句不执行，OK，it's easy,找到它们删除即可，然后再放进去执行就OK滴啦！这个可是灰常灰常的爽哟。。。。。。
技巧4:
我来给大家讲一下，下面这条语句都做了什么
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd --one-database db_test
这是把mysql-bin.000001这个二进制文件里的内容转换成ASCII文件(也就是sql语句)，直接通过管道操作符"|"传输给 mysql这个程序，然后过滤掉其它数据库的语句，只在db_test里执行。
技巧5:
着了，多打了一个技巧，现在暂时没内容，等以后再加吧！！！
)
下面部份摘录自网上。
如果MySQL服务器启用了二进制日志，你可以使用mysqlbinlog工具来恢复从指定的时间点开始 (例如，从你最后一次备份)直到现在或另一个指定的时间点的数据。关于启用二进制日志的信息，参见5.11.3节，“二进制日志”。对于 mysqlbinlog的详细信息，参见mysql手册8.6节，“mysqlbinlog：用于处理二进制日志文件的实用工具”。
要想从二进制日志恢复数据，你需要知道当前二进制日志文件的路径和文件名。一般可以从选项文件(即my.cnf or my.ini，取决于你的系统)中找到路径。如果未包含在选项文件中，当服务器启动时，可以在命令行中以选项的形式给出。启用二进制日志的选项为-- log-bin。要想确定当前的二进制日志文件的文件名，输入下面的MySQL语句：
SHOW BINLOG EVENTS G
你还可以从命令行输入下面的内容：
mysql --user=root -pmy_pwd -e 'SHOW BINLOG EVENTS G'
将密码my_pwd替换为服务器的root密码。
1. 指定恢复时间
对于MySQL 4.1.4，可以在mysqlbinlog语句中通过--start-date和--stop-date选项指定DATETIME格式的起止时间。举例说明，假设在今天上午10:00(今天是2005年4月20日)，执行SQL语句来删除一个大表。要想恢复表和数据，你可以恢复前晚上的备份，并输入：
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd
该命令将恢复截止到在--stop-date选项中以DATETIME格式给出的日期和时间的所有数据。如果你没有检测到几个小时后输入的错误的SQL语句，可能你想要恢复后面发生的活动。根据这些，你可以用起使日期和时间再次运行mysqlbinlog：
mysqlbinlog --start-date="2005-04-20 10:01:00" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd
在该行中，从上午10:01登录的SQL语句将运行。组合执行前夜的转储文件和mysqlbinlog的两行可以将所有数据恢复到上午10:00前一秒钟。你应检查日志以确保时间确切。下一节介绍如何实现。
2. 指定恢复位置
也可以不指定日期和时间，而使用mysqlbinlog的选项--start-position和--stop-position来指定日志位置。它们的作用与起止日选项相同，不同的是给出了从日志起的位置号。使用日志位置是更准确的恢复方法，特别是当由于破坏性SQL语句同时发生许多事务的时候。要想确定位置号，可以运行mysqlbinlog寻找执行了不期望的事务的时间范围，但应将结果重新指向文本文件以便进行检查。操作方法为：
mysqlbinlog --start-date="2005-04-20 9:55:00" --stop-date="2005-04-20 10:05:00"
/var/log/mysql/mysql-bin.000001 > /tmp/mysql_restore.sql
该命令将在/tmp目录创建小的文本文件，将显示执行了错误的SQL语句时的SQL语句。你可以用文本编辑器打开该文件，寻找你不要想重复的语句。如果二进制日志中的位置号用于停止和继续恢复操作，应进行注释。用log_pos加一个数字来标记位置。使用位置号恢复了以前的备份文件后，你应从命令行输入下面内容：
mysqlbinlog --stop-position="368312" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd
mysqlbinlog --start-position="368315" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd
上面的第1行将恢复到停止位置为止的所有事务。下一行将恢复从给定的起始位置直到二进制日志结束的所有事务。因为mysqlbinlog的输出包括每个SQL语句记录之前的SET TIMESTAMP语句，恢复的数据和相关MySQL日志将反应事务执行的原时间。
㈦ 如何动态监控mysql binlog
有两种方法，一种方法使用mysql的check table和repair table 的sql语句，另一种方法是使用MySQL提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。
1. check table 和 repair table
登陆mysql 终端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出现的结果说Status是OK，则不用修复，如果有Error，可以用：
repair table tabTest;
进行修复，修复之后可以在用check table命令来进行检查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk适用于MYISAM类型的数据表，而isamchk适用于ISAM类型的数据表。这两条命令的主要参数相同，一般新的系统都使用MYISAM作为缺省的数据表类型，这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用：
myisamchk tablename.MYI
进行检测，如果需要修复的话，可以使用：
myisamchk -of tablename.MYI
关于myisamchk的详细参数说明，可以参见它的使用帮助。需要注意的时在进行修改时必须确保MySQL服务器没有访问这个数据表，保险的情况下是最好在进行检测时把MySQL服务器Shutdown掉。
另外可以把下面的命令放在你的rc.local里面启动MySQL服务器前：
[ -x /tmp/mysql.sock ] && /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI
其中的/tmp/mysql.sock是MySQL监听的Sock文件位置，对于使用RPM安装的用户应该是/var/lib/mysql/mysql.sock，对于使用源码安装则是/tmp/mysql.sock可以根据自己的实际情况进行变更，而pathtochk则是myisamchk所在的位置，DATA_DIR是你的MySQL数据库存放的位置。
需要注意的时，如果你打算把这条命令放在你的rc.local里面，必须确认在执行这条指令时MySQL服务器必须没有启动！检测修复所有数据库(表)
㈧ 如何查看mysql binlog
有两种方法，一种方法使用mysql的check table和repair table 的sql语句，另一种方法是使用MySQL提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。
1. check table 和 repair table
登陆mysql 终端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出现的结果说Status是OK，则不用修复，如果有Error，可以用：
repair table tabTest;
进行修复，修复之后可以在用check table命令来进行检查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk适用于MYISAM类型的数据表，而isamchk适用于ISAM类型的数据表。这两条命令的主要参数相同，一般新的系统都使用MYISAM作为缺省的数据表类型，这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用：
myisamchk tablename.MYI
进行检测，如果需要修复的话，可以使用：
myisamchk -of tablename.MYI
关于myisamchk的详细参数说明，可以参见它的使用帮助。需要注意的时在进行修改时必须确保MySQL服务器没有访问这个数据表，保险的情况下是最好在进行检测时把MySQL服务器Shutdown掉。
㈨ 如何查看mysql binlog中的具体sql语句
基于row模式的binlog，生成DML(insert/update/delete)的rollback语句
通过mysqlbinlog -v 解析binlog生成可读的sql文件
提取需要处理的有效sql
"### "开头的行专.如果输入的start-position位于某属个event group中间，则会导致"无法识别event"错误！
㈩ mysqlbinlog 怎么将数据库恢复到指定的时间
mysqlbinlog 怎么复将数据库恢复制到指定的时间
先用数据备份以norecovery的方式恢复到最近时间点，然後再恢复日志备份(如中间有多份则都用norecovery方式恢复)，最後一份选择特定时间及recovery方式。