mirror of
https://github.com/MariaDB/server.git
synced 2025-01-29 18:20:07 +01:00
987df9b37a
MariaDB 10.2.2 inherited from MySQL 5.7 a perceived optimization of ALTER TABLE, which skips the writing of redo log records. In MDEV-16809 we introduced a parameter that allows the redo log to be written, so that Mariabackup would not be impacted, but we kept the MySQL 5.7 behaviour enabled by default (innodb_log_optimize_ddl=ON). As noted in MDEV-19747 (Deprecate and ignore innodb_log_optimize_ddl, implemented in MariaDB 10.5.1), omitting the redo log writes can actually reduce performance, because we will have to wait for the data pages to be written out. When the redo log file is configured to be large enough, it actually can be much faster to write the redo log and avoid the extra page flushing. When the redo log is omitted (innodb_log_optimize_ddl=ON), also Mariabackup may have to perform a lot of extra work, to re-copy the entire data file if it is possible that any log was omitted during the backup. Starting with MariaDB 10.5.1, the parameter innodb_log_optimize_ddl is deprecated and ignored. We hereby deprecate (but will not ignore) the parameter in earlier versions as well.
28 lines
837 B
Text
28 lines
837 B
Text
--source include/have_debug.inc
|
|
|
|
CREATE TABLE t1(i INT PRIMARY KEY auto_increment, a int) ENGINE INNODB;
|
|
INSERT INTO t1(a) SELECT * from seq_1_to_10000;
|
|
SET GLOBAL innodb_log_optimize_ddl=ON;
|
|
|
|
let $targetdir=$MYSQLTEST_VARDIR/tmp/backup;
|
|
|
|
let after_copy_test_t1=CREATE INDEX a_ind ON test.t1(a) ALGORITHM=INPLACE;
|
|
echo # xtrabackup backup;
|
|
--disable_result_log
|
|
exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --backup --target-dir=$targetdir --dbug=+d,mariabackup_events;
|
|
--enable_result_log
|
|
|
|
--list_files $targetdir/test t1*
|
|
--let before_copy_test_t1=
|
|
|
|
echo # xtrabackup prepare;
|
|
--disable_result_log
|
|
exec $XTRABACKUP --prepare --target-dir=$targetdir;
|
|
-- source include/restart_and_restore.inc
|
|
--enable_result_log
|
|
|
|
# Check that new table is there after restore.
|
|
SELECT COUNT(*) from t1;
|
|
DROP TABLE t1;
|
|
rmdir $targetdir;
|
|
|