Replicated REPAIR TABLE writes an error in the log when normal REPAIR does not

--source include/have_partition.inc

--source include/master-slave.inc

create table t (a int, key(a)) partition by range (a) (

  partition p0 values less than (10),

  partition p1 values less than (100)

);

insert into t values (5),(50);

--sync_slave_with_master

flush tables;

--let $datadir= `select @@datadir`

--move_file $datadir/test/t#P#p0.MYD $datadir/test/tmp

--move_file $datadir/test/t#P#p1.MYD $datadir/test/t#P#p0.MYD

--move_file $datadir/test/tmp $datadir/test/t#P#p1.MYD

--connection master

repair table t;

--sync_slave_with_master

--connection master

drop table t;

--source include/rpl_end.inc

The test case above imitates a situation when rows ended up in wrong partitions in the table on the slave. It is something that can happen due to a previous malfunctioning of some kind, or can legally occur in 11.4+ if a table was previously altered with WITHOUT VALIDATION clause.

Such table is easily fixed by REPAIR TABLE. When it is executed directly on the server with the corrupt table, it writes its output in a form of "warnings" (they are not real warnings produced by the SQL statement, but the message type in the result set):

repair table t;

Table	Op	Msg_type	Msg_text

test.t	repair	warning	Moved 1 misplaced rows

test.t	repair	warning	Moved 1 misplaced rows

test.t	repair	status	OK

Nothing shows up in the log.

However, when REPAIR is replicated and executed by the slave thread, as in the test case above, it instead writes ERROR messages in the error log:

2024-01-04 22:32:15 12 [ERROR] Moved 1 misplaced rows

2024-01-04 22:32:15 12 [ERROR] Moved 1 misplaced rows

It can be argued that it does need to write something since there are no interactive messages, but in any case it shouldn't be an error, since a) in the corresponding statement result it's just a warning, and b) REPAIR succeeds and no action is expected from the user.