Skip to main content
replaced http://dba.stackexchange.com/ with https://dba.stackexchange.com/
Source Link

When you have binlog_format=MIXED some statements will appear as actual SQL. Other statements may get obfuscated like this:

### INSERT INTO `sanma`.`response`
### SET
###   @1=743096223
###   @2=0
###   @3='IR'
###   @4='UnderProcess'
###   @5=2015-05-29 20:51:34
###   @6=743053329
###   @7=NULL
###   @8=NULL
###   @9='758484829'
###   @10=1432912893
###   @11=758484829
###   @12='UnderProcess'
###   @13=0
###   @14=NULL
###   @15=NULL
###   @16=NULL
###   @17=NULL
# at 20535714
#150529 20:51:33 server id 71  end_log_pos 20535741     Xid = 84151212
COMMIT/*!*/;

That statement was possible to see because the INSERT ... SET syntax was used.

Other statements may get obfuscated beyond recognition. This is the risk of using MIXED or ROW.

I have dealt with this recently

The only thing you can do is

# Look for INSERT, UPDATE, DELETE statements
mysqlbinlog ... > statements.sql
grep -i "^[IUD][NPE][SDL][EA][RT][TE]"     statements.sql  > dml.sql
grep -i "^### [IUD][NPE][SDL][EA][RT][TE]" statements.sql >> dml.sql

There are no guarantees you will catch every change in statement form when mysqld switches to binlog_format ROW intermittently.

When you have binlog_format=MIXED some statements will appear as actual SQL. Other statements may get obfuscated like this:

### INSERT INTO `sanma`.`response`
### SET
###   @1=743096223
###   @2=0
###   @3='IR'
###   @4='UnderProcess'
###   @5=2015-05-29 20:51:34
###   @6=743053329
###   @7=NULL
###   @8=NULL
###   @9='758484829'
###   @10=1432912893
###   @11=758484829
###   @12='UnderProcess'
###   @13=0
###   @14=NULL
###   @15=NULL
###   @16=NULL
###   @17=NULL
# at 20535714
#150529 20:51:33 server id 71  end_log_pos 20535741     Xid = 84151212
COMMIT/*!*/;

That statement was possible to see because the INSERT ... SET syntax was used.

Other statements may get obfuscated beyond recognition. This is the risk of using MIXED or ROW.

I have dealt with this recently

The only thing you can do is

# Look for INSERT, UPDATE, DELETE statements
mysqlbinlog ... > statements.sql
grep -i "^[IUD][NPE][SDL][EA][RT][TE]"     statements.sql  > dml.sql
grep -i "^### [IUD][NPE][SDL][EA][RT][TE]" statements.sql >> dml.sql

There are no guarantees you will catch every change in statement form when mysqld switches to binlog_format ROW intermittently.

When you have binlog_format=MIXED some statements will appear as actual SQL. Other statements may get obfuscated like this:

### INSERT INTO `sanma`.`response`
### SET
###   @1=743096223
###   @2=0
###   @3='IR'
###   @4='UnderProcess'
###   @5=2015-05-29 20:51:34
###   @6=743053329
###   @7=NULL
###   @8=NULL
###   @9='758484829'
###   @10=1432912893
###   @11=758484829
###   @12='UnderProcess'
###   @13=0
###   @14=NULL
###   @15=NULL
###   @16=NULL
###   @17=NULL
# at 20535714
#150529 20:51:33 server id 71  end_log_pos 20535741     Xid = 84151212
COMMIT/*!*/;

That statement was possible to see because the INSERT ... SET syntax was used.

Other statements may get obfuscated beyond recognition. This is the risk of using MIXED or ROW.

I have dealt with this recently

The only thing you can do is

# Look for INSERT, UPDATE, DELETE statements
mysqlbinlog ... > statements.sql
grep -i "^[IUD][NPE][SDL][EA][RT][TE]"     statements.sql  > dml.sql
grep -i "^### [IUD][NPE][SDL][EA][RT][TE]" statements.sql >> dml.sql

There are no guarantees you will catch every change in statement form when mysqld switches to binlog_format ROW intermittently.

Source Link
RolandoMySQLDBA
  • 184.3k
  • 33
  • 323
  • 531

When you have binlog_format=MIXED some statements will appear as actual SQL. Other statements may get obfuscated like this:

### INSERT INTO `sanma`.`response`
### SET
###   @1=743096223
###   @2=0
###   @3='IR'
###   @4='UnderProcess'
###   @5=2015-05-29 20:51:34
###   @6=743053329
###   @7=NULL
###   @8=NULL
###   @9='758484829'
###   @10=1432912893
###   @11=758484829
###   @12='UnderProcess'
###   @13=0
###   @14=NULL
###   @15=NULL
###   @16=NULL
###   @17=NULL
# at 20535714
#150529 20:51:33 server id 71  end_log_pos 20535741     Xid = 84151212
COMMIT/*!*/;

That statement was possible to see because the INSERT ... SET syntax was used.

Other statements may get obfuscated beyond recognition. This is the risk of using MIXED or ROW.

I have dealt with this recently

The only thing you can do is

# Look for INSERT, UPDATE, DELETE statements
mysqlbinlog ... > statements.sql
grep -i "^[IUD][NPE][SDL][EA][RT][TE]"     statements.sql  > dml.sql
grep -i "^### [IUD][NPE][SDL][EA][RT][TE]" statements.sql >> dml.sql

There are no guarantees you will catch every change in statement form when mysqld switches to binlog_format ROW intermittently.