主题认识,mysqlbinlog解析出的SQL语句被诠释是怎么回事

MySQL
mysqlbinlog解析出的SQL语句被诠释是怎么回事

MySQL抑制binlog日志中的BINLOG部分

MySQL通过binlog来记录整个数据的更改进程,因而大家纵然有MySQL的binlog日志即可完整的还原数据库。MySQL
binlog日志记录有3种不一致的法门,即:STATEMENT,MIXED,ROW。对于分裂的日志情势,生成的binlog有不一样的记录形式。对于MIXED(部分SQL语句)和ROW情势是以base-64方式记录,会以BINLOG起先,是一段伪SQL,大家得以用利用base64-output参数来抑制其出示。本文对此付出了描述及示范。

至于mysqlbinlog的用法,请参见:使用mysqlbinlog提取二进制日志

 

1、mysqlbinlog之base64-output参数

–base64-output=value

This option determines when events should be displayed encoded as
base-64 strings using BINLOG statements. The option has these
permissible values (not case sensitive):

AUTO (“automatic”) or UNSPEC (“unspecified”) displays BINLOG
statements automatically when necessary (that is, for format description
events and row events). If no –base64-output option is given, the
effect is the same as –base64-output=AUTO. NEVER causes BINLOG
statements not to be displayed. mysqlbinlog exits with an error if a
row event is found that must be displayed using
BINLOG.DECODE-ROWS specifies to mysqlbinlog that you intend
for row events to be decoded and displayed as commented SQL statements
by also specifying the –verbose option. Like NEVER, DECODE-ROWS
suppresses display of BINLOG statements, but unlike NEVER, it
does not exit with an error if a row event is found.

以上描述对于binlog日志中的BINLOG部分,假若要过虑掉须求钦定DECODE-ROWS
以及–verbose选项。

 

The SQL statements produced by –verbose for row events are much more
readable than the corresponding BINLOG statements. However, they do
not correspond exactly to the original SQL statements that generated the
events. The following limitations apply:

–verbose选项可以拿到越来越多的可读消息,可是并不是一个本来的SQL语句(类似的)。

· The original column names are lost and replaced by @N, where
N is a column number.

· Character set information is not available in the binary log, which
affects string column display:

There is no distinction made between corresponding binary and nonbinary
string types (BINARY主题认识,mysqlbinlog解析出的SQL语句被诠释是怎么回事。 and CHAR,997755.com澳门葡京,VARBINARY and VARCHAR,
BLOB and TEXT). The output uses a data type of STRING for
fixed-length strings andVARSTRING for variable-length strings.For
multibyte character sets, the maximum number of bytes per character is
not present in the binary log, so the length for string types is
displayed in bytes rather than in characters. For example, STRING(4)
will be used as the data type for values from either of these column
types:

CHAR(4) CHARACTER SET latin1

CHAR(2) CHARACTER SET ucs2

Due to the storage format for events of type UPDATE_ROWS_EVENT,
UPDATE statements are displayed with theWHERE clause preceding
the SET clause.

Proper interpretation of row events requires the information from the
format description event at the beginning of the binary log. Because
mysqlbinlog does not know in advance whether the rest of the log
contains row events, by default it displays the format description event
using a BINLOG statement in the initial part of the output.

If the binary log is known not to contain any events requiring a
BINLOG statement (that is, no row events), the –base64-output=NEVER
option can be used to prevent this header from being written.

 

② 、演示生成binlog日志

--环境
mysql> show variables like 'version';
+---------------+------------+
| Variable_name | Value      |
+---------------+------------+
| version       | 5.6.12-log |
+---------------+------------+

--如下查询binlog为row记录模式
mysql> show variables like 'binlog_for%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+

mysql> reset master;
Query OK, 0 rows affected (0.01 sec)

mysql> show master status;
+-----------------+----------+--------------+------------------+-------------------+
| File            | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-----------------+----------+--------------+------------------+-------------------+
| APP01bin.000001 |      120 |              |                  |                   |
+-----------------+----------+--------------+------------------+-------------------+

mysql> use test;
Database changed

--创建表t1
mysql> create table t1(id smallint,val varchar(20));
Query OK, 0 rows affected (0.01 sec)

--插入单条记录
mysql> insert into t1 values(1,'robin');
Query OK, 1 row affected (0.00 sec)

--清空表
mysql> truncate table t1;
Query OK, 0 rows affected (0.01 sec)

--查看binlog events
mysql> show binlog events;
+-----------------+-----+-------------+-----------+-------------+----------------------------------------------------------+
| Log_name        | Pos | Event_type  | Server_id | End_log_pos | Info                                                     |
+-----------------+-----+-------------+-----------+-------------+----------------------------------------------------------+
| APP01bin.000001 |   4 | Format_desc |        11 |         120 | Server ver: 5.6.12-log, Binlog ver: 4                    |
| APP01bin.000001 | 120 | Query       |        11 |         238 | use `test`; create table t1(id smallint,val varchar(20)) |
| APP01bin.000001 | 238 | Query       |        11 |         310 | BEGIN                                                    |
| APP01bin.000001 | 310 | Table_map   |        11 |         358 | table_id: 74 (test.t1)                                   |
| APP01bin.000001 | 358 | Write_rows  |        11 |         402 | table_id: 74 flags: STMT_END_F                           |
| APP01bin.000001 | 402 | Xid         |        11 |         433 | COMMIT /* xid=30 */                                      |
| APP01bin.000001 | 433 | Query       |        11 |         517 | use `test`; truncate table t1                            |
+-----------------+-----+-------------+-----------+-------------+----------------------------------------------------------+
7 rows in set (0.00 sec)

--获取binlog位置
mysql> show variables like 'log_bin_basename';
+------------------+--------------------+
| Variable_name    | Value              |
+------------------+--------------------+
| log_bin_basename | /opt/data/APP01bin |
+------------------+--------------------+

③ 、演示提取binlog日志

BINLOG ‘ #以此BINLOG部分是真实的SQL语句,无法见到具体内容<br
>fzcsvbmlaaaamaaaagybaaaaaeoaaaaaaaeabhrlc3qaanqxaaicdwi8aameualg<br=””
>fzcsvb4laaaalaaaajibaaaaaeoaaaaaaaeaagac=””
wbaavyb2jpbv7cujq=”<br” >’=”” *!*=”” ;

