[MXS-4254] Replication status is not showing like previous version Created: 2022-08-23  Updated: 2023-10-16  Resolved: 2022-09-16

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

Type: Bug Priority: Major
Reporter: Naresh Chandra Assignee: Duong Thien Ly
Resolution: Fixed Votes: 0
Labels: None

Attachments: PNG File screenshot-1.png     PNG File screenshot-2.png     PNG File screenshot-3.png     PNG File screenshot-4.png    
Issue Links:
Relates
relates to MXS-4812 More than one primary database in a m... Closed

 Description   

We are unable to see the replication status like how we have in the 6.3.1 version like below.

When we hover on the server then its not showing the replication status like 6.3.1 version, seems its not popping up properly?



 Comments   
Comment by Duong Thien Ly [ 2022-08-23 ]

Is the server down? when the server is down, it won't be able to get replication data.

Comment by Naresh Chandra [ 2022-08-23 ]

No Duong, I am testing 22.08.0 version with the same configuration of 6.3.1 version. In 6.3.1 version it showing properly but 22.08.0 its not showing the popup window when we hover on the server.

Comment by Duong Thien Ly [ 2022-08-23 ]


Can you go to the detail page of that server and check if the "MONITOR DIAGNOSTICS" has information in slave_connections?

Comment by Naresh Chandra [ 2022-08-23 ]

Yes, its showing fine on the "MONITOR DIAGNOSTICS" section. Seems in the dash board section popup has some issue?

Comment by Duong Thien Ly [ 2022-08-23 ]

Hmm, that's odd. From the screenshot, it doesn't have the `master_server_name` attribute. The "popup" relies on that value.

Comment by Naresh Chandra [ 2022-08-23 ]

NOTE: In this configuration we have not added any master, we have added all the replicas to schema router, this server main purpose is for only query editor, it means only for the replica servers. But it should show replication status even the configuration doesn't have a master configuration like 6.3.1 version.

Comment by Esa Korhonen [ 2022-08-23 ]

The master server must be visible to the monitor. Not necessarily for the service.

Comment by Naresh Chandra [ 2022-08-23 ]

@Esa Korhonen, I am not sure it was working fine with 6.3.1 That's why I have raised the issue.

Comment by Esa Korhonen [ 2022-08-23 ]

If it was, it was a bug. The monitor cannot labels servers as [Slave] without checking the server they are replicating from (the server could be down, for example). [Master] and [Slave] tag assignment can be customized a bit with the "master_conditions" and "slave_conditions"-settings of MariaDBMonitor.

Comment by Duong Thien Ly [ 2022-09-16 ]

Close it as it's not a bug on the GUI

Comment by Naresh Chandra [ 2022-09-16 ]

Hi Duong,

Is it fixed in the backend?

Comment by Duong Thien Ly [ 2022-09-16 ]

naresh.chandra@copart.com, do you mean the replication is shown even if it doesn't have the master? I suppose it's fixed in 22.08. As a result, you don't see the replication status when it doesn't have the master.
Or do you want to have it fixed in 6.3?

Comment by Naresh Chandra [ 2022-09-16 ]

Duong, If master is not there then its fine in 22.08 version, even slave has master but we are unable to see the replication status whenever we hover mouse on that particular server, you can see the screenshot which i have attached.

Comment by Duong Thien Ly [ 2022-09-16 ]

So you do have a master configuration on 22.08 and it still doesn't show the replication status? Can you share the configuration file?

Comment by Naresh Chandra [ 2022-09-16 ]

I have not mentioned master config, I only configured only slaves in the file.

Comment by Duong Thien Ly [ 2022-09-16 ]

Without master configuration, the monitor won't be able to generate replication status. As Esa mentioned above, if it worked in 6.3, that was a bug. So the MariaDBMonitor needs to know which master server the slaves are replicating from.

Comment by Naresh Chandra [ 2022-09-20 ]

Thanks Duong, for the clarification.

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