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

AliSQL: [Feature] Issue#29: ADD INFORMATION_SCHEMA.INNODB_RSEG TABLE TO DISPLAY THE ROLLBACK INFORMATION

Details

    Description

      Description:
      ------------
      This feature introduced one system table "information_schema.innodb_rseg" to
      show the status of each of the rollback segments information.
      

      https://github.com/alibaba/AliSQL/commit/0a4817fffcbfb0b1bad46122380d1cded6dfdce0

      Attachments

        Issue Links

          Activity

            plinux, I would prefer not to add this table, because in a future version of MariaDB, I would like to redesign the InnoDB undo logs. There would no longer be rseg_id, but instead I would try to have an .ibu undo log file for each .ibd file.

            In the patch, the column zip_size should always be reported as 0. If we want this table in MariaDB (expecting the columns to be changed in a later release), I think that this column should be omitted, and the table name should be something else, such as innodb_undo or innodb_transaction_logs.

            marko Marko Mäkelä added a comment - plinux , I would prefer not to add this table, because in a future version of MariaDB, I would like to redesign the InnoDB undo logs. There would no longer be rseg_id, but instead I would try to have an .ibu undo log file for each .ibd file. In the patch, the column zip_size should always be reported as 0. If we want this table in MariaDB (expecting the columns to be changed in a later release), I think that this column should be omitted, and the table name should be something else, such as innodb_undo or innodb_transaction_logs.

            As noted in MDEV-25062, we will have to change the format of undo logs to improve concurrency. My previous idea of having a separate undo log file for each tablespace would likely perform badly when a transaction is modifying multiple tables.

            As part of undo log format changes, we may implement some instrumentation, which would have to reflect the format of our choice.

            marko Marko Mäkelä added a comment - As noted in MDEV-25062 , we will have to change the format of undo logs to improve concurrency. My previous idea of having a separate undo log file for each tablespace would likely perform badly when a transaction is modifying multiple tables. As part of undo log format changes, we may implement some instrumentation, which would have to reflect the format of our choice.

            While we still have not changed the transaction metadata and undo log format beyond how it was changed in MDEV-12288 and MDEV-15132, I think that this view would be of very limited use. The columns are as follows:

            show create table information_schema.innodb_rseg;
            Table	Create Table
            INNODB_RSEG	CREATE TEMPORARY TABLE `INNODB_RSEG` (
              `rseg_id` bigint(21) unsigned NOT NULL DEFAULT '0',
              `space_id` bigint(21) unsigned NOT NULL DEFAULT '0',
              `zip_size` bigint(21) unsigned NOT NULL DEFAULT '0',
              `page_no` bigint(21) unsigned NOT NULL DEFAULT '0',
              `max_size` bigint(21) unsigned NOT NULL DEFAULT '0',
              `curr_size` bigint(21) unsigned NOT NULL DEFAULT '0'
            ) ENGINE=MEMORY DEFAULT CHARSET=utf8
            

            The rollback segment ID is conceptually a primary key. Ever since MDEV-19570 was implemented, there always are 128 rollback segments, limited by the current format of the DB_ROLL_PTR column.

            The space_id identifies the undo tablespace. It and page_no are constant in the TRX_SYS page since the database creation.

            The column zip_size should always be 0, because undo tablespaces can never use any ROW_FORMAT=COMPRESSED storage format.

            Above, the most interesting columns would be curr_size and max_size. Ever since MDEV-22343 removed the dictionary table SYS_TABLESPACES, the size of each tablespace (including undo tablespaces) should be reported by INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES, by the columns FILE_SIZE and ALLOCATED_SIZE. That could be used for monitoring how well innodb_undo_log_truncate=ON is performing.

            marko Marko Mäkelä added a comment - While we still have not changed the transaction metadata and undo log format beyond how it was changed in MDEV-12288 and MDEV-15132 , I think that this view would be of very limited use. The columns are as follows: show create table information_schema.innodb_rseg; Table Create Table INNODB_RSEG CREATE TEMPORARY TABLE `INNODB_RSEG` ( `rseg_id` bigint(21) unsigned NOT NULL DEFAULT '0', `space_id` bigint(21) unsigned NOT NULL DEFAULT '0', `zip_size` bigint(21) unsigned NOT NULL DEFAULT '0', `page_no` bigint(21) unsigned NOT NULL DEFAULT '0', `max_size` bigint(21) unsigned NOT NULL DEFAULT '0', `curr_size` bigint(21) unsigned NOT NULL DEFAULT '0' ) ENGINE=MEMORY DEFAULT CHARSET=utf8 The rollback segment ID is conceptually a primary key. Ever since MDEV-19570 was implemented, there always are 128 rollback segments, limited by the current format of the DB_ROLL_PTR column. The space_id identifies the undo tablespace. It and page_no are constant in the TRX_SYS page since the database creation. The column zip_size should always be 0, because undo tablespaces can never use any ROW_FORMAT=COMPRESSED storage format. Above, the most interesting columns would be curr_size and max_size . Ever since MDEV-22343 removed the dictionary table SYS_TABLESPACES , the size of each tablespace (including undo tablespaces) should be reported by INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES , by the columns FILE_SIZE and ALLOCATED_SIZE . That could be used for monitoring how well innodb_undo_log_truncate=ON is performing.

            People

              marko Marko Mäkelä
              svoj Sergey Vojtovich
              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.