#应用-v参数的情事,可以看来大家操作生成的SQL语句了,为insert into
[email protected]等等的花样,借使-vv则输出列的讲述音讯

BINLOG ‘<br
>fzcsvbmlaaaamaaaagybaaaaaeoaaaaaaaeabhrlc3qaanqxaaicdwi8aameualg<br=””
>fzcsvb4laaaalaaaajibaaaaaeoaaaaaaaeaagac=””
wbaavyb2jpbv7cujq=”<br” >’=”” *!*=”” ;

#添加–base64-output=DECODE-ROWS选项来抑制BINLOG的显得,如下大家看不到了BINLOG部分

#此时采取mysqlbinlog做1个不完全復苏

#翻看恢复生机后的结果

 

MySQL通过binlog来记录整个数据的更动进度,由此大家只要有MySQL的binlog日志即可完整的上升数据库。MySQL
bi…

binlog 基本认识

本文转发于:

 

   
MySQL的二进制日志可以说是MySQL最要紧的日记了,它记录了具备的DDL和DML(除了数量查询语句)语句,以事件方式记录,还富含语句所举办的花费的年华,MySQL的二进制日志是事情安全型的。

binlog 基本认识

一网友举报使用mysqlbinlog解析出的二进制日志中的内容中,有些SQL语句有#表明的状态,这一个是怎么回事呢?大家经过试验来询问一下切实可行细节情状,如下所示,实验环境为5.6.20-enterprise-commercial-advanced-log

    一般的话开启二进制日志大概会有1%的习性损耗(参见MySQL官方中文手册
5.1.24版)。二进制有多少个最首要的使用处境:

   
MySQL的二进制日志可以说是MySQL最关键的日记了,它记录了具备的DDL和DML(除了数据查询语句)语句,以事件格局记录,还含有语句所推行的费用的年月,MySQL的二进制日志是事情安全型的。

 

   
其一:MySQLReplication在Master端开启binlog,Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目标。

    一般的话开启二进制日志大概会有1%的性格损耗(参见MySQL官方普通话手册
5.1.24版)。二进制有多个最根本的行使情形:

 

    其二:自然就是数据復苏了,通过拔取mysqlbinlog工具来使復苏数据。

    其一:MySQL
Replication在Master端开启binlog,Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目标。

#
whereis mysqlbinlog

   
二进制日志包括两类公事:二进制日志索引文件(文件名后缀为.index)用于记录全数的二进制文件,二进制日志文件(文件名后缀为.00000*)记录数据库全数的DDL和DML(除了数据查询语句)语句事件。

    其二:自然就是数据恢复生机了,通过应用mysqlbinlog工具来使复苏数据。

mysqlbinlog:
/usr/bin/mysqlbinlog /usr/share/man/man1/mysqlbinlog.1.gz

一、开启binlog日志:

   
二进制日志包蕴两类公事:二进制日志索引文件(文件名后缀为.index)用于记录所有的二进制文件,二进制日志文件(文件名后缀为.00000*)记录数据库全体的DDL和DML(除了数量查询语句)语句事件。

 

    vi编辑打开mysql配置文件

一、开启binlog日志:

大家先在参数文件my.cnf里面设置binlog_format=ROW
,然后重启一下MySQL服务

    # vi /usr/local/mysql/etc/my.cnf    在[mysqld] 区块

    vi编辑打开mysql配置文件

 

    设置/添加log-bin=mysql-bin  确认是开拓状态(值mysql-bin
是日记的基本名或前缀名);

    # vi /usr/local/mysql/etc/my.cnf

 

    重启mysqld服务使配置生效

    在[mysqld] 区块

mysql> show variables like 'binlog_format';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW   |

+---------------+-------+

1 row in set (0.00 sec)

 

mysql> show master status;

+----------------------+----------+--------------+------------------+-------------------+

| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

+----------------------+----------+--------------+------------------+-------------------+

| DB-Server-bin.000005 |      512 |              |                  |                   |

+----------------------+----------+--------------+------------------+-------------------+

1 row in set (0.00 sec)

 

mysql> 

 

 

 

mysql> drop table kkk;

Query OK, 0 rows affected (0.01 sec)

 

mysql> create table kkk (id int ,name varchar(32));

Query OK, 0 rows affected (0.02 sec)

 

mysql> insert into kkk

    -> select 100, 'name' union all

    -> select 200, 'kerry' union all

    -> select 300, 'k3';

Query OK, 3 rows affected (0.02 sec)

Records: 3  Duplicates: 0  Warnings: 0

 

mysql> 

    # pkill mysqld# /usr/local/mysql/bin/mysqld_safe –user=mysql
&二 、也可登录mysql服务器,通过mysql的变量配置表,查看二进制日志是还是不是已开启
单词:variable[ˈvɛriəbəl] 变量

    设置/添加 log-bin=mysql-bin  确认是开辟状态(值 mysql-bin
是日记的基本名或前缀名);

 

    登录服务器

    重启mysqld服务使配置生效

暗中认同意况下只美观到局地由此base-64编码的音信,如下所示:

    # /usr/local/mysql/bin/mysql -uroot -p123456mysql> show
variables like ‘log_%’;

    # pkill mysqld

 

   
+—————————————-+—————————————+ 
  | Variable_name                          | Value                     
          |   
+—————————————-+—————————————+ 
  | log_bin                                | ON                       
            | ——> ON表示已经开启binlog日志

    # /usr/local/mysql/bin/mysqld_safe –user=mysql &

[root@DB-Server
~]# /usr/bin/mysqlbinlog 
/data/mysql/DB-Server-bin.000005

    | log_bin_basename                      |
/usr/local/mysql/data/mysql-bin      |    | log_bin_index             
            | /usr/local/mysql/data/mysql-bin.index |    |
log_bin_trust_function_creators        | OFF                       
          |    | log_bin_use_v1_row_events              | OFF     
                            |    | log_error                           
  | /usr/local/mysql/data/martin.err      |    | log_output           
                |FILE|    | log_queries_not_using_indexes          |
