[MXS-119] Monitor Plugin for Tungsten Connector Created: 2015-05-01  Updated: 2016-10-10  Resolved: 2016-10-10

Status: Closed
Project: MariaDB MaxScale
Component/s: N/A
Affects Version/s: None
Fix Version/s: N/A

Type: New Feature Priority: Major
Reporter: Dipti Joshi (Inactive) Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None

Issue Links:
Relates
relates to MXS-135 Testing Table Key Sharding Features Closed
Epic Link: Table Key Sharding Tasks

 Description   

Tungsten Connector is installed on every database node of master - slave cluster. The application going through Tungsten connector should always attempt to go to primary host as master , if primary is not reachable then application should go to the secondary host. If primary host becomes available again, application should fallback to primary host. When MaxScale is connecting to backend database servers through Tungsten connector, Tungsten monitor in MaxScale needs to do the same - i.e. report primary host as master if it a reachable, other wise report secondary host as master.

The configuration needs to be similar to existing monitors:
[Tungsten Connector Monitor]
type=monitor
module=tungstenConMon
servers=primary-server1,secondary-server2,secondary-server3
user=dbmonitoruser
passwd=dbmonitorpwd
monitor_interval=8000
backend_connect_timeout=3

Every monitor interval, the monitor needs to

  • reach to primary server(first one in servers list in monitor configuration), if it is reachable and responds to the query "SHOW STATUS LIKE 'UPTIME'" , then report the the primary node as master to the router
  • Other wise try reaching the next secondary server defined in monitor configuration, do the same query "SHOW STATUS LIKE 'UPTIME'" . If this secondary server responds to the query, then report the the this secondary server node as master to the router, and so on

 Comments   
Comment by Dipti Joshi (Inactive) [ 2015-05-01 ]

Massimiliano Pinto , markus makela please estimate the scope for this.

Comment by Massimiliano Pinto (Inactive) [ 2015-05-04 ]

SHOW STATUS LIKE 'UPTIME' it's similar to SELECT 1: it always gets a successful reply.

Maybe no query is necessary, just checking if the node is running (aka: mysql connection works)

Is the new monitor goal to set Master role to the first available running node?

What about the other nodes? Should they have Slave role or just running ?

Comment by Dipti Joshi (Inactive) [ 2015-05-05 ]

SHOW STATUS LIKE 'UPTIME' it's similar to SELECT 1: it always gets a successful reply.

  • Yes, it will if the node is up and running and the mariadb/mysql server process is running
    Maybe no query is necessary, just checking if the node is running (aka: mysql connection works)
    Is the new monitor goal to set Master role to the first available running node?
  • First primary-server1 should be contacted, if it responds then set it to MASTER. If Primary does not respond then only go to the rest of the nodes, and among these you can select first available running node as MASTER.
    What about the other nodes? Should they have Slave role or just running ?
  • Other nodes just SLAVE. There will not be the traditional SLAVE STATUS or MASTER STATUS at mysql or mariadb level
Generated at Thu Feb 08 03:56:55 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.