[MXS-958] If slave is not started after CHANGE MASTER, then Master_log_file is lost when maxscale restarts Created: 2016-10-27  Updated: 2016-12-01  Resolved: 2016-11-28

Status: Closed
Project: MariaDB MaxScale
Component/s: binlogrouter
Affects Version/s: 1.4.3
Fix Version/s: 1.4.4, 2.0.2

Type: Bug Priority: Minor
Reporter: Geoff Montee (Inactive) Assignee: Massimiliano Pinto (Inactive)
Resolution: Fixed Votes: 2
Labels: None


 Description   

If the binlog router's slave is not started after executing CHANGE MASTER, then the configured value of Master_log_file is lost if the maxscale service is restarted.

To reproduce, let's say that I have the following MaxScale configuration file:

[maxscale]
 
threads=4
 
log_debug=1
 
log_trace=1
 
 
 
[Replication]
 
type=service
 
router=binlogrouter
 
version_string=10.0.25-log
 
user=repl
 
passwd=password
 
router_options=server_id=2,binlogdir=/var/log/binlogs
 
 
 
[Replication Listener]
 
type=listener
 
service=Replication
 
protocol=MySQLClient
 
port=3306

When I start MaxScale up with this configuration file, I log into the replication listener, and I execute CHANGE MASTER in the following way:

$ mysql -u repl -ppassword -h 127.0.0.1
 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
 
Your MySQL connection id is 1657
 
Server version: 10.0.25-log
 
 
 
Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.
 
 
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
 
 
MySQL [(none)]> CHANGE MASTER TO Master_host='172.31.32.144', Master_log_file='mariadb.000026', Master_user='repl', Master_password='password';
 
Query OK, 0 rows affected (0.00 sec)

Note that I did not execute START SLAVE.

Now let's say that I restart MaxScale without starting the slave first:

service maxscale restart

At this point, Master_log_file will be reset to mariadb.000001 according to the log:

2016-10-27 12:10:41   notice : Validating binlog file 'mariadb.000001' ...
 
2016-10-27 12:10:41   info   : Current binlog file is mariadb.000001, current pos is 4

And if this older binlog file doesn't exist on the master, then MaxScale will fail:

2016-10-27 12:18:30   error  : Error packet in binlog stream.mariadb.000001 @ 4.
 
2016-10-27 12:18:30   error  : Replication: Master connection error 1236 'Could not find first log file name in binary log index file' in state 'Slave stopped', attempting reconnect to master 172.31.32.144:3306
 
2016-10-27 12:18:30   notice : Replication: Master 172.31.32.144 disconnected after 0 seconds. 1 events read.



 Comments   
Comment by Massimiliano Pinto (Inactive) [ 2016-10-28 ]

Some background infos:
1) CHANGE MASTER TO command only creates or updates the 'master.ini' file.
No binlog file is involved at this stage.

2) The START SLAVE command then creates the new binlog file before starting the replication

3) When Binlog Server is not configured, the 'master.ini' file doesn't exist.

4) If Binlog server is already configured, the CHANGE MASTER TO 'new_file' doesn't create a new binlog file

First improvement is to add the binlog file creation at point 3)

New added behaviour for 3) almost ready.

A.1) master.ini doesn't exist and it's created by this SQL statement "change master to ..."
A.2) Binlog file is created with 4 magic bytes
A.3) if START SLAVE is executed replication starts, asking master for events in mysql-bin.000009, as it is current 1.4.3 behaviour, using that binlogfile

B.1) If START SLAVE is not executed the new created binlogfile is still in the $binlogdir.
B.2) If mascale has been stopped the new created binlogfile is still in the $binlogdir.
B.3) when maxscale starts master.ini exists and mysql-bin.000009 exists and the replication starts from that file as current 1.4.3 behaviour

This is the log entry in such scenario:

MySQL [(none)]> change master to master_log_file='mysql-bin.000009', master_host='127.0.0.1', master_port=10116, master_user='massi', master_password='massi';
2016-10-28 16:01:32 [5] info : BinlogServer: 'master.ini' created, binlog file 'mysql-bin.000009' created

The log message clearly says master.ini was created with a new binlog file 'mysql-bin.000009' with size 4

  1. ls -lart
    rw-rr- 1 user1 group1 4 Oct 28 16:16 /binlogs/mysql-bin.000009

At this point replication will start either by issuing START SLAVE or by restarting maxscale.

New possible scenario for binlog file creation are under investigation

Generated at Thu Feb 08 04:03:11 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.