OFF                                  |    | log_slave_updates         
            | OFF                                  |    |
log_slow_admin_statements              | OFF                         
        |    | log_slow_slave_statements              | OFF         
                        |    |
log_throttle_queries_not_using_indexes | 0                         
          |    | log_warnings                          | 1             
                      |   
+—————————————-+—————————————+三 、常用binlog日志操作命令

贰 、也可登录mysql服务器,通过mysql的变量配置表,查看二进制日志是还是不是已开启
单词:variable[ˈvɛriəbəl] 变量

 

    1.查看全体binlog日志列表

    登录服务器

 

      mysql> show master logs;

    # /usr/local/mysql/bin/mysql -uroot -p123456

 

   
2.翻看master状态,即最后(最新)三个binlog日志的数码名称,及其最后三个操作事件pos截止点(Position)值

    mysql> show variables like ‘log_%’;

use `MyDB`/*!*/;

SET TIMESTAMP=1530288296/*!*/;

DROP TABLE `kkk` /* generated by server */

/*!*/;

# at 628

#180629 12:05:14 server id 1  end_log_pos 745 CRC32 0xc6037a3f  Query   thread_id=3     exec_time=0     error_code=0

SET TIMESTAMP=1530288314/*!*/;

create table kkk (id int ,name varchar(32))

/*!*/;

# at 745

#180629 12:06:07 server id 1  end_log_pos 817 CRC32 0x74fd4efb  Query   thread_id=3     exec_time=0     error_code=0

SET TIMESTAMP=1530288367/*!*/;

BEGIN

/*!*/;

# at 817

#180629 12:06:07 server id 1  end_log_pos 866 CRC32 0xfb1391dd  Table_map: `MyDB`.`kkk` mapped to number 73

# at 866

#180629 12:06:07 server id 1  end_log_pos 930 CRC32 0xecb4e812  Write_rows: table id 73 flags: STMT_END_F

 

BINLOG '

71g2WxMBAAAAMQAAAGIDAAAAAEkAAAAAAAEABE15REIAA2trawACAw8CYAAD3ZET+w==

71g2Wx4BAAAAQAAAAKIDAAAAAEkAAAAAAAEAAgAC//xkAAAABG5hbWX8yAAAAAVrZXJyefwsAQAA

AmszEui07A==

'/*!*/;

# at 930

#180629 12:06:07 server id 1  end_log_pos 961 CRC32 0x7ca988e3  Xid = 37

COMMIT/*!*/;

DELIMITER ;

# End of log file

ROLLBACK /* added by mysqlbinlog */;

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

      mysql> show master status;

997755.com澳门葡京 1

 

    3.刷新log日志,自此刻发轫发生叁个新编号的binlog日志文件

叁 、常用binlog日志操作命令

mysqlbinlog有贰个参数–verbose(或-v),将自动生成带注释的SQL语句(在行事件中重构伪SQL语句),其实那些不要原始SQL语句,而是伪SQL,假如使用这一个参数五次(如-v
-v),则输出列的描述消息,会生成字段的档次、长度、是还是不是为null等个性音讯:

      mysql>flush logs;

    1.查看全部binlog日志列表

 

     
注:每当mysqld服务重启时,会活动执行此命令,刷新binlog日志;在mysqldump备份数据时加
-F 选项也会刷新binlog日志;

      mysql> show master logs;

-v,
–verbose      
Reconstruct pseudo-SQL statements out of row events. -v  -v adds comments
on column data types.

    4.重置(清空)所有binlog日志

   
2.查看master状态,即最终(最新)一个binlog日志的编号名称,及其最终叁个操作事件pos截止点(Position)值

 

      mysql>reset master;

      mysql> show master status;

[root@DB-Server
~]# /usr/bin/mysqlbinlog -v /data/mysql/DB-Server-bin.000005

肆 、查看某些binlog日志内容,常用有二种办法:

    3.刷新log日志,自此刻开班发出三个新编号的binlog日志文件

 

    1.使用mysqlbinlog自带查看命令法:

      mysql> flush logs;

997755.com澳门葡京 2

      注: binlog是二进制文件,普通文书查看器cat more
vi等都不可以开拓,必须选择自带的 mysqlbinlog 命令查看

     
注:每当mysqld服务重启时,会活动执行此命令,刷新binlog日志;在mysqldump备份数据时加
-F 选项也会刷新binlog日志;

 

         
binlog日志与数据库文件在同目录中(作者的环境安插安装是采纳在/usr/local/mysql/data中)

    4.重置(清空)所有binlog日志

如上所示,其实那里的SQL语句不是原始SQL语句,那么是或不是见到原始SQL语句呢?答案是足以,然而必须安装系统变量binlog_rows_query_log_events

      在MySQL5.5之下版本采纳mysqlbinlog命令时假设报错,就增长“–no-defaults”选项

      mysql> reset master;

 

      # /usr/local/mysql/bin/mysqlbinlog
/usr/local/mysql/data/mysql-bin.000013        下边截取三个片段分析:

④ 、查看有些binlog日志内容,常用有二种方法:

mysql> show variables like 'binlog_rows_query_log_events';

+------------------------------+-------+

| Variable_name                | Value |

+------------------------------+-------+

| binlog_rows_query_log_events | OFF   |

+------------------------------+-------+

1 row in set (0.00 sec)

 

mysql> set binlog_rows_query_log_events=1;

Query OK, 0 rows affected (0.00 sec)

 

mysql> flush logs;

Query OK, 0 rows affected (0.01 sec)

 

mysql>  show master status;

+----------------------+----------+--------------+------------------+-------------------+

| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

+----------------------+----------+--------------+------------------+-------------------+

| DB-Server-bin.000026 |      120 |              |                  |                   |

+----------------------+----------+--------------+------------------+-------------------+

1 row in set (0.00 sec)

 

mysql>

mysql> insert into kkk select 600, 'k600';

Query OK, 1 row affected (0.00 sec)

Records: 1  Duplicates: 0  Warnings: 0

       
…………………………………………………………………….#
at 552#131128 17:50:46 server id 1  end_log_pos 665  Query 
thread_id=11    exec_time=0    error_code=0
—->执行时间:17:50:46;pos点:665SET TIMESTAMP=1385632246/*!*/;

    1.拔取mysqlbinlog自带查看命令法:

 

        update zyyshop.stu set name=’李四’ where id=4             
