• --verify-binlog-checksum , -c 

Verify checksums in binary log files. 

• --version , -V 

Display version information and exit. 

The mysqlbinlog  version number shown when using this option is 3.4. 

• --zstd-compression-level= level 

The compression level to use for connections to the server that use the zstd  compression algorithm. The permitted levels are from 1 to 22, with larger values indicating increasing levels of compression. The default zstd  compression level is 3. The compression level setting has no effect on connections that do not use zstd  compression. 

For more information, see Section 4.2.8, “Connection Compression Control” . 

This option was added in MySQL 8.0.18. 

You can pipe the output of mysqlbinlog  into the mysql  client to execute the events contained in the binary log. This technique is used to recover from an unexpected exit when you have an old backup (see Section 7.5, “Point-in-Time (Incremental) Recovery” ). For example: 

mysqlbinlog binlog.000001 | mysql -u root -p 

Or: 

mysqlbinlog binlog.[0-9]* | mysql -u root -p 

If the statements produced by mysqlbinlog  may contain BLOB  values, these may cause problems when mysql  processes them. In this case, invoke mysql  with the --binary-mode  option. 

You can also redirect the output of mysqlbinlog  to a text file instead, if you need to modify the statement log first (for example, to remove statements that you do not want to execute for some reason). After editing the file, execute the statements that it contains by using it as input to the mysql  program: 

mysqlbinlog binlog.000001 > tmpfile ... edit tmpfile  ... mysql -u root -p < tmpfile 

When mysqlbinlog  is invoked with the --start-position  option, it displays only those events with an offset in the binary log greater than or equal to a given position (the given position must match the start of one event). It also has options to stop and start when it sees an event with a given date and time. This enables you to perform point-in-time recovery using the --stop-datetime  option (to be able to say, for example, “roll forward my databases to how they were today at 10:30 a.m.” ). 

Processing multiple files.  If you have more than one binary log to execute on the MySQL server, the safe method is to process them all using a single connection to the server. Here is an example that demonstrates what may be unsafe : 

mysqlbinlog binlog.000001 | mysql -u root -p # DANGER!! mysqlbinlog binlog.000002 | mysql -u root -p # DANGER!! 

Processing binary logs this way using multiple connections to the server causes problems if the first log file contains a CREATE TEMPORARY TABLE  statement and the second log contains a statement that uses the temporary table. When the first mysql  process terminates, the server drops the temporary table. When the second mysql  process attempts to use the table, the server reports “unknown table.” 

