Hi, The INNODB_METRICS are partly duplicating global status variables. I would actually like to remove them eventually; see https://jira.mariadb.org/browse/MDEV-15706. This interface was designed in MySQL before performance_schema was developed. I do not know if the author considered using status variables.
The regressions that you found were not intentional; we should avoid changing interfaces within GA releases such as 10.6. The only intentional change was to remove some "double bookkeeping" and let some INNODB_METRICS counters reflect counters that are already being maintained for other reasons, instead of duplicating them. Some indirection for the counter Innodb_buffer_pool_read_requests was removed in MDEV-26827: the duplicate global variable export_vars.innodb_buffer_pool_read_requests was removed and the status variable should reflect buf_pool.stat.n_page_gets directly. When diagnosing https://jira.mariadb.org/browse/MDEV-29967 I did see that counter being incremented. The statement that I used was: show global status like 'innodb_buffer_pool_read%'; Can you please file a bug with exact steps on how to reproduce this? Marko On Fri, May 12, 2023 at 10:12 AM <mari...@biblestuph.com> wrote: > > Figured out trx_rseg_history_len; it's just disabled by default now. But > still stumped on Innodb_buffer_pool_read_requests. > > On 5/12/2023 2:40 AM, mari...@biblestuph.com wrote: > > I've also noticed that my transaction history length is always zero; > > that's true on all my 10.6.13 instances (not just Bullseye). Is that > > information no longer stored here? > > > > SELECT `count` FROM information_schema.INNODB_METRICS WHERE name = > > 'trx_rseg_history_len'; > > > > On 5/11/2023 11:55 PM, mari...@biblestuph.com wrote: > >> Just upgraded from 10.6.12 to 10.6.13 on a Debian Bullseye system, and > >> seeing this oddity. Innodb_buffer_pool_read_requests is zero, and > >> seems to remain at zero no matter what I do (I even tried selecting > >> all the data from a small table several times in a row with no > >> change). It's been running a couple hours now; I've restarted it a > >> couple times. I have 10.6.13 on a few other platforms as well > >> (including Buster), and I'm not seeing the same issue on them. What > >> would cause this? I have no other Bullseye systems running 10.6.13 > >> yet, and the same system has been running 10.6.12 for over a week now > >> without showing this issue. > >> > >> The system _seems_ to be running fine, it's a replica system that is > >> being fed actively from the master (data comes in to it very regularly). > >> > >> MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_%'; > >> +-----------------------------------------+--------------------------------------------------+ > >> | Variable_name | Value | > >> +-----------------------------------------+--------------------------------------------------+ > >> | Innodb_buffer_pool_dump_status | | > >> | Innodb_buffer_pool_load_status | Buffer pool(s) load > >> completed at 230511 23:21:26 | > >> | Innodb_buffer_pool_resize_status | | > >> | Innodb_buffer_pool_load_incomplete | OFF | > >> | Innodb_buffer_pool_pages_data | 609103 | > >> | Innodb_buffer_pool_bytes_data | 9979543552 > >> | > >> | Innodb_buffer_pool_pages_dirty | 19465 | > >> | Innodb_buffer_pool_bytes_dirty | 318914560 > >> | > >> | Innodb_buffer_pool_pages_flushed | 0 | > >> | Innodb_buffer_pool_pages_free | 299441 | > >> | Innodb_buffer_pool_pages_made_not_young | 0 | > >> | Innodb_buffer_pool_pages_made_young | 107 | > >> | Innodb_buffer_pool_pages_misc | 0 | > >> | Innodb_buffer_pool_pages_old | 224824 | > >> | Innodb_buffer_pool_pages_total | 908544 | > >> | Innodb_buffer_pool_pages_lru_flushed | 0 | > >> | Innodb_buffer_pool_pages_lru_freed | 0 | > >> | Innodb_buffer_pool_pages_split | 726 | > >> | Innodb_buffer_pool_read_ahead_rnd | 0 | > >> | Innodb_buffer_pool_read_ahead | 3 | > >> | Innodb_buffer_pool_read_ahead_evicted | 0 | > >> | Innodb_buffer_pool_read_requests | 0 | > >> | Innodb_buffer_pool_reads | 604346 | > >> | Innodb_buffer_pool_wait_free | 0 | > >> | Innodb_buffer_pool_write_requests | 3639341 | > >> +-----------------------------------------+--------------------------------------------------+ > >> 25 rows in set (0.000 sec) > >> > >> MariaDB [(none)]> SHOW VARIABLES LIKE 'innodb_buffer_pool%'; > >> +-------------------------------------+----------------+ > >> | Variable_name | Value | > >> +-------------------------------------+----------------+ > >> | innodb_buffer_pool_chunk_size | 134217728 | > >> | innodb_buffer_pool_dump_at_shutdown | ON | > >> | innodb_buffer_pool_dump_now | OFF | > >> | innodb_buffer_pool_dump_pct | 80 | > >> | innodb_buffer_pool_filename | ib_buffer_pool | > >> | innodb_buffer_pool_load_abort | OFF | > >> | innodb_buffer_pool_load_at_startup | ON | > >> | innodb_buffer_pool_load_now | OFF | > >> | innodb_buffer_pool_size | 15032385536 | > >> +-------------------------------------+----------------+ > >> 9 rows in set (0.000 sec) > >> > >> _______________________________________________ > >> Mailing list: https://launchpad.net/~maria-discuss > >> Post to : maria-discuss@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~maria-discuss > >> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~maria-discuss > > Post to : maria-discuss@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~maria-discuss > > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~maria-discuss > Post to : maria-discuss@lists.launchpad.net > Unsubscribe : https://launchpad.net/~maria-discuss > More help : https://help.launchpad.net/ListHelp -- Marko Mäkelä, Lead Developer InnoDB MariaDB plc _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