—->执行的SQL

      注: binlog是二进制文件,普通文书查看器cat more
vi等都无法开拓,必须利用自带的 mysqlbinlog 命令查看

[root@DB-Server
~]# /usr/bin/mysqlbinlog 
–base64-output=DECODE-ROWS  -v -v
/data/mysql/DB-Server-bin.000026

        /*!*/;

         
binlog日志与数据库文件在同目录中(小编的环境计划安装是选项在/usr/local/mysql/data中)

 

        # at 665#131128 17:50:46 server id 1  end_log_pos 692  Xid =
1454 —->执行时间:17:50:46;pos点:692
……………………………………………………………………. 
      注: server id 1    数据库主机的服务号;

      在MySQL5.5以下版本接纳mysqlbinlog命令时倘使报错,就增进“–no-defaults”选项

997755.com澳门葡京 3

            end_log_pos 665 pos点

      # /usr/local/mysql/bin/mysqlbinlog
/usr/local/mysql/data/mysql-bin.000013

 

            thread_id=11    线程号

        上面截取二个有个别分析:

 

   
2.方面那种方法读取出binlog日志的全文内容较多,不便于辨别查看pos点消息,那里介绍一种特别有利于的查询命令:

       
…………………………………………………………………….

 

      mysql> show binlog events [IN ‘log_name’] [FROMpos]
[LIMIT [offset,] row_count];

        # at 552

 

            选项解析:

        #131128 17:50:46 server id 1  end_log_pos 665  Query 
thread_id=11    exec_time=0    error_code=0
—->执行时间:17:50:46;pos点:665

在二进制日志格式为MIXED形式下,简单测试没有察觉SQL被诠释的气象,记录的都以固有的SQL语句。不知晓是不是留存某个特殊处境也会出现那种情景。网友反映腾讯云的MySQL在MIXED方式下,也会现出那种气象,不过尚未动用过腾讯的MySQL,手头也从不测试环境,只好作罢!

              IN ‘log_name’ 
钦定要查询的binlog文件名(不点名就是第柒个binlog文件)

        SET TIMESTAMP=1385632246/*!*/;

              FROM pos       
指定从哪些pos开始点开始查起(不点名就是从整个文件第二个pos点早先算)

        update zyyshop.stu set name=’李四’ where id=4             
—->执行的SQL

              LIMIT [offset,] 偏移量(不点名就是0)

        /*!*/;

              row_count      查询总条数(不点名就是全体行)

        # at 665

            截取部分查询结果:

        #131128 17:50:46 server id 1  end_log_pos 692  Xid = 1454
—->执行时间:17:50:46;pos点:692

            *************************** 20.
row ***************************             
  Log_name:mysql-bin.000021 
———————————————->
查询的binlog日志文件名

       
…………………………………………………………………….

                    Pos: 11197
———————————————————->
pos起始点:              Event_type: Query
———————————————————->
事件类型:Query

        注: server id 1    数据库主机的服务号;

              Server_id: 1
————————————————————–>
标识是由哪台服务器执行的

            end_log_pos 665 pos点

            End_log_pos: 11308
———————————————————->
pos结束点:11308(即:下行的pos起始点)

            thread_id=11    线程号

                    Info:use`zyyshop`; INSERT INTO `team2` VALUES
(0,345,’asdf8er5′) —> 执行的sql语句

   
2.上边那种方法读取出binlog日志的全文内容较多,不便于辨别查看pos点新闻,那里介绍一种特别有利的查询命令:

            *************************** 21.
row ***************************             
  Log_name:mysql-bin.000021Pos: 11308
———————————————————->
pos起始点:11308(即:上行的pos结束点)

      mysql> show binlog events [IN ‘log_name’] [FROM pos]
[LIMIT [offset,] row_count];

              Event_type: Query

            选项解析:

              Server_id: 1            End_log_pos: 11417             
      Info:use`zyyshop`;/*!40000 ALTER TABLE `team2` ENABLE KEYS
*/*************************** 22. row
***************************               
Log_name:mysql-bin.000021Pos: 11417              Event_type: Query

              IN ‘log_name’ 
指定要查询的binlog文件名(不指定就是第3个binlog文件)

              Server_id: 1            End_log_pos: 11510             
      Info:use`zyyshop`; DROP TABLEIF EXISTS `type`

              FROM pos       
钦命从哪些pos初始点开头查起(不点名就是从整个文件第1个pos点开端算)

     
这条语句可以将钦点的binlog日志文件,分成有效事件行的办法赶回,并可利用limit钦命pos点的起初偏移,查询条数;

              LIMIT [offset,] 偏移量(不钦赐就是0)

      A.查询第三个(最早)的binlog日志:

              row_count      查询总条数(不钦赐就是全数行)

        mysql> show binlog events\G;

            截取部分查询结果:

      B.钦赐询问mysql-bin.000021 这么些文件:

            *************************** 20.
row ***************************

        mysql> show binlog events in ‘mysql-bin.000021’\G;

           Log_name: mysql-bin.000021 
———————————————->
查询的binlog日志文件名

      C.钦定查询mysql-bin.000021 那几个文件,从pos点:8224开首查起:

                    Pos: 11197
———————————————————->
pos起始点:

        mysql> show binlog events in ‘mysql-bin.000021’ from 8224\G;

              Event_type: Query
———————————————————->
事件类型:Query

      D.钦赐询问mysql-bin.000021
这些文件,从pos点:8224先导查起,查询10条

              Server_id: 1
————————————————————–>
标识是由哪台服务器执行的

        mysql> show binlog events in ‘mysql-bin.000021’ from 8224
limit 10\G;

            End_log_pos: 11308
———————————————————->
pos结束点:11308(即:下行的pos起始点)

      E.钦赐询问mysql-bin.000021
那些文件,从pos点:8224上马查起,偏移2行,查询10条

                    Info: use `zyyshop`; INSERT INTO `team2` VALUES
(0,345,’asdf8er5′) —> 执行的sql语句

        mysql> show binlog events in ‘mysql-bin.000021’ from 8224
