MYSQL Binglog分析利器:binlog2sql使用详解

大部分使用mysql的业务也都会开启binlog,用以记录数据库的更新操作。当然binlog的格式大家也都比较清楚,分别是statement、mixed、row模式。针对row格式的binlog,它以二进制形式记录相应的SQL,通过编辑器打开无法知道具体的SQL是什么。当然,我们也可以通过mysqlbinlog分析,但分析结果不利于我们做数据的回滚和redo。前段时间同事分享了一个小工具binlog2sql,觉得蛮有意思,凑着今天有时间装了学习下。
一、 binlog2sql 简介
binlog2sql是一开源工具,其可以从MySQL binlog解析出你要的SQL。根据不同选项,你可以得到原始SQL、回滚SQL、去除主键的INSERT SQL等。
主要用途如下:
(1)数据快速回滚(闪回)
(2)主从切换后数据不一致的修复
(3)从binlog生成标准SQL,带来的衍生功能
二、binlog2sql安装
1、 binlog2sql 下载
https://github.com/danfengcao/binlog2sql
2、 binlog2sql 依赖包安装
python2.6+
PyMySQL==0.7.8+
wheel==0.24.0+
mysql-replication==0.9+
(1)PyMySQL-0.7.10安装
https://pypi.python.org/pypi/PyMySQL/
[root@node1 binlogsql]# tar -xzvf PyMySQL-0.7.10.tar.gz
[root@node1 binlogsql]# cd PyMySQL-0.7.10
[root@node1 PyMySQL-0.7.10]# python setup.py install
(2)wheel-0.30.0a0安装
https://pypi.python.org/pypi/wheel/
[root@node1 binlogsql]# tar -xzvf wheel-0.30.0a0.tar.gz
[root@node1 binlogsql]# cd wheel-0.30.0a0
[root@node1 wheel-0.30.0a0]# python setup.py install
(3)python-mysql-replication安装
https://github.com/noplay/python-mysql-replication
[root@node1 binlogsql]# unzip python-mysql-replication-master.zip
[root@node1 binlogsql]# cd python-mysql-replication-master
[root@node1 python-mysql-replication-master]# python setup.py  install
(4)可以通过pip安装相应的依赖包
https://pypi.python.org/pypi/pip
[root@node1 tools]# tar -xzvf pip-9.0.1.tar.gz
[root@node1 tools]# cd pip-9.0.1
[root@node1 pip-9.0.1]# python setup.py install
[root@node1 binlog2sql-master]# pip install  -r requirements.txt
3、 binlog2sql 安装
直接下载解压缩即可,运行相应的py脚本

[root@node1 tools]# unzip binlog2sql-master.zip
[root@node1 tools]# cd binlog2sql-master
设置别名,方便命令调用:
alias binlog2sql='python /tools/binlogsql/binlog2sql-master/binlog2sql/binlog2sql.py'
三、binlog2sql使用
1、 binlog2sql 帮助手册
[root@node1 binlog2sql]# binlog2sql  --help
usage: binlog2sql.py [-h HOST] [-u USER] [-p PASSWORD] [-P PORT]
                     [--start-file STARTFILE] [--start-position STARTPOS]
                     [--stop-file ENDFILE] [--stop-position ENDPOS]
                     [--start-datetime STARTTIME] [--stop-datetime STOPTIME]
                     [--stop-never] [--help] [-d [DATABASES [DATABASES ...]]]
                     [-t [TABLES [TABLES ...]]] [-K] [-B]

Parse MySQL binlog to SQL you want

optional arguments:
  --stop-never          Wait for more data from the server. default: stop
                        replicate at the last binlog when you start binlog2sql  ## 持续同步binlog。可选。不加则同步至执行命令时最新的binlog位置
  --help                help infomation
  -K, --no-primary-key  Generate insert sql without primary key if exists ## 对INSERT语句去除主键。可选。
  -B, --flashback       Flashback data to start_postition of start_file ## 生成回滚语句,可解析大文件,不受内存限制,每打印一千行加一句SLEEP SELECT(1)。可选。与stop-never或no-primary-key不能同时添加。

