Description\n-----------\n\nThe BACKUP STAGE commands are a set of commands to make it possible to make an efficient external backup tool.\n\nSyntax\n\n``sql\nBACKUP STAGE [START | FLUSH | BLOCK_DDL | BLOCK_COMMIT | END ]\n`\n\nIn the following text, a transactional table means InnoDB, or specifically an InnoDB-like engine with redo log that can lock redo purges and can be copied without locks by an outside process.\n\nGoals with BACKUP STAGE Commands\n\n To be able to do a majority of the backup with the minimum possible server locks. Especially for transactional tables (InnoDB, MyRocks etc) there is only need for a very short block of new commits while copying statistics and log tables.\n DDL are only needed to be blocked for a very short duration of the backup while mariadb-backup is copying the tables affected by DDL during the initial part of the backup.\n Most non transactional tables (those that are not in use) will be copied during BACKUP STAGE START. The exceptions are system statistic and log tables that are not blocked during the backup until BLOCK_COMMIT.\n Should work efficiently with backup tools that use disk snapshots.\n Should work as efficiently as possible for all table types that store data on the local disks.\n As little copying as possible under higher level stages/locks. For example, .frm (dictionary) and .trn (trigger) files should be copying while copying the table data.\n\nBACKUP STAGE Commands\n\nBACKUP STAGE START\n\nThe START stage is designed for the following tasks:\n\n Blocks purge of redo files for storage engines that needs this (Aria).\n Start logging of DDL commands into _datadir_/ddl.log. This may take a short time as the command has to wait until there are no active DDL commands.\n\nBACKUP STAGE FLUSH\n\nThe FLUSH stage is designed for the following tasks:\n\n FLUSH all changes for inactive non-transactional tables, except for statistics and log tables.\n Close all tables that are not in use, to ensure they are marked as closed for the backup.\n BLOCK all new write locks for all non transactional tables (except statistics and log tables). The command will not wait for tables that are in use by read-only transactions.\n\nDDLs don't have to be blocked at this stage as they can't cause the table to be in an inconsistent state. This is true also for non-transactional tables.\n\nBACKUP STAGE BLOCK_DDL\n\nThe BLOCK_DDL stage is designed for the following tasks:\n\n Wait for all statements using write locked non-transactional tables to end.\n Blocks CREATE TABLE, DROP TABLE, TRUNCATE TABLE, and RENAME TABLE.\n Blocks also start off a new ALTER TABLE and the final rename phase of ALTER TABLE. Running ALTER TABLES are not blocked.\n\nBACKUP STAGE BLOCK_COMMIT\n\nThe BLOCK_COMMIT stage is designed for the following tasks:\n\n Lock the binary log and commit/rollback to ensure that no changes are committed to any tables. If there are active commits or data to be copied to the binary log this will be allowed to finish. Active transactions will not affect BLOCK_COMMIT.\n This doesn't lock temporary tables that are not used by replication. However these will be blocked when it's time to write to the binary log.\n Lock system log tables and statistics tables, flush them and mark them closed.\n\nWhen the BLOCK_COMMIT's stages return, this is the 'backup time'. Everything committed will be in the backup and everything not committed will roll back.\n\nTransactional engines will continue to do changes to the redo log during the BLOCK COMMIT stage, but this is not important as all of these will roll back later as the changes will not be committed.\n\nBACKUP STAGE END\n\nThe END stage is designed for the following tasks:\n\n End DDL logging\n Free resources\n\nUsing BACKUP STAGE Commands with Backup Tools\n\nUsing BACKUP STAGE Commands with mariadb-backup\n\nThe BACKUP STAGE statements are a set of statements that make it possible to make an efficient external backup tool.\n\nThe BACKUP STAGE statements are a set of statements that make it possible to make an efficient external backup tool. How mariadb-backup uses these statements depends on which version you are using. It depends on whether you are using the version that is bundled with MariaDB Community Server or the version that is bundled with MariaDB Enterprise Server.\n\nThe BACKUP STAGE statements are a set of statements that make it possible to make an efficient external backup tool. How mariadb-backup uses these statements depends on which version you are using. It depends on whether you are using the version that is bundled with MariaDB Community Server or the version that is bundled with MariaDB Enterprise Server.\n\nSee mariadb-backup and BACKUP STAGE Commands for some examples on how mariadb-backup uses these commands.\n\nUsing BACKUP STAGE Commands with Storage Snapshots\n\nThe BACKUP STAGE commands are a set of commands to make it possible to make an efficient external backup tool. These commands could even be used by tools that perform backups by taking a snapshot of a file system, SAN, or some other kind of storage device. See Storage Snapshots and BACKUP STAGE Commands for some examples on how to use each BACKUP STAGE command in an efficient way.\n\nPrivileges\n\nBACKUP STAGE requires the RELOAD privilege.\n\nNotes\n\n Only one connection can run BACKUP STAGE START. If a second connection tries, it will wait until the first one has executed BACKUP STAGE END.\n If the user skips a BACKUP STAGE, then all intermediate backup stages will automatically be run. This will allow us to add new stages within the BACKUP STAGE hierarchy in the future with even more precise locks without causing problems for tools using an earlier version of the BACKUP STAGE implementation.\n One can use the max_statement_time or lock_wait_timeout system variables to ensure that a BACKUP STAGE` command doesn't block the server too long.\n DDL logging is available from MariaDB 10.11.8, MariaDB 11.0.6, MariaDB 11.1.5 and MariaDB 11.2.4, and in MariaDB Enterprise Server.\n A disconnect automatically releases backup stages.\n* There is no easy way to see what the current stage is.\n\nURL: https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/backup-commands/backup-stage