Yes, please provide the table structure (SHOW CREATE TABLE ...), an example of the UPDATE statement that you are using, SELECT @@binlog_row_image from the same session where UPDATE was executed, and an example of the resulting binlog from the same server.

Just in case – when you are saying that you've had binlog_row_image=MINIMAL for months, I assume you restarted the server after you set it, right?

I updated the original description. And, yes, I did restart the servers since adding `binlog_row_image=MINIMAL` to the config file and they have been running with that setting. I will attach an excerpt of the binlog showing for one of the update statements.

I attached an example binlog entry for one of the updates. It has the row event decoded so I could redact the original blob data. Without it decoding the row data, the same event has a consistently large `BINLOG '...'` block.

After looking at the example UPDATE query I added here outside of the code context I normally see it in, I tried removing the message != 's3' condition from the query and it appears that is doesn't log the old blob data anymore. It looks like since I select the old body so it skips already updated rows, that column is marked as needing to be read when writing the binlog row data. It seems odd, though, that since it has the primary key it still writes the other column's data. Unless I'm thinking about this wrong and the binlog writes the full possibly updated row data for the entire query even if not all of the rows would be updated by the query.

Indeed, it appears to depend on using blob in the WHERE clause, and I agree that it shouldn't. As a workaround, I suppose you can remove the condition, it doesn't do anything useful in your case anyway.

Nor reproducible with MySQL 5.6, 5.7.

MTR-like test-case (only to reproduce, not to be put into the regression suite as is!)

--source include/have_innodb.inc

--source include/have_binlog_format_row.inc

SET binlog_row_image= 'MINIMAL';

CREATE TABLE `contacts_messages` (

    id INT PRIMARY KEY,

    message BLOB

) ENGINE=InnoDB;

CREATE TABLE `contacts_messages_upload_status` (

    id INT PRIMARY KEY

) ENGINE=InnoDB;

INSERT INTO `contacts_messages_upload_status` VALUES (1),(2);

INSERT INTO `contacts_messages` VALUES (1,'foo'),(2,'bar');

UPDATE `contacts_messages` SET `message` = 's3' WHERE message != 's3';

--let $datadir= `SELECT @@datadir`

SHOW BINLOG EVENTS;

FLUSH BINARY LOGS;

--exec $MYSQL_BINLOG --verbose --base64-output=DECODE-ROWS $datadir/master-bin.000001

DROP TABLE `contacts_messages`, `contacts_messages_upload_status`;

Hi,

I have found out that what makes the difference (at least in my case) is having a column defined as:

timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

In particular it must be present 'ON UPDATE CURRENT_TIMESTAMP'

This even with a Primary Key on the table.

I attach a simple test case.
binlog_row_image.txt

Fixed by commit f9ac7032cbc4b7 ) (I checked 2 cases- in the 2 above comments )

commit f9ac7032cbc4b7b9af9c8122e6ebfd91af9fbaf9 (HEAD)

Author: Andrei Elkin <andrei.elkin@mariadb.com>

Date:   Sun Jan 20 19:00:16 2019 +0200

    MDEV-14605 Changes to "ON UPDATE CURRENT_TIMESTAMP" fields are not

               always logged properly with binlog_row_image=MINIMAL