connect setting:
  -h HOST, --host HOST  Host the MySQL database server located
  -u USER, --user USER  MySQL Username to log in as
  -p PASSWORD, --password PASSWORD
                        MySQL Password to use
  -P PORT, --port PORT  MySQL port to use

range filter:
  --start-file STARTFILE
                        Start binlog file to be parsed  ## 起始解析文件。必须。
  --start-position STARTPOS, --start-pos STARTPOS ## start-file的起始解析位置。可选。默认为start-file的起始位置。
                        Start position of the --start-file
  --stop-file ENDFILE, --end-file ENDFILE              ##末尾解析文件。可选。默认为start-file同一个文件。若解析模式为stop-never,此选项失效。
                        Stop binlog file to be parsed. default: '--start-file'
  --stop-position ENDPOS, --end-pos ENDPOS    ## stop-file的末尾解析位置。可选。默认为stop-file的最末位置;若解析模式为stop-never,此选项失效。
                        Stop position of --stop-file. default: latest position
                        of '--stop-file'
  --start-datetime STARTTIME
                        Start reading the binlog at first event having a
                        datetime equal or posterior to the argument; the
                        argument must be a date and time in the local time
                        zone, in any format accepted by the MySQL server for
                        DATETIME and TIMESTAMP types, for example: 2004-12-25
                        11:25:56 (you should probably use quotes for your
                        shell to set it properly). ## 从哪个时间点的binlog开始解析,格式必须为datetime,如'2016-11-11 11:11:11'。可选。默认不过滤。
  --stop-datetime STOPTIME
                        Stop reading the binlog at first event having a
                        datetime equal or posterior to the argument; the
                        argument must be a date and time in the local time
                        zone, in any format accepted by the MySQL server for
                        DATETIME and TIMESTAMP types, for example: 2004-12-25
                        11:25:56 (you should probably use quotes for your
                        shell to set it properly).  ## 到哪个时间点的binlog停止解析,格式必须为datetime,如'2016-11-11 11:11:11'。可选。默认不过滤。

schema filter:
  -d [DATABASES [DATABASES ...]], --databases [DATABASES [DATABASES ...]]
                        dbs you want to process  ## 只输出目标db的sql。可选。默认为空。
  -t [TABLES [TABLES ...]], --tables [TABLES [TABLES ...]]
                        tables you want to process  ## 只输出目标tables的sql。可选。默认为空。
2、 binlog2sql要求mysql配置参数需包括以下内容
[mysqld]
log-bin-index = /home/mysql/bin-index
max_binlog_size = 1G
binlog_format = row
binlog_row_image = full
log-bin = /home/mysql/mysql-bin
3、 binlog2sql解析binlog案例
(1)解析某个 binl og 全部内容

