Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-11123

`Seconds_Behind_Master` is not accessible through `information_schema`

Details

    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

          New Feature - A new feature of the product, which has yet to be developed. MDEV-33856 Alternative Replication Lag Representation via Received/Executed Master Binlog Event Timestamps

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            crishoj Christian Rishøj created issue -
            crishoj Christian Rishøj made changes -
            Field Original Value New Value
            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...             		{{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...
            crishoj Christian Rishøj made changes -
            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...             		{{Seconds_Behind_Master}} (and possibly other replication-related status variables) are not accessible through {{INFORMATION_SCHEMA.GLOBAL_STATUS}}:

            {code:SQL}
            MariaDB [information_schema]> SELECT * FROM GLOBAL_STATUS WHERE VARIABLE_NAME LIKE '%seconds%';
            Empty set (0.00 sec)
            {code}

            This seems inconsistent, since other replication-related status variables are accessible:

            {code:SQL}
            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)
            {code}

            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...
            elenst Elena Stepanova made changes -
            Fix Version/s 10.2 [ 14601 ]
            Assignee Lixun Peng [ plinux ]
            Elkin Andrei Elkin made changes -
            Assignee Lixun Peng [ plinux ] Andrei Elkin [ elkin ]
            Elkin Andrei Elkin made changes -
            Labels show_slave_status
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 78059 ] MariaDB v4 [ 140120 ]
            bnestere Brandon Nesterenko added a comment -

            Fixed in 11.6 with MDEV-33856

            bnestere Brandon Nesterenko added a comment - Fixed in 11.6 with MDEV-33856
            bnestere Brandon Nesterenko made changes -
            Fix Version/s 11.6.0 [ 29839 ]
            Fix Version/s 10.2 [ 14601 ]
            Resolution Duplicate [ 3 ]
            Status Open [ 1 ] Closed [ 6 ]
            bnestere Brandon Nesterenko made changes -

            People

              Elkin Andrei Elkin
              crishoj Christian Rishøj
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.