Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Duplicate
-
10.1.18
-
Ubuntu Linux
Description
Seconds_Behind_Master (and possibly other replication-related status variables) are not accessible through INFORMATION_SCHEMA.GLOBAL_STATUS:
MariaDB [information_schema]> SELECT * FROM GLOBAL_STATUS WHERE VARIABLE_NAME LIKE '%seconds%';
|
Empty set (0.00 sec)
|
This seems inconsistent, since other replication-related status variables are accessible:
MariaDB [information_schema]> SELECT * FROM GLOBAL_STATUS WHERE VARIABLE_NAME LIKE 'slave%';
|
+----------------------------+----------------+
|
| VARIABLE_NAME | VARIABLE_VALUE |
|
+----------------------------+----------------+
|
| SLAVE_CONNECTIONS | 15 |
|
| SLAVE_HEARTBEAT_PERIOD | 30.000 |
|
| SLAVE_OPEN_TEMP_TABLES | 0 |
|
| SLAVE_RECEIVED_HEARTBEATS | 505 |
|
| SLAVE_RETRIED_TRANSACTIONS | 0 |
|
| SLAVE_RUNNING | ON |
|
| SLAVE_SKIPPED_ERRORS | 0 |
|
| SLAVES_CONNECTED | 1 |
|
| SLAVES_RUNNING | 1 |
|
+----------------------------+----------------+
|
9 rows in set (0.00 sec)
|
A possible use case could be defining EVENTs to create a self-contained monitoring solution for replication lag in a multi-master environment. Currently, the only way to get Seconds_Behind_Master from SQL is to use a CURSOR to parse the output of SHOW SLAVE STATUS in a procedure...
Attachments
Issue Links
- relates to
-
MDEV-33856 Alternative Replication Lag Representation via Received/Executed Master Binlog Event Timestamps
-
- Closed
-