点击(此处)折叠或打开

  1. ##构造binlog内容
  2. (root:localhost:Wed Mar 15 11:45:32 2017)[(none)]>flush logs;
  3. Query OK, 0 rows affected (0.00 sec)

  4. (root:localhost:Wed Mar 15 11:45:36 2017)[(none)]>show master status \G
  5. *************************** 1. row ***************************
  6.              File: mysql-bin.000028
  7.          Position: 120
  8.      Binlog_Do_DB:
  9.  Binlog_Ignore_DB:
  10. Executed_Gtid_Set:
  11. 1 row in set (0.00 sec)
  12. (root:localhost:Wed Mar 15 11:45:40 2017)[(none)]>use dbtest;
  13. Database changed
  14. (root:localhost:Wed Mar 15 11:46:53 2017)[dbtest]>show tables;
  15. +------------------+
  16. | Tables_in_dbtest |
  17. +------------------+
  18. | T |
  19. | T1 |
  20. | t |
  21. | t1 |
  22. | t2 |
  23. +------------------+
  24. 5 rows in set (0.00 sec)

  25. (root:localhost:Wed Mar 15 11:46:54 2017)[dbtest]>drop table t1;
  26. Query OK, 0 rows affected (0.00 sec)

  27. (root:localhost:Wed Mar 15 11:46:57 2017)[dbtest]>drop table T;
  28. Query OK, 0 rows affected (0.01 sec)

  29. (root:localhost:Wed Mar 15 11:47:01 2017)[dbtest]>drop table T1;
  30. Query OK, 0 rows affected (0.01 sec)

  31. (root:localhost:Wed Mar 15 11:47:02 2017)[dbtest]>show tables;
  32. +------------------+
  33. | Tables_in_dbtest |
  34. +------------------+
  35. | t |
  36. | t2 |
  37. +------------------+
  38. 2 rows in set (0.00 sec)

  39. (root:localhost:Wed Mar 15 11:47:07 2017)[dbtest]>drop table t2;
  40. Query OK, 0 rows affected (0.00 sec)

  41. (root:localhost:Wed Mar 15 11:47:12 2017)[dbtest]>create table t1 select * from t;
  42. Query OK, 0 rows affected (0.02 sec)
  43. Records: 0 Duplicates: 0 Warnings: 0

  44. (root:localhost:Wed Mar 15 11:47:20 2017)[dbtest]>select * from t;
  45. Empty set (0.00 sec)

  46. (root:localhost:Wed Mar 15 11:47:23 2017)[dbtest]>desc t;
  47. +-------+---------+------+-----+---------+-------+
  48. | Field | Type | Null | Key | Default | Extra |
  49. +-------+---------+------+-----+---------+-------+
  50. | id | int(11) | YES | | NULL | |
  51. +-------+---------+------+-----+---------+-------+
  52. 1 row in set (0.00 sec)

  53. (root:localhost:Wed Mar 15 11:47:27 2017)[dbtest]>insert into t values(1),(2),(3);
  54. Query OK, 3 rows affected (0.01 sec)
  55. Records: 3 Duplicates: 0 Warnings: 0

  56. (root:localhost:Wed Mar 15 11:47:38 2017)[dbtest]>insert into t1 select * from t;
  57. Query OK, 3 rows affected (0.00 sec)
  58. Records: 3 Duplicates: 0 Warnings: 0

  59. (root:localhost:Wed Mar 15 11:47:45 2017)[dbtest]>update t1 set id='11' where id<10;
  60. Query OK, 3 rows affected (0.00 sec)
  61. Rows matched: 3 Changed: 3 Warnings: 0

  62. (root:localhost:Wed Mar 15 11:48:12 2017)[dbtest]>show master status \G
  63. *************************** 1. row ***************************
  64.              File: mysql-bin.000028
  65.          Position: 38968
  66.      Binlog_Do_DB:
  67.  Binlog_Ignore_DB:
  68. Executed_Gtid_Set:
  69. 1 row in set (0.00 sec)
正常语句是:python binlog2sql.py  -h10.1.0.10 -P3306 -udb_user -p'abc.123' -ddbtest  --start-file='mysql-bin.000028'
由于上文做了binlog2sql别名,这里可以通过别名直接调用命令:
[root@node1 binlog2sql]#  binlog2sql -h10.1.0.10 -P3306 -udb_user -p'abc.123' -ddbtest  --start-file='mysql-bin.000028'
USE dbtest;
DROP TABLE `t1` /* generated by server */;
USE dbtest;
DROP TABLE `T` /* generated by server */;
USE dbtest;
DROP TABLE `T1` /* generated by server */;
USE dbtest;
DROP TABLE `t2` /* generated by server */;
USE dbtest;
CREATE TABLE `t1` (
  `id` int(11) DEFAULT NULL
);
INSERT INTO `dbtest`.`t`(`id`) VALUES (1); #start 35104 end 35274 time 2017-03-15 11:47:38
INSERT INTO `dbtest`.`t`(`id`) VALUES (2); #start 35104 end 35274 time 2017-03-15 11:47:38
INSERT INTO `dbtest`.`t`(`id`) VALUES (3); #start 35104 end 35274 time 2017-03-15 11:47:38
INSERT INTO `dbtest`.`t1`(`id`) VALUES (1); #start 36062 end 36233 time 2017-03-15 11:47:45
INSERT INTO `dbtest`.`t1`(`id`) VALUES (2); #start 36062 end 36233 time 2017-03-15 11:47:45
INSERT INTO `dbtest`.`t1`(`id`) VALUES (3); #start 36062 end 36233 time 2017-03-15 11:47:45
UPDATE `dbtest`.`t1` SET `id`=11 WHERE `id`=1 LIMIT 1; #start 36625 end 36812 time 2017-03-15 11:48:12
UPDATE `dbtest`.`t1` SET `id`=11 WHERE `id`=2 LIMIT 1; #start 36625 end 36812 time 2017-03-15 11:48:12
UPDATE `dbtest`.`t1` SET `id`=11 WHERE `id`=3 LIMIT 1; #start 36625 end 36812 time 2017-03-15 11:48:12
(2)解析某几个binlog相应的表t,t1操作记录