limit 2,10\G;

            *************************** 21.
row
**********************************************

⑤ 、苏醒binlog日志实验(zyyshop是数据库)

                Log_name: mysql-bin.000021

    1.要是现行是凌晨4:00,笔者的安插职务开端履行二次完整的数据库备份:

                    Pos: 11308
———————————————————->
pos起始点:11308(即:上行的pos结束点)

      将zyyshop数据库备份到 /root/BAK.zyyshop.sql 文件中:

              Event_type: Query

      # /usr/local/mysql/bin/mysqldump -uroot -p123456 -lF
–log-error=/root/myDump.err -B zyyshop >
/root/BAK.zyyshop.sql……       
大致过了若干分钟,备份完结了,作者决不操心数据丢失了,因为我有备份了,嘎嘎~~~ 
   
由于本身利用了-F选项,当备份工作刚起始时系统会刷新log日志,爆发新的binlog日志来记录备份之后的数据库“增删改”操作,查看一下:

              Server_id: 1

      mysql> show master status;

            End_log_pos: 11417

      +——————+———-+————–+——————+ 
    |File| Position | Binlog_Do_DB | Binlog_Ignore_DB |     
+——————+———-+————–+——————+     
|mysql-bin.000023 |      120 |              |                  |     
+——————+———-+————–+——————+     
相当于说, mysql-bin.000023
是用来记录4:00随后对数据库的兼具“增删改”操作。

                    Info: use `zyyshop`; /*!40000 ALTER TABLE
`team2` ENABLE KEYS */

    2.早9:00上班了,业务的急需会对数据库进行种种“增删改”操作~~~     
@ 比如:创制八个学员表并插入、修改了多少等等:

            *******
*************************** 22. row
*********************************************************

        CREATE TABLE IF NOT EXISTS `tt` (

                Log_name: mysql-bin.000021

          `id` int(10) unsigned NOTNULLAUTO_INCREMENT,         
`name` varchar(16) NOTNULL,          `sex` enum(‘m’,’w’)
NOTNULLDEFAULT’m’,          `age` tinyint(3) unsigned NOTNULL,       
  `classid` char(6)DEFAULTNULL,          PRIMARY KEY (`id`)

                         Pos: 11417

        ) ENGINE=InnoDBDEFAULTCHARSET=utf8;

              Event_type: Query

      导入实验数据

              Server_id: 1

      mysql> insert into
zyyshop.tt(`name`,`sex`,`age`,`classid`)
values(‘yiyi’,’w’,20,’cls1′),(‘xiaoer’,’m’,22,’cls3′),(‘zhangsan’,’w’,21,’cls5′),(‘lisi’,’m’,20,’cls4′),(‘wangwu’,’w’,26,’cls6′);

            End_log_pos: 11510

      查看数据

                            Info: use `zyyshop`; DROP TABLE IF EXISTS
`type`

      mysql> select * from zyyshop.tt;

     
那条语句可以将点名的binlog日志文件,分成有效事件行的法门赶回,并可采取limit钦赐pos点的初步偏移,查询条数;

      +—-+———-+—–+—–+———+      | id | name    | sex
| age | classid |      +—-+———-+—–+—–+———+      |  1
| yiyi    | w  |  20 | cls1    |      |  2 | xiaoer  | m  |  22 | cls3 
  |      |  3 | zhangsan | w  |  21 | cls5    |      |  4 | lisi    | m 
|  20 | cls4    |      |  5 | wangwu  | w  |  26 | cls6    |     
+—-+———-+—–+—–+———+     
清晨时光又举办了改动数据操作

      A.查询第一个(最早)的binlog日志:

      mysql> update zyyshop.tt set name=’李四’ where id=4;

        mysql> show binlog events\G;

      mysql> update zyyshop.tt set name=’小二’ where id=2;

      B.内定询问 mysql-bin.000021 那么些文件:

      修改后的结果:

        mysql> show binlog events in ‘mysql-bin.000021’\G;

      mysql> select * from zyyshop.tt;

      C.钦点查询 mysql-bin.000021 那个文件,从pos点:8224起始查起:

      +—-+———-+—–+—–+———+      | id | name    | sex
| age | classid |      +—-+———-+—–+—–+———+      |  1
| yiyi    | w  |  20 | cls1    |      |  2 | 小二    | m  |  22 | cls3 
  |      |  3 | zhangsan | w  |  21 | cls5    |      |  4 | 李四    | m 
|  20 | cls4    |      |  5 | wangwu  | w  |  26 | cls6    |     
+—-+———-+—–+—–+———+     
假设此时是晚上18:00,莫名地履行了一条悲催的SQL语句,整个数据库都没了:

        mysql> show binlog events in ‘mysql-bin.000021’ from 8224\G;

      mysql> drop database zyyshop;

      D.钦赐询问 mysql-bin.000021
这几个文件,从pos点:8224开始查起,查询10条

   
3.此刻杯具了,别慌!先仔细翻看最终一个binlog日志,并记录下第①的pos点,到底是哪个pos点的操作导致了数据库的毁伤(经常在最终几步);

        mysql> show binlog events in ‘mysql-bin.000021’ from 8224
limit 10\G;

      备份一下最后三个binlog日志文件:

      E.钦点询问 mysql-bin.000021
那一个文件,从pos点:8224从头查起,偏移2行,查询10条

      # ll /usr/local/mysql/data | grep mysql-bin# cp -v
/usr/local/mysql/data/mysql-bin.000023 /root/     
此时履行一遍刷新日志索引操作,重新初叶新的binlog日志记录文件,理论说
mysql-bin.000023
这几个文件不会再有持续写入了(便于我们解析原因及寻找pos点),以后全部数据库操作都会写入到下二个日记文件;

        mysql> show binlog events in ‘mysql-bin.000021’ from 8224
limit 2,10\G;

      mysql>flush logs;

五 、复苏binlog日志实验(zyyshop是数据库)

      mysql> show master status;

    1.若是现行是凌晨4:00,作者的布置职务最先施行1次完整的数据库备份:

    4.读取binlog日志,分析难题

      将zyyshop数据库备份到 /root/BAK.zyyshop.sql 文件中:

      方式一:使用mysqlbinlog读取binlog日志:

      # /usr/local/mysql/bin/mysqldump -uroot -p123456 -lF
