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

BACKUP SERVER to mounted file system

    XMLWordPrintable

Details

    • Q1/2026 Server Development, Q1/2026 Server Maintenance, Q2/2026 Server Maintenance, Q2/2026 Server Development, Q3/2026 Server Maintenance, Q3/2026 Server Development

    Description

      The purpose of this work is to improve current situation around backups by implementing a SQL command that makes a backup of the running server to a mounted directory path or to a tar stream (MDEV-38362):

      BACKUP SERVER TO '/path/to/directory';
      BACKUP SERVER TO '/path/to/directory' 1 CONCURRENT;
      BACKUP SERVER WITH 'command';
      BACKUP SERVER WITH 1 CONCURRENT 'command';
      

      In place of the 1, any positive number of threads may be specified. For the first variant, '/path/to' must exist and '/path/to/directory' must not exist; that is where the backup will be written to.

      For the second variant, 'command' must be the name of a script or command that will be executed in a child process. The standard input of that command will be in a format that is compatible with GNU tar --format=oldgnu (and also BSD `tar` variants that are also part of Microsoft Windows and Apple macOS). The command is expected to optionally compress and encrypt the stream and redirect it to a file on a local or a remote server. The BACKUP SERVER WITH will append an additional argument, a positive base-ten number in ASCII, starting with 1, to identify the current thread. In this way, each concurrent stream can write a separate file.

      This statement will create the requested target directory and fill it with a consistent snapshot of the database. Additionally, the directory will contain a file backup.cnf, which includes some variables that are specific to restoring the backup.

      To prepare a backup (analogous to mariadb-backup --prepare), MDEV-39061 introduces a script that executes roughly the following:

      echo 'SELECT … INTO OUTFILE 'ib_logfile0';shutdown;'|mariadbd \
      --defaults-file=/path/to/directory/backup.cnf \
      --datadir=/path/to/directory --bootstrap
      rm /path/to/directory/ib_*.log
      

      That is, it will apply the backed up log and create an empty ib_logfile0 that corresponds to the final log sequence number (LSN). The is based on this comment of MDEV-27208.

      This step is optional. Alternatively, one could just move the backup to its final storage location and start up MariaDB Server on it, with the correct innodb_log_recovery_start to avoid corruption. By default, InnoDB crash recovery starts from the latest available log checkpoint. However, for restoring a backup, recovery must start from the checkpoint that was the latest when the backup was started. Starting recovery from a possible later checkpoint will result in a corrupted database!

      We may assume that when log_bin is enabled, binlog_storage_engine=innodb (MDEV-34705) will be enabled as well. In this way, there should be no need to include a binlog position or GTID in the backup.cnf.

      Initially only full backup

      For the duration of the backup execution, the server will be configured with innodb_log_archive=ON (MDEV-37949). We will avoid copying any data files created after innodb_lsn_archived, because those files can be reconstructed based on log records.

      Unlike mariadb-backup, the initial implementation of BACKUP SERVER only supports a full backup. Partial backup will be covered in MDEV-40163 and incremental backup in MDEV-39054 (log streaming) and MDEV-39089 (copying changed pages).

      Storage engine interface

      Most of the actual work is done by the storage engines. There are 3 new handlerton function pointers backup_start, backup_step, backup_end as well as new data types: backup_target to identify a backup target directory, backup_sink comprising the storage engine context and the target stream, and backup_phase (BACKUP_PHASE_FINISH, BACKUP_PHASE_ABORT, BACKUP_PHASE_PREPARE_START or one of the phases that are tightly coupled with backup lock modes, between BACKUP_PHASE_START for MDL_BACKUP_START and BACKUP_PHASE_NO_COMMIT for MDL_BACKUP_WAIT_COMMIT.

      For most phases, handlerton::backup_start() and handlerton::backup_end() will be invoked in the thread in which the execution of the BACKUP SERVER statement started. Between these calls, handlerton::backup_step() may be invoked in multiple threads, corresponding to the CONCURRENT clause.

      The currently implemented phases are as follows:

      • BACKUP_PHASE_START:
        • innodb_backup_start(): enables innodb_log_archive=ON for the duration of the backup and initializes a work queue for innodb_backup_step()
        • innodb_backup_step(): copies one InnoDB log or data file at a time
      • BACKUP_PHASE_NO_COMMIT:
        • this is where ENGINE=RocksDB backup (MDEV-39091) would be implemented based on rocksdb_create_checkpoint
        • innodb_backup_start(): determine the end LSN of the backup, and add the remaining log files to the work queue
        • innodb_backup_step(): hard-link, copy or stream the remaining log files
        • innodb_backup_end(): release the InnoDB resources (for example, restore innodb_log_archive=OFF)
        • aria_backup_start(): traverses directories to collect file names
        • aria_backup_end(): copies or streams all files in a loop (yes, in a single thread for now, while the server is maximally blocked!); to be improved in MDEV-39092
      • BACKUP_PHASE_FINISH: executed after releasing locks; another BACKUP SERVER may execute concurrently
        • For ENGINE=RocksDB (MDEV-39091) this is where the entire backup would be streamed
        • no special handling in innodb_backup_start()
        • innodb_backup_step(): copy the remaining log files
        • innodb_backup_end(): if the last log file was hard-linked, duplicate it; write or stream the backup.cnf containing essential information

      The streaming backup (MDEV-38362) does not currently make use of any working directory for the backup. A log-based ENGINE=Aria backup should be possible with the use of some temporary delete-on-close files.

      Attachments

        Issue Links

          Activity

            People

              marko Marko Mäkelä
              wlad Vladislav Vaintroub
              Votes:
              17 Vote for this issue
              Watchers:
              43 Start watching this issue

              Dates

                Created:
                Updated:

                Time Tracking

                  Estimated:
                  Original Estimate - 50d Original Estimate - 50d
                  50d
                  Remaining:
                  Time Spent - 43d 3h 25m Remaining Estimate - 6d 6h 50m
                  6d 6h 50m
                  Logged:
                  Time Spent - 43d 3h 25m Remaining Estimate - 6d 6h 50m
                  43d 3h 25m

                  Git Integration

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