点击(此处)折叠或打开

(root:localhost:Wed Mar 15 15:01:01 2017)[dbtest]>flush logs;
Query OK, 0 rows affected (0.00 sec)

(root:localhost:Wed Mar 15 15:01:09 2017)[dbtest]>show master status \G
*************************** 1. row ***************************
             File: mysql-bin.000030
         Position: 120
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)
(root:localhost:Wed Mar 15 15:01:16 2017)[dbtest]>delete from t1;
Query OK, 3 rows affected (0.00 sec)

(root:localhost:Wed Mar 15 15:01:51 2017)[dbtest]>create table t2(id int);
Query OK, 0 rows affected (0.00 sec)

(root:localhost:Wed Mar 15 15:02:03 2017)[dbtest]>insert into t2 select * from t;
Query OK, 3 rows affected (0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
## 特别注 的是 ,如果值解析特定表的sql,DDL全部解析,DML过滤相应的表SQL
[root@node1 mysql]# binlog2sql  -h10.0.1.10  -P3306 -udb_user -p'abc.123' -ddbtest -t t t1 --start-file='mysql-bin.000028' --stop-file='mysql-bin.000030'
USE dbtest;
DROP TABLE `t1` /* generated by server */;
USE dbtest;
DROP TABLE `T` /* generated by server */;
USE dbtest;
DROP TABLE `T1` /* generated by server */;
USE dbtest;
DROP TABLE `t2` /* generated by server */;
USE dbtest;
CREATE TABLE `t1` (
  `id` int(11) DEFAULT NULL
);
INSERT INTO `dbtest`.`t1`(`id`) VALUES (1); #start 36062 end 36233 time 2017-03-15 11:47:45
INSERT INTO `dbtest`.`t1`(`id`) VALUES (2); #start 36062 end 36233 time 2017-03-15 11:47:45
INSERT INTO `dbtest`.`t1`(`id`) VALUES (3); #start 36062 end 36233 time 2017-03-15 11:47:45
UPDATE `dbtest`.`t1` SET `id`=11 WHERE `id`=1 LIMIT 1; #start 36625 end 36812 time 2017-03-15 11:48:12
UPDATE `dbtest`.`t1` SET `id`=11 WHERE `id`=2 LIMIT 1; #start 36625 end 36812 time 2017-03-15 11:48:12
UPDATE `dbtest`.`t1` SET `id`=11 WHERE `id`=3 LIMIT 1; #start 36625 end 36812 time 2017-03-15 11:48:12
DELETE FROM `dbtest`.`t1` WHERE `id`=11 LIMIT 1; #start 10116 end 10287 time 2017-03-15 15:01:51
DELETE FROM `dbtest`.`t1` WHERE `id`=11 LIMIT 1; #start 10116 end 10287 time 2017-03-15 15:01:51
DELETE FROM `dbtest`.`t1` WHERE `id`=11 LIMIT 1; #start 10116 end 10287 time 2017-03-15 15:01:51
USE dbtest;
create table t2(id int);
(3)数据库回滚
##通过-B或者--flashback参数解析回滚的SQL,但从解析内容看,也是只解析DML

[root@node1 mysql]# binlog2sql --flashback   -h10.0.1.10  -P3306 -udb_user -p'abc.123' -ddbtest -tt -tt1  --start-file='mysql-bin.000028' --stop-file='mysql-bin.000030'           
INSERT INTO `dbtest`.`t1`(`id`) VALUES (11); #start 10116 end 10287 time 2017-03-15 15:01:51
INSERT INTO `dbtest`.`t1`(`id`) VALUES (11); #start 10116 end 10287 time 2017-03-15 15:01:51
INSERT INTO `dbtest`.`t1`(`id`) VALUES (11); #start 10116 end 10287 time 2017-03-15 15:01:51
UPDATE `dbtest`.`t1` SET `id`=3 WHERE `id`=11 LIMIT 1; #start 36625 end 36812 time 2017-03-15 11:48:12
UPDATE `dbtest`.`t1` SET `id`=2 WHERE `id`=11 LIMIT 1; #start 36625 end 36812 time 2017-03-15 11:48:12
UPDATE `dbtest`.`t1` SET `id`=1 WHERE `id`=11 LIMIT 1; #start 36625 end 36812 time 2017-03-15 11:48:12
DELETE FROM `dbtest`.`t1` WHERE `id`=3 LIMIT 1; #start 36062 end 36233 time 2017-03-15 11:47:45
DELETE FROM `dbtest`.`t1` WHERE `id`=2 LIMIT 1; #start 36062 end 36233 time 2017-03-15 11:47:45
DELETE FROM `dbtest`.`t1` WHERE `id`=1 LIMIT 1; #start 36062 end 36233 time 2017-03-15 11:47:45
四、知识扩展
1、binlog种类以及其优缺点
参考:

(1)Statement:每一条会修改数据的sql都会记录在binlog中。
    优点:不需要记录每一行的变化,减少了binlog日志量,节约了IO,提高性能。(相比row能节约多少性能与日志量,这个取决于应用的SQL情况,正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量,但是考虑到如果带条件的update操作,以及整表删除,alter表等操作,ROW格式会产生大量日志,因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况,其所产生的日志量会增加多少,以及带来的IO性能问题。)
    缺点:由于记录的只是执行语句,为了这些语句能在slave上正确运行,因此还必须记录每条语句在执行的时候的一些相关信息,以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能,slave可与master上要保持一致会有很多相关问题(如sleep()函数, last_insert_id(),以及user-defined functions(udf)会出现问题).使用以下函数的语句也无法被复制:LOAD_FILE()、UUID()、USER()、FOUND_ROWS()、SYSDATE() (除非启动时启用了 --sysdate-is-now 选项),同时在INSERT ...SELECT 会产生比 RBR 更多的行级锁
(2)Row:不记录sql语句上下文相关信息,仅保存哪条记录被修改。
    优点: binlog中可以不记录执行的sql语句的上下文相关的信息,仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程,或function,以及trigger的调用和触发无法被正确复制的问题
    缺点:所有的执行的语句当记录到日志中的时候,都将以每行记录的修改来记录,这样可能会产生大量的日志内容,比如一条update语句,修改多条记录,则binlog中每一条修改都会有记录,这样造成binlog日志量会很大,特别是当执行alter table之类的语句的时候,由于表结构修改,每条记录都发生改变,那么该表每一条记录都会记录到日志中。
(3)Mixed: 是以上两种level的混合使用,一般的语句修改使用statment格式保存binlog,如一些函数,statement无法完成主从复制的操作,则采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式,也就是在Statement和Row之间选择一种.新版本的MySQL中队row level模式也被做了优化,并不是所有的修改都会以row level来记录,像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句,还是会记录所有行的变更。
2binlog相关配置参数
log_bin:设置此参数表示启用binlog功能,并指定路径名称
log_bin_index:设置此参数是指定二进制索引文件的路径与名称
binlog_do_db:此参数表示只记录指定数据库的二进制日志
binlog_ignore_db:此参数表示不记录指定的数据库的二进制日志
max_binlog_cache_size:此参数表示binlog使用的内存最大的尺寸
binlog_cache_size:此参数表示binlog使用的内存大小,可以通过状态变量binlog_cache_use和binlog_cache_disk_use来帮助测试。
binlog_cache_use:使用二进制日志缓存的事务数量
binlog_cache_disk_use:使用二进制日志缓存但超过binlog_cache_size值并使用临时文件来保存事务中的语句的事务数量
max_binlog_size:Binlog最大值,最大和默认值是1GB,该设置并不能严格控制Binlog的大小,尤其是Binlog比较靠近最大值而又遇到一个比较大事务时,为了保证事务的完整性,不可能做切换日志的动作,只能将该事务的所有SQL都记录进当前日志,直到事务结束
sync_binlog:这个参数直接影响mysql的性能和完整性。sync_binlog=0表示当事务提交后,Mysql仅仅是将binlog_cache中的数据写入Binlog文件,但不执行fsync之类的磁盘 同步指令通知文件系统将缓存刷新到磁盘,而让Filesystem自行决定什么时候来做同步,这个是性能最好的。sync_binlog=n,在进行n次事务提交以后,Mysql将执行一次fsync之类的磁盘同步指令,同志文件系统将Binlog文件缓存刷新到磁盘。Mysql中默认的设置是sync_binlog=0,即不作任何强制性的磁盘刷新指令,这时性能是最好的,但风险也是最大的。一旦系统绷Crash,在文件系统缓存中的所有Binlog信息都会丢失
binlog_format:binlog日志格式,statement/row/mixed
binlog_row_image:其是在5.6之后有的参数,FULL记录每一行的变更,minimal只记录影响后的行,前提是row模式。
3、binlog删除方法
reset master;   ##删除master的binlog
reset slave;    ##删除slave的中继日志,reset slave all
purge master logs before '2016-03-15 10:00:00';  ##删除指定日期以前的日志索引中binlog日志文件
purge master logs to 'binlog.000001';  ##删除指定日志文件的日志索引中binlog日志文件
4、mysqlbinlog解析row模式的binlog日志
mysqlbinlog --base64-output=decode-rows -v --start-datetime='2016-07-13 10:00:00' --stop-datetime='2016-07-13 10:40:00'  mysql-bin.000021
5、主从binlog和relaylog文件内容
主库:
    File: binlog.007247                   ##主库当前写入的binlog文件
    Position: 132941350                ##主库当前写入的binlog文件position
从库:
    Master_Log_File: binlog.007247                    ##从库io thread当前读取的主库binlog文件
    Read_Master_Log_Pos: 100309902               ##从库io thread当前读取的主库binlog文件的position
    Relay_Log_File: mysql-relay-bin.025950          ##从库SQL thread当前写入的relay-log文件
    Relay_Log_Pos: 29008629                           ##从库SQL thread当前写入的replay-log文件的position
    Relay_Master_Log_File: binlog.007243           ##当前执行的replay-log对应的主库binlog文件
    Exec_Master_Log_Pos: 565883515               ##当前执行的binlog文件的position
    Relay_Log_Space: 4395318217                    ##读取与执行的relay-log间隔
    cat relay-log. info                  ##relay-log执行binlog信息
    ./mysql-relay-bin.025950            ##当前SQL thread写入的relay-log文件
    29008629                    ##当前SQL thread写入的relay-log文件的position
    binlog.007243                    ##当前执行的relay-log文件对应的binlog 文件
    565883515                    ##当前执行的relay-log文件对应的binlog 文件的position
    cat master. info                  ##主从同步信息记录文件
    binlog.007247                    ##当前读取的主库binlog文件
    372008635                    ##当前读取的主库binlog文件对应的position

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/27067062/viewspace-2135398/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/27067062/viewspace-2135398/

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: binlog2sql是一种工具,用于将MySQLbinlog日志文件转换为可读的SQL语句,以便进行离线分析和查看。binlogMySQL数据库中的事务日志,记录了数据库中发生的所有数据变更操作。binlog2sql可以将这些变更操作还原成SQL语句,方便用户了解数据库的历史变更情况。 离线指的是在数据库不处于活动状态下进行操作,即在数据库停止或者不可用的情况下使用binlog2sql工具进行分析。这种方式可以避免对数据库正常运行造成影响,并且可以随时进行回溯和查询。 使用binlog2sql离线可以实现一些重要的功能。首先,可以恢复误删数据。当我们误删了一些重要的数据时,通过binlog2sql工具可以还原出删除数据的SQL语句,然后再执行这些SQL语句,就能够将数据恢复回来。其次,可以查看历史变更记录。通过解析binlog日志文件,可以得到所有数据的变更操作,包括插入、更新和删除等操作的SQL语句,方便我们了解数据库的演进和变化。最后,可以进行数据库迁移和同步。通过解析源数据库binlog日志文件,可以生成对应的SQL语句,然后将这些SQL语句执行在目标数据库上,从而实现数据库的迁移和同步。 总之,binlog2sql离线是一种方便的工具,可以帮助我们对数据库进行离线分析和查看。无论是恢复误删的数据、查看历史变更记录还是进行数据库迁移和同步,binlog2sql都可以帮助我们完成这些任务。 ### 回答2: binlog2sql 离线的意思是指在没有网络连接的情况下使用 binlog2sql 工具进行操作。 binlog2sql 是一个用于将 MySQL 数据库binlog 转化为 SQL 语句的工具,可以用于实时同步 MySQL 数据库的变更或者回放数据库的历史操作。一般情况下,binlog2sql 工具是在线工作的,即在数据库正常运行时实时监听 binlog,并将其转化为 SQL 语句。 然而,当没有网络连接时,我们仍然可以使用 binlog2sql 工具。这种情况下,我们需要手动将 MySQL 数据库binlog 文件复制到离线的环境中,并使用 binlog2sql 工具对这些离线的 binlog 文件进行解析和分析。这样,我们就可以获得离线环境下的 SQL 语句,用于还原数据库的操作历史。 离线使用 binlog2sql 的一个常见应用场景是进行数据库备份和恢复。我们可以将线上数据库binlog 文件复制到离线环境,使用 binlog2sql 工具解析生成对应的 SQL 语句,并创建一个新的数据库来还原原始数据库的状态。这对于故障恢复、数据迁移以及数据库版本升级等场景都非常有用。 总结起来,binlog2sql 离线的含义是指在没有网络连接的情况下,手动复制和解析 MySQL 数据库binlog 文件,使用 binlog2sql 工具生成 SQL 语句,从而进行数据库的备份、还原和迁移等操作。 ### 回答3: binlog2sql是一个用于将MySQL二进制日志(binlog)转换为SQL语句的工具。它可以在离线环境中使用,意味着可以在没有网络连接的情况下进行转换操作。 通过binlog2sql,我们可以将MySQL的二进制日志文件转换成可以被理解和查询的SQL语句文件。这对于分析数据库操作记录、恢复数据等任务非常有用。通常情况下,binlog文件是MySQL服务器在执行每个事务时记录的二进制日志文件,它包含了对数据库的所有更改操作。而binlog2sql可以将这些操作转化为SQL语句,以便我们进行进一步的分析和处理。 在离线环境中使用binlog2sql有几个好处。首先,离线环境意味着我们不需要与网络连接,可以在没有外部干扰的情况下进行转换工作。这可以提高转换的速度和准确性。其次,离线环境还可以提供更高的安全性,因为我们不需要将敏感的数据库信息传输到网络上。最后,离线环境也可以方便我们在本地进行数据恢复和分析工作。 总之,binlog2sql是一个功能强大的工具,它可以在离线环境中使用,将MySQL的二进制日志转换为SQL语句,方便我们进行数据分析和恢复工作。它的离线特性使得我们可以在没有网络连接的环境下进行转换操作,提高了效率和安全性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值