–log-error=/root/myDump.err -B zyyshop > /root/BAK.zyyshop.sql

        # /usr/local/mysql/bin/mysqlbinlog 
/usr/local/mysql/data/mysql-bin.000023     
形式二:登录服务器,并查看(推荐):

        ……

        mysql> show binlog events in ‘mysql-bin.000023’;

       
差不离过了若干分钟,备份落成了,小编绝不顾虑数据丢失了,因为小编有备份了,嘎嘎~~~

        以下为末段片段:

     
由于自家使用了-F选项,当备份工作刚开始时系统会刷新log日志,暴发新的binlog日志来记录备份之后的数据库“增删改”操作,查看一下:

       
+——————+——+————+———–+————-+————————————————————+ 
      | Log_name        |Pos| Event_type | Server_id | End_log_pos
| Info                                                      |       
+——————+——+————+———–+————-+————————————————————+ 
      |mysql-bin.000023 |  922 | Xid        |        1 |        953 |
COMMIT/* xid=3820 */|        |mysql-bin.000023 |  953 | Query      | 
      1 |        1038 | BEGIN                                           
          |        |mysql-bin.000023 | 1038 | Query      |        1 |   
    1164 |use`zyyshop`; update zyyshop.tt set name=’李四’ where id=4| 
      |mysql-bin.000023 | 1164 | Xid        |        1 |        1195 |
COMMIT/* xid=3822 */|        |mysql-bin.000023 | 1195 | Query      | 
      1 |        1280 | BEGIN                                           
          |        |mysql-bin.000023 | 1280 | Query      |        1 |   
    1406 |use`zyyshop`; update zyyshop.tt set name=’小二’ where id=2| 
      |mysql-bin.000023 | 1406 | Xid        |        1 |        1437 |
COMMIT/* xid=3823 */|        |mysql-bin.000023 | 1437 | Query      | 
      1 |        1538 | drop database zyyshop                           
          |       
+——————+——+————+———–+————-+————————————————————+ 
      通过分析,造成数据库破坏的pos点区间是介于 1437–1538
之间,只要苏醒到1437前就可。

      mysql> show master status;

    5.现行把凌晨备份的数据恢复生机:

      +——————+———-+————–+——————+

      # /usr/local/mysql/bin/mysql -uroot -p123456 -v <
/root/BAK.zyyshop.sql;      注:
至此甘休当日黎明先生(4:00)前的备份数据都过来了。

      | File            | Position | Binlog_Do_DB | Binlog_Ignore_DB
|

         
但今日一整天(4:00–18:00)的数量怎么做吧?就得以前文提到的mysql-bin.000023
新日志做作品了……    6.从binlog日志恢复生机数据

      +——————+———-+————–+——————+

      恢复生机语法格式:

      | mysql-bin.000023 |      120 |              |                  |

      # mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名 
      常用选项:

      +——————+———-+————–+——————+

          –start-position=953                  起始pos点

      约等于说, mysql-bin.000023
