[MXS-1565] Test: Rejoin rejected for old master Created: 2017-12-04  Updated: 2018-01-04  Resolved: 2018-01-04

Status: Closed
Project: MariaDB MaxScale
Component/s: mariadbmon
Affects Version/s: None
Fix Version/s: 2.2.1

Type: Task Priority: Major
Reporter: Johan Wikman Assignee: Esa Korhonen
Resolution: Fixed Votes: 0
Labels: None

Epic Link: Failover/Switchover/Rejoin Testing
Sprint: 2017-48, 2017-49

 Description   
  • Create a master-slave replication setup.
  • Generate some traffic and ensure that all slaves are up to date.
  • Take down all slaves.
  • Generate some traffic on the master.
  • Take down the master.
  • Bring all slaves up.
  • Allow the failover mechanism to do slave promotion.
  • Raise the old master and verify that it is not rejoined.


 Comments   
Comment by Esa Korhonen [ 2017-12-20 ]

The scheme described above wont work with the way mysqlmonitor currently handles downed servers. When a slave goes down, it will lose the [Slave] status. If it comes back online when the master is down, the slave status is not restored, and failover cannot happen without at least one [Slave]. Even if it could, there would be a race, since the servers would not come online at the exact same moment. What may happen is that one slave comes online first, failover is performed on that one with no regards to the others.
Instead, the following steps are taken:

  • 1 master, 3 slaves
  • stop maxscale so it does not autorejoin later on
  • stop & reset slave on servers 3 & 4
  • add data to server 4
  • restart maxscale, check that server 3 is rejoined but not server 4
  • manually set server 1 to replicate from server 4, creating a relay master
  • check that servers 2 & 3 are redirected, making server 1 just a slave
  • switchover master to server 1, check that it's the master
Generated at Thu Feb 08 04:07:43 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.