mysqlbinlog — Utility for Processing Binary Log Files • --verify-binlog-checksum ,  -c • --version ,  -V • --zstd-compression-level= level Verify checksums in binary log files. Display version information and exit. The  mysqlbinlog  version number shown when using this option is 3.4. 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: Or: 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: 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 : 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.” mysqlbinlog binlog.000001 | mysql -u root -p mysqlbinlog binlog.[0-9]* | mysql -u root -p mysqlbinlog binlog.000001 > tmpfile ...  edit tmpfile  ... mysql -u root -p < tmpfile mysqlbinlog binlog.000001 | mysql -u root -p # DANGER!! mysqlbinlog binlog.000002 | mysql -u root -p # DANGER!! 616