是用来记录4:00从此对数据库的具有“增删改”操作。

          –stop-position=1437                  结束pos点

    2.早9:00上班了,业务的需要会对数据库举办各类“增删改”操作~~~

          –start-datetime=”二〇一三-11-29 13:18:54″ 初始时间点

      @ 比如:成立三个学生表并插入、修改了数据等等:

          –stop-datetime=”2013-11-29 13:21:53″  为止时间点

        CREATE TABLE IF NOT EXISTS `tt` (

          –database=zyyshop                   
钦命只回复zyyshop数据库(一台主机上频仍有五个数据库,只限本地log日志)

          `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

        不常用选项:   

          `name` varchar(16) NOT NULL,

          -u –user=name              Connect to the remote
serverasusername.连接到远程主机的用户名

          `sex` enum(‘m’,’w’) NOT NULL DEFAULT ‘m’,

          -p –password[=name]        Password to connect to remote
server.连接到远程主机的密码

          `age` tinyint(3) unsigned NOT NULL,

          -h –host=name              Get the binlog from
server.从远程主机上获取binlog日志

          `classid` char(6) DEFAULT NULL,

          –read-from-remote-server  Read binary logs from
aMySQLserver.从有些MySQL服务器上读取binlog日志

          PRIMARY KEY (`id`)

     
小结:实际是将读出的binlog日志内容,通过管道符传递给mysql命令。这几个命令、文件尽量写成相对路径;

        ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

      A.完全復苏(本例不可信赖,因为最后那条 drop database zyyshop
也在日记里,必须想办法把这条破坏语句排除掉,做一些恢复生机)

      导入实验数据

        # /usr/local/mysql/bin/mysqlbinlog 
/usr/local/mysql/data/mysql-bin.000021 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop      B.内定pos为止点过来(部分苏醒):

      mysql> insert into
zyyshop.tt(`name`,`sex`,`age`,`classid`)
values(‘yiyi’,’w’,20,’cls1′),(‘xiaoer’,’m’,22,’cls3′),(‘zhangsan’,’w’,21,’cls5′),(‘lisi’,’m’,20,’cls4′),(‘wangwu’,’w’,26,’cls6′);

        @ –stop-position=953 pos结束点

      查看数据

       
注:此pos截至点介于“导入实验数据”与立异“name=’李四’”之间,那样可以恢复生机到更改“name=’李四’”从前的“导入测试数据”

      mysql> select * from zyyshop.tt;

        # /usr/local/mysql/bin/mysqlbinlog –stop-position=953
–database=zyyshop /usr/local/mysql/data/mysql-bin.000023 |
/usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop     

      +—-+———-+—–+—–+———+

        在另一极限登录查看结果(成功苏醒了):

      | id | name    | sex | age | classid |

        mysql> select * from zyyshop.tt;

      +—-+———-+—–+—–+———+

        +—-+———-+—–+—–+———+        | id | name    |
sex | age | classid |        +—-+———-+—–+—–+———+   
    |  1 | yiyi    | w  |  20 | cls1    |        |  2 | xiaoer  | m  | 
22 | cls3    |        |  3 | zhangsan | w  |  21 | cls5    |        |  4
| lisi    | m  |  20 | cls4    |        |  5 | wangwu  | w  |  26 |
cls6    |        +—-+———-+—–+—–+———+     
C.钦定pso点区间回复(部分苏醒):

      |  1 | yiyi    | w  |  20 | cls1    |

        更新 name=’李四’ 那条数据,日志区间是Pos[1038] –>
End_log_pos[1164],按工作区间是:Pos[953] –>
End_log_pos[1195];

      |  2 | xiaoer  | m  |  22 | cls3    |

        更新 name=’小二’ 那条数据,日志区间是Pos[1280] –>
End_log_pos[1406],按工作区间是:Pos[1195] –>
End_log_pos[1437];

      |  3 | zhangsan | w  |  21 | cls5    |

        c1.独门恢复生机 name=’李四’ 那步操作,可这么:

      |  4 | lisi    | m  |  20 | cls4    |

          # /usr/local/mysql/bin/mysqlbinlog –start-position=1038
–stop-position=1164 –database=zyyshop 
/usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop          也可以按工作区间单独苏醒,如下:

      |  5 | wangwu  | w  |  26 | cls6    |

          # /usr/local/mysql/bin/mysqlbinlog –start-position=953
–stop-position=1195 –database=zyyshop 
/usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop        c2.独立复苏 name=’小二’
这步操作,可那般:

      +—-+———-+—–+—–+———+

          # /usr/local/mysql/bin/mysqlbinlog –start-position=1280
–stop-position=1406 –database=zyyshop 
/usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop   

      深夜时分又举办了改动数据操作

          也可以按工作区间单独苏醒,如下:

      mysql> update zyyshop.tt set name=’李四’ where id=4;

          # /usr/local/mysql/bin/mysqlbinlog –start-position=1195
–stop-position=1437 –database=zyyshop 
/usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop        c3.将 name=’李四’、name=’小二’
多步操作一起过来,须要按事务区间,可这么:

      mysql> update zyyshop.tt set name=’小二’ where id=2;

          # /usr/local/mysql/bin/mysqlbinlog –start-position=953
–stop-position=1437 –database=zyyshop 
/usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop     
D.在另一终端登录查看如今结果(两名称也过来了):

      修改后的结果:

        mysql> select * from zyyshop.tt;

      mysql> select * from zyyshop.tt;

        +—-+———-+—–+—–+———+        | id | name    |
sex | age | classid |        +—-+———-+—–+—–+———+   
    |  1 | yiyi    | w  |  20 | cls1    |        |  2 | 小二    | m  | 
22 | cls3    |        |  3 | zhangsan | w  |  21 | cls5    |        |  4
| 李四    | m  |  20 | cls4    |        |  5 | wangwu  | w  |  26 |
cls6    |        +—-+———-+—–+—–+———+     
E.也可内定时间距离復苏(部分復苏):除了用pos点的章程开展还原,也足以透过点名时间间隔进行苏醒,按时间回复要求用mysqlbinlog命令读取binlog日志内容,找时间节点。

      +—-+———-+—–+—–+———+

        比如,作者把刚恢复生机的tt表删除掉,再用时间间隔点过来

      | id | name    | sex | age | classid |

        mysql> drop table tt;

      +—-+———-+—–+—–+———+

        @ –start-datetime=”二零一三-11-29 13:18:54″  开头时间点

      |  1 | yiyi    | w  |  20 | cls1    |

        @ –stop-datetime=”2012-11-29 13:21:53″  截止时间点

      |  2 | 小二    | m  |  22 | cls3    |

        # /usr/local/mysql/bin/mysqlbinlog –start-datetime=”二零一二-11-29
13:18:54″ –stop-datetime=”二〇一三-11-29 13:21:53″ –database=zyyshop
/usr/local/mysql/data/mysql-bin.000021 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop     
统计:所谓復苏,就是让mysql将保留在binlog日志中钦点段落区间的sql语句各种重新履行一回而已。

      |  3 | zhangsan | w  |  21 | cls5    |

      |  4 | 李四    | m  |  20 | cls4    |

      |  5 | wangwu  | w  |  26 | cls6    |

      +—-+———-+—–+—–+———+

     
尽管此时是清晨18:00,莫名地推行了一条悲催的SQL语句,整个数据库都没了:

      mysql> drop database zyyshop;

   
3.此刻杯具了,别慌!先仔细查阅最后三个binlog日志,并记下下第①的pos点,到底是哪些pos点的操作导致了数据库的毁损(平日在最终几步);

      备份一下终极贰个binlog日志文件:

      # ll /usr/local/mysql/data | grep mysql-bin

      # cp -v /usr/local/mysql/data/mysql-bin.000023 /root/

     
此时推行一遍刷新日志索引操作,重新开首新的binlog日志记录文件,理论说
mysql-bin.000023
这几个文件不会再有继承写入了(便于我们分析原因及查找pos点),将来全数数据库操作都会写入到下五个日志文件;

      mysql> flush logs;

      mysql> show master status;

    4.读取binlog日志,分析难点

      方式一:使用mysqlbinlog读取binlog日志:

        # /usr/local/mysql/bin/mysqlbinlog 
/usr/local/mysql/data/mysql-bin.000023

      格局二:登录服务器,并查看(推荐):

        mysql> show binlog events in ‘mysql-bin.000023’;

        以下为最后片段:

       
+——————+——+————+———–+————-+————————————————————+

        | Log_name        | Pos  | Event_type | Server_id |
End_log_pos | Info                                                   
  |

       
+——————+——+————+———–+————-+————————————————————+

        | mysql-bin.000023 |  922 | Xid        |        1 |        953 |
COMMIT /* xid=3820 */                                      |

        | mysql-bin.000023 |  953 | Query      |        1 |        1038
| BEGIN                                                      |

        | mysql-bin.000023 | 1038 | Query      |        1 |        1164
| use `zyyshop`; update zyyshop.tt set name=’李四’ where id=4|

        | mysql-bin.000023 | 1164 | Xid        |        1 |        1195
| COMMIT /* xid=3822 */                                      |

        | mysql-bin.000023 | 1195 | Query      |        1 |        1280
| BEGIN                                                      |

        | mysql-bin.000023 | 1280 | Query      |        1 |        1406
| use `zyyshop`; update zyyshop.tt set name=’小二’ where id=2|

        | mysql-bin.000023 | 1406 | Xid        |        1 |        1437
| COMMIT /* xid=3823 */                                      |

        | mysql-bin.000023 | 1437 | Query      |        1 |        1538
| drop database zyyshop                                      |

       
+——————+——+————+———–+————-+————————————————————+

        通过分析,造成数据库破坏的pos点区间是在乎 1437–1538
之间,只要復苏到1437前就可。

    5.现行把凌晨备份的数据苏醒:

      # /usr/local/mysql/bin/mysql -uroot -p123456 -v <
/root/BAK.zyyshop.sql;

      注: 至此甘休当日凌晨(4:00)前的备份数据都復苏了。

          但今日一整天(4:00–18:00)的多寡如何是好呢?就得之前文提到的
mysql-bin.000023 新日志做小说了……

    6.从binlog日志苏醒数据

      复苏语法格式:

      # mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名

        常用选项:

          –start-position=953                  起始pos点

          –stop-position=1437                  结束pos点

          –start-datetime=”二〇一一-11-29 13:18:54″ 起首时间点

          –stop-datetime=”二零一三-11-29 13:21:53″  为止时间点

          –database=zyyshop                   
内定只回复zyyshop数据库(一台主机上屡次有多少个数据库,只限本地log日志)

        不常用选项:   

          -u –user=name              Connect to the remote server as
username.连接到远程主机的用户名

          -p –password[=name]        Password to connect to remote
server.连接到远程主机的密码

          -h –host=name              Get the binlog from
server.从远程主机上赢得binlog日志

          –read-from-remote-server  Read binary logs from a MySQL
server.从某些MySQL服务器上读取binlog日志

     
小结:实际是将读出的binlog日志内容,通过管道符传递给mysql命令。那些命令、文件尽量写成绝对路径;

      A.完全复苏(本例不可靠,因为最后那条 drop database zyyshop
也在日记里,必须想方法把这条破坏语句排除掉,做一些恢复生机)

        # /usr/local/mysql/bin/mysqlbinlog 
/usr/local/mysql/data/mysql-bin.000021 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop

      B.内定pos截至点过来(部分复苏):

        @ –stop-position=953 pos结束点

       
注:此pos截止点介于“导入实验数据”与更新“name=’李四’”之间,那样可以还原到更改“name=’李四’”此前的“导入测试数据”

        # /usr/local/mysql/bin/mysqlbinlog –stop-position=953
–database=zyyshop /usr/local/mysql/data/mysql-bin.000023 |
/usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop

        在另一极限登录查看结果(成功恢复生机了):

        mysql> select * from zyyshop.tt;

        +—-+———-+—–+—–+———+

        | id | name    | sex | age | classid |

        +—-+———-+—–+—–+———+

        |  1 | yiyi    | w  |  20 | cls1    |

        |  2 | xiaoer  | m  |  22 | cls3    |

        |  3 | zhangsan | w  |  21 | cls5    |

        |  4 | lisi    | m  |  20 | cls4    |

        |  5 | wangwu  | w  |  26 | cls6    |

        +—-+———-+—–+—–+———+

      C.指定pso点区间回复(部分復苏):

        更新 name=’李四’ 那条数据,日志区间是Pos[1038] –>
End_log_pos[1164],按工作区间是:Pos[953] –>
End_log_pos[1195];

        更新 name=’小二’ 那条数据,日志区间是Pos[1280] –>
End_log_pos[1406],按工作区间是:Pos[1195] –>
End_log_pos[1437];

        c1.独立恢复生机 name=’李四’ 那步操作,可这么:

          # /usr/local/mysql/bin/mysqlbinlog –start-position=1038
–stop-position=1164 –database=zyyshop 
/usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop

          也得以按工作区间单独复苏,如下:

          # /usr/local/mysql/bin/mysqlbinlog –start-position=953
–stop-position=1195 –database=zyyshop 
/usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop

        c2.独门苏醒 name=’小二’ 那步操作,可那般:

          # /usr/local/mysql/bin/mysqlbinlog –start-position=1280
–stop-position=1406 –database=zyyshop 
/usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop

          也足以按工作区间单独复苏,如下:

          # /usr/local/mysql/bin/mysqlbinlog –start-position=1195
–stop-position=1437 –database=zyyshop 
/usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop

        c3.将 name=’李四’、name=’小二’
多步操作一起过来,须求按事务区间,可那般:

          # /usr/local/mysql/bin/mysqlbinlog –start-position=953
–stop-position=1437 –database=zyyshop 
/usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop

      D.在另一终极登录查看近期结果(两名称也回复了):

        mysql> select * from zyyshop.tt;

        +—-+———-+—–+—–+———+

        | id | name    | sex | age | classid |

        +—-+———-+—–+—–+———+

        |  1 | yiyi    | w  |  20 | cls1    |

        |  2 | 小二    | m  |  22 | cls3    |

        |  3 | zhangsan | w  |  21 | cls5    |

        |  4 | 李四    | m  |  20 | cls4    |

        |  5 | wangwu  | w  |  26 | cls6    |

        +—-+———-+—–+—–+———+

     
E.也可钦定时间间隔復苏(部分復苏):除了用pos点的法门开展回复,也得以由此点名时间距离进行復苏,按时间回复需求用mysqlbinlog命令读取binlog日志内容,找时间节点。

        比如,作者把刚復苏的tt表删除掉,再用时间间隔点过来

        mysql> drop table tt;

        @ –start-datetime=”二零一三-11-29 13:18:54″  开首时间点

        @ –stop-datetime=”2011-11-29 13:21:53″  截止时间点

        # /usr/local/mysql/bin/mysqlbinlog –start-datetime=”2013-11-29
13:18:54″ –stop-datetime=”2013-11-29 13:21:53″ –database=zyyshop
/usr/local/mysql/data/mysql-bin.000021 | /usr/local/mysql/bin/mysql
-uroot -p123456 -v zyyshop

     
总括:所谓復苏,就是让mysql将保存在binlog日志中指定段落区间的sql语句逐个重新履行叁次而已。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*
*
Website