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

innodb_read_only=1 should avoid creating buf_flush_page_cleaner_thread

Details

    • 10.0.34

    Description

      When the server is started in innodb_read_only mode, there cannot be any writes to persistent InnoDB/XtraDB files. Just like the creation of buf_flush_page_cleaner_thread is skipped in this case, also the creation of the XtraDB-specific buf_flush_lru_manager_thread should be skipped.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-13059 XtraDB hangs on Windows due to failing to release block->lock X-latch in innodb_read_only mode

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            laurynas Laurynas Biveinis added a comment -

            I believe we have worked out the correct conditions for starting/not starting page cleaners / LRU managers in the latest XtraDB source. Specifically, LRU manager has to be started on innodb_read_only too - it evicts in addition to flushing, and so without it, a --innodb-empty-free-list-algorithm=backoff would starve InnoDB of free pages.

            laurynas Laurynas Biveinis added a comment - I believe we have worked out the correct conditions for starting/not starting page cleaners / LRU managers in the latest XtraDB source. Specifically, LRU manager has to be started on innodb_read_only too - it evicts in addition to flushing, and so without it, a --innodb-empty-free-list-algorithm=backoff would starve InnoDB of free pages.
            marko Marko Mäkelä added a comment -

            I noticed that I had forgotten to update this ticket when I committed the change to MariaDB 10.0.32, 10.1.25. In MariaDB 10.2 there is no buf_flush_lru_manager_thread.

            laurynas, thank you for the hint. It looks like I should revert this change, or otherwise if innodb_read_only in combination with innodb_empty_free_list_algorithm=backoff may cause the buffer pool to run out. I will construct and run a test case.

            marko Marko Mäkelä added a comment - I noticed that I had forgotten to update this ticket when I committed the change to MariaDB 10.0.32, 10.1.25. In MariaDB 10.2 there is no buf_flush_lru_manager_thread . laurynas , thank you for the hint. It looks like I should revert this change, or otherwise if innodb_read_only in combination with innodb_empty_free_list_algorithm=backoff may cause the buffer pool to run out. I will construct and run a test case.
            marko Marko Mäkelä added a comment -

            I tried and failed to reproduce the buffer pool starvation. It turns out that when the buf_flush_lru_manager_thread is not running, buf_LRU_get_free_block() will choose the legacy algorithm:

            	if (srv_empty_free_list_algorithm == SRV_EMPTY_FREE_LIST_BACKOFF
            		 
            	    && buf_lru_manager_is_active
            		 
            	    && (srv_shutdown_state == SRV_SHUTDOWN_NONE
            		 
            		|| srv_shutdown_state == SRV_SHUTDOWN_CLEANUP)) {

            The condition buf_lru_manager_is_active would not hold, because innobase_start_or_create_for_mysql() will not set the variable unless it is starting the buf_flush_lru_manager_thread.
            For the record, I used the following test case:

            --source include/have_innodb.inc
            		 
            --source include/not_embedded.inc
            		 
             
            		 
            SET GLOBAL innodb_file_per_table=on;
            		 
            create table t(a char(255),b char(255),c char(255), d char(255) not null unique,
            		 
            primary key(a,b,c))engine=innodb;
            		 
             
            		 
            begin;
            		 
            --disable_query_log
            		 
            let $n=30000;
            		 
            while ($n)
            		 
            {
            		 
            eval insert into t values($n,$n,$n,$n);
            		 
            dec $n;
            		 
            }
            		 
            --enable_query_log
            		 
            commit;
            		 
            -- let $restart_parameters=--innodb-read-only --innodb-buffer-pool-size=20m --innodb-buffer-pool-instances=1
            		 
            -- source include/restart_mysqld.inc
            		 
             
            		 
            check table t;

            By default, innodb_buffer_pool_instances would be 0, which would be replaced with 8 if the innodb_buffer_pool_size is large enough.
            It seems that MariaDB has little or no regression test coverage of the innodb_empty_free_list_algorithm=backoff (which is the XtraDB default in 10.0 and 10.1), because the size of a single buffer pool instance would be smaller than 20MiB by default. 1280 pages (20MiB at innodb_page_size=16k) is the limit that is enforced by innodb_empty_free_list_algorithm_allowed().

            marko Marko Mäkelä added a comment - I tried and failed to reproduce the buffer pool starvation. It turns out that when the buf_flush_lru_manager_thread is not running, buf_LRU_get_free_block() will choose the legacy algorithm: if (srv_empty_free_list_algorithm == SRV_EMPTY_FREE_LIST_BACKOFF && buf_lru_manager_is_active && (srv_shutdown_state == SRV_SHUTDOWN_NONE || srv_shutdown_state == SRV_SHUTDOWN_CLEANUP)) { The condition buf_lru_manager_is_active would not hold, because innobase_start_or_create_for_mysql() will not set the variable unless it is starting the buf_flush_lru_manager_thread . For the record, I used the following test case: --source include/have_innodb.inc --source include/not_embedded.inc   SET GLOBAL innodb_file_per_table= on ; create table t(a char (255),b char (255),c char (255), d char (255) not null unique , primary key (a,b,c))engine=innodb;   begin ; --disable_query_log let $n=30000; while ($n) { eval insert into t values ($n,$n,$n,$n); dec $n; } --enable_query_log commit ; -- let $restart_parameters=--innodb-read-only --innodb-buffer-pool-size=20m --innodb-buffer-pool-instances=1 -- source include/restart_mysqld.inc   check table t; By default, innodb_buffer_pool_instances would be 0, which would be replaced with 8 if the innodb_buffer_pool_size is large enough. It seems that MariaDB has little or no regression test coverage of the innodb_empty_free_list_algorithm=backoff (which is the XtraDB default in 10.0 and 10.1), because the size of a single buffer pool instance would be smaller than 20MiB by default. 1280 pages (20MiB at innodb_page_size=16k ) is the limit that is enforced by innodb_empty_free_list_algorithm_allowed() .
            laurynas Laurynas Biveinis added a comment -

            That is correct, I had forgotten about the added && buf_lru_manager_is_active condition.

            laurynas Laurynas Biveinis added a comment - That is correct, I had forgotten about the added && buf_lru_manager_is_active condition.

            People

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