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

systemd: EXTEND_TIMEOUT_USEC= to avoid startup and shutdown timeouts

    XMLWordPrintable

Details

    • 10.3.6-1

    Description

      MDEV-9202, MDEV-8509 shows cases where the systemd timeout isn't sufficient to preform initialization/shut-down.

      Since https://github.com/systemd/systemd/commit/a327431bd168b2f327f3cd422379e213c643f2a5 released in system v236 Type=notify service can now advice to the systemd service manager they are still working to avoid the service timing out.

      The use of EXTEND_TIMEOUT_USEC= on older services has no effect and is therefore compatible.

      This needs to be included in (feel free to correct/extend):

      • buffer pool dump - buf_dump (storage/innobase/buf/buf0dump.cc)
      • redo log recovery - log_group_read_log_seg (storage/innobase/log/log0log.cc)
      • undo recovery - recv_recover_page_func (storage/innobase/log/log0recv.cc)
      • change buffer?
      • merge buffer?

      I was planning on making the 15 seconds of recv_sys_t->report() more general with respect to interval, and use a define INNODB_REPORT_INTERVAL (include/univ.i?) as the basis for this form of watchdog. I'd send notify messages of INNODB_REPORT_INTERVAL * 2 as an acceptable margin.

      Anywhere else or other suggestions marko, jplindst?

      • galera SST scripts - donor and recipient

      Any other server/engine slow points to account for?

      Target 10.3 and then look at a backport?

      Attachments

        Issue Links

          Activity

            People

              marko Marko Mäkelä
              danblack Daniel Black
              Votes:
              1 Vote for this issue
              Watchers:
              8 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.