[MDEV-7416] Using named slaves; 'empty' mysql-relay-bin.xxx logs are not removed Created: 2015-01-07  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: Replication
Affects Version/s: 10.0.15
Fix Version/s: 10.4, 10.5

Type: Bug Priority: Minor
Reporter: sjon Assignee: Brandon Nesterenko
Resolution: Unresolved Votes: 0
Labels: logging, multisource, replication

Attachments: HTML File show-global-variables     HTML File show-variables    
Issue Links:
Relates
relates to MDEV-8596 Detect conflicts between file name se... Closed

 Description   

Ever since migrating to mariadb with named masters; besides useful relay logs (named mysql-relay-bin-SERVER which are properly removed) we have a lot of useless, empty relay logs on all our servers. It seems every FLUSH LOGS (which we execute daily) results in an additional file. They are all 297 bytes.

These shouldn't be created since we only have named masters.

 Comments   
Comment by Elena Stepanova [ 2015-01-08 ]

Strangely, I don't get these default relay logs if I only ever configure named slaves.
Could it be that you once ran change master to ..., even though you never actually started this anonymous slave? It would behave exactly as you described.
The easy way to check it is to run SHOW ALL SLAVES STATUS \G command. It will return a row per each configured slave; the first field is 'Connection_name' – if it's empty, it is the anonymous slave.
If it's there and you don't want it, you can run RESET SLAVE '' ALL.

Comment by sjon [ 2015-01-08 ]

I already checked that; and I really only have 2 named masters there. This machine did have an unnamed connection previously; but that is multiple months, reboots and upgrades ago.

Could you try if "flush logs" maybe causes these files to appear? I'm pretty sure it's related to that:

-rw-rw----  1 mysql mysql  13470762 Jan  1 00:20 mysql-bin.000081
 
-rw-rw----  1 mysql mysql  13573801 Jan  2 00:34 mysql-bin.000082
 
-rw-rw----  1 mysql mysql  12280631 Jan  3 00:41 mysql-bin.000083
 
-rw-rw----  1 mysql mysql   7220622 Jan  4 00:41 mysql-bin.000084
 
-rw-rw----  1 mysql mysql   4100754 Jan  5 00:10 mysql-bin.000085
 
-rw-rw----  1 mysql mysql  20281672 Jan  6 00:25 mysql-bin.000086
 
-rw-rw----  1 mysql mysql  19206399 Jan  6 15:12 mysql-bin.000087
 
-rw-rw----  1 mysql mysql    603780 Jan  6 17:35 mysql-bin.000088
 
-rw-rw----  1 mysql mysql       345 Jan  6 17:57 mysql-bin.000089
 
-rw-rw----  1 mysql mysql    183694 Jan  7 00:17 mysql-bin.000090
 
-rw-rw----  1 mysql mysql    414241 Jan  7 09:30 mysql-bin.000091
 
-rw-rw----  1 mysql mysql     70131 Jan  7 09:42 mysql-bin.000092
 
-rw-rw----  1 mysql mysql      5086 Jan  7 09:56 mysql-bin.000093
 
-rw-rw----  1 mysql mysql       345 Jan  7 10:10 mysql-bin.000094
 
-rw-rw----  1 mysql mysql       369 Jan  8 00:20 mysql-bin.000095
 
-rw-rw----  1 mysql mysql      2816 Jan  8 15:40 mysql-bin.000096
 
-rw-rw----  1 mysql mysql       512 Jan  8 00:20 mysql-bin.index
 
...skipped 179 files, removed named relay-logs ...
 
-rw-rw----  1 mysql mysql       297 Jan  1 00:20 mysql-relay-bin.000180
 
-rw-rw----  1 mysql mysql       297 Jan  2 00:34 mysql-relay-bin.000181
 
-rw-rw----  1 mysql mysql       297 Jan  3 00:41 mysql-relay-bin.000182
 
-rw-rw----  1 mysql mysql       297 Jan  4 00:41 mysql-relay-bin.000183
 
-rw-rw----  1 mysql mysql       297 Jan  5 00:10 mysql-relay-bin.000184
 
-rw-rw----  1 mysql mysql       297 Jan  6 00:25 mysql-relay-bin.000185
 
-rw-rw----  1 mysql mysql       267 Jan  6 15:12 mysql-relay-bin.000186
 
-rw-rw----  1 mysql mysql       267 Jan  6 17:35 mysql-relay-bin.000187
 
-rw-rw----  1 mysql mysql       267 Jan  6 17:57 mysql-relay-bin.000188
 
-rw-rw----  1 mysql mysql       297 Jan  7 00:17 mysql-relay-bin.000189
 
-rw-rw----  1 mysql mysql       267 Jan  7 09:30 mysql-relay-bin.000190
 
-rw-rw----  1 mysql mysql       267 Jan  7 09:42 mysql-relay-bin.000191
 
