[MXS-29] bugzillaId-589: detect if MAXSCALE_SCHEMA.HEARTBEAT table is not replicated Created: 2014-01-22  Updated: 2019-12-19  Resolved: 2015-11-03

Status: Closed
Project: MariaDB MaxScale
Component/s: Core, mariadbmon
Affects Version/s: 1.0.1
Fix Version/s: 1.3.0

Type: Bug Priority: Minor
Reporter: Timofey Turenko Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux



 Description   

This item is imported from bugzilla http://bugs.mariadb.com/show_bug.cgi?id=589

Vilho Raatikka 2014-10-22 12:40:44 UTC
If replication lag is also monitored, monitor user must have enough permissions to create schema, insert and read rows from its tables. That's because MaxScale creates MAXSCALE_SCHEMA and HEARTBEAT table in it.

[MySQL Monitor]
type=monitor
module=mysqlmon
servers=server1,server2,server3
user=maxuser
passwd=maxpwd
# 
# options for mysql_monitor only
#
detect_replication_lag=1
 

MySQL replication setup may limit what is replicated. If MAXSCALE_SCHEMA.HEARTBEAT isn't replicated replication lag can't be resolved for any of the slaves. As a consequence, all queries are routed to master.

What is asked is detection of this situation and such a log write to error and trace log that user recognizes the case.



 Comments   
Comment by Dipti Joshi (Inactive) [ 2015-03-09 ]

This is the comment history imported from bugzilla

Comment 1 Mark Riddoch 2014-10-22 16:26:19 UTC
I would suggest this is a usability issue and be considered for the GA release

Comment 2 Massimiliano 2014-10-28 09:42:20 UTC
(In reply to comment #0)

> If replication lag is also monitored, monitor user must have enough
> permissions to create schema, insert and read rows from its tables. That's
> because MaxScale creates MAXSCALE_SCHEMA and HEARTBEAT table in it.
> 
> [MySQL Monitor]
> type=monitor
> module=mysqlmon
> servers=server1,server2,server3
> user=maxuser
> passwd=maxpwd
> # 
> # options for mysql_monitor only
> #
> detect_replication_lag=1
> 
> MySQL replication setup may limit what is replicated. If
> MAXSCALE_SCHEMA.HEARTBEAT isn't replicated replication lag can't be resolved
> for any of the slaves. As a consequence, all queries are routed to master.
> 
> What is asked is detection of this situation and such a log write to error
> and trace log that user recognizes the case.

I started a slave without database 'maxscale_schema' and with this option:

--replicate-wild-ignore-table=maxscale_schema.%

The slave will never receive anything about maxscale_schema.

Replication lag is enabled and as MaxScale starts this the entry in the error log for each monitor run (about the slave):

2014-10-28 05:32:37   [mysql_mon]: error: replication heartbeat: failed selecting from hearthbeat table of 127.0.0.1:3307 : [SELECT master_timestamp FROM maxscale_schema.replication_heartbeat WHERE maxscale_id = 49093882 AND master_server_id = 3], Table 'maxscale_schema.replication_heartbeat' doesn't exist 

Another scenario:
'maxscale_schema' is not accessible by the monitor user due to grant lacks these are the messages:

2014-10-28 04:04:40   [mysql_mon]: Error creating maxscale_schema database in Master server: Access denied for user 'arriva'@'localhost' to database 'maxscale_schema'
2014-10-28 04:04:40   [mysql_mon]: Error creating maxscale_schema.replication_heartbeat table in Master server: CREATE command denied to user 'arriva'@'localhost' for table 'replication_heartbeat'
2014-10-28 04:04:40   [mysql_mon]: Error deleting from maxscale_schema.replication_heartbeat table: [DELETE FROM maxscale_schema.replication_heartbeat WHERE master_timestamp < 1414310680], DELETE command denied to user 'newuser'@'localhost' for table 'replication_heartbeat'
2014-10-28 04:04:40   [mysql_mon]: Error updating maxscale_schema.replication_heartbeat table: [UPDATE maxscale_schema.replication_heartbeat SET master_timestamp = 1414483480 WHERE master_server_id = 3 AND maxscale_id = 51171536], UPDATE command denied to user 'newuser'@'localhost' for table 'replication_heartbeat'
2014-10-28 04:04:40   [mysql_mon]: error: replication heartbeat: failed selecting from hearthbeat table of 127.0.0.1:3307 : [SELECT master_timestamp FROM maxscale_schema.replication_heartbeat WHERE maxscale_id = 51171536 AND master_server_id = 3], SELECT command denied to user 'newuser'@'localhost' for table 'replication_heartbeat' 

Current MaxScale version handles this basic issues.

Shall we need to add other informations or write into another log file?

Comment 3 Mark Riddoch 2014-10-28 09:48:42 UTC
I would suggest we add something to the diagnostics output for the monitor, this way it would show up in the output of a show monitor command from the CLI and debug interfaces.

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