-rw-rw----  1 mysql mysql       267 Jan  7 09:56 mysql-relay-bin.000192
 
-rw-rw----  1 mysql mysql       267 Jan  7 10:10 mysql-relay-bin.000193
 
-rw-rw----  1 mysql mysql       297 Jan  8 00:20 mysql-relay-bin.000194
 
-rw-rw----  1 mysql mysql       248 Jan  8 00:20 mysql-relay-bin.000195
 
-rw-rw----  1 mysql mysql      4875 Jan  8 00:20 mysql-relay-bin.index

Comment by Elena Stepanova [ 2015-01-08 ]

Yes, I did run FLUSH LOGS, the anonymous logs only appear for me when the anonymous slave is configured.
Do you have other files related to the anonymous slave in your datadir? master.info, relay-log.info.
There should also be the file multi-master.info, can you check its contents – does it only have two lines corresponding to your configured slaves, or is there anything else?
Please also attach output of SHOW VARIABLES and SHOW GLOBAL VARIABLES.

Thanks.

Comment by sjon [ 2015-01-08 ]

multi-master contains 2 lines which is correct; interestingly I also have the master.info which seems to be somewhat odd:

33

4

3306
60
1
/etc/mysql/ca-cert.pem

0
1800.000

0

0

using_gtid=0

The relay-log.info is also there:

./mysql-relay-bin.000001
4

0

I'll attach the output of the variables

Comment by Elena Stepanova [ 2015-01-15 ]

Thanks, I could now reproduce the problem.
It starts happening if you at least once attempted to run START SLAVE (without a name), while the anonymous slave is not configured. The attempt fails with the proper error, as expected, and the slave does not appear in SHOW ALL SLAVES STATUS, but all files associated with it (relay logs etc.) get created and from now on start rotating etc.

Test case

 
--source include/master-slave.inc
 
 
 
--connection slave
 
--source include/stop_slave.inc
 
 
 
reset slave all;
 
eval change master 'm1' to master_host='127.0.0.1', master_port=$MASTER_MYPORT, master_user='root';
 
 
 
--let $datadir = `select @@datadir`
 
 
 
start all slaves;
 
set default_master_connection = 'm1';
 
--source include/wait_for_slave_to_start.inc
 
set default_master_connection = '';
 
 
 
--echo #
 
--echo # Relay logs after starting 'm1' slave
 
--list_files $datadir *relay*
 
 
 
--echo #
 
--echo # FLUSH LOGS doesn't do anything bad
 
flush logs;
 
--list_files $datadir *relay*
 
 
 
--echo #
 
--echo # Try to start the anonymous slave although it's not configured
 
--error ER_BAD_SLAVE
 
start slave;
 
 
 
--echo #
 
--echo # Relay logs after a failed attempt to start an unconfigured slave
 
--list_files $datadir *relay*
 
 
 
--echo #
 
--echo # From now on FLUSH LOGS rotate logs for non-existing slave
 
flush logs;
 
--list_files $datadir *relay*

Partial output

 
#
 
# Relay logs after starting 'm1' slave
 
relay-log-m1.info
 
slave-relay-bin-m1.000001
 
slave-relay-bin-m1.000002
 
slave-relay-bin-m1.index
 
#
 
# FLUSH LOGS doesn't do anything bad
 
flush logs;
 
relay-log-m1.info
 
slave-relay-bin-m1.000001
 
slave-relay-bin-m1.000002
 
slave-relay-bin-m1.index
 
#
 
# Try to start the anonymous slave although it's not configured
 
start slave;
 
ERROR HY000: The server is not configured as slave; fix in config file or with CHANGE MASTER TO
 
#
 
# Relay logs after a failed attempt to start an unconfigured slave
 
relay-log-m1.info
 
relay-log.info
 
slave-relay-bin-m1.000001
 
slave-relay-bin-m1.000002
 
slave-relay-bin-m1.index
 
slave-relay-bin.000001
 
slave-relay-bin.index
 
#
 
# From now on FLUSH LOGS rotate logs for non-existing slave
 
flush logs;
 
relay-log-m1.info
 
relay-log.info
 
slave-relay-bin-m1.000001
 
slave-relay-bin-m1.000002
 
slave-relay-bin-m1.index
 
slave-relay-bin.000001
 
slave-relay-bin.000002
 
slave-relay-bin.index

Comment by Damian Maggio [ 2019-10-25 ]

Hi everyone,

We hit this same problem. We have a multi-master replication (all named, no anonymous slaves). The empty relay logs begin to appear when we run START SLAVE without setting a default connection. mysql -e 'START SLAVE', for example.

Running RESET SLAVE in the same situation fixes the problem and deletes all the empty relay logs, the master.info, and mysql-relay-bin.info.

I hope this is useful.

Kind regards,

PD.: version info: mysql Ver 15.1 Distrib 10.1.23-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Generated at Thu Feb 08 07:19:25 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.