1
0
mirror of https://github.com/MariaDB/server.git synced 2025-05-29 21:42:28 +03:00
mariadb/mysql-test/suite/innodb/t/truncate_purge_debug.test
Marko Mäkelä 3448ceb02a MDEV-13564: Implement innodb_unsafe_truncate=ON for compatibility
While MariaDB Server 10.2 is not really guaranteed to be compatible
with Percona XtraBackup 2.4 (for example, the MySQL 5.7 undo log format
change that could be present in XtraBackup, but was reverted from
MariaDB in MDEV-12289), we do not want to disrupt users who have
deployed xtrabackup and MariaDB Server 10.2 in their environments.

With this change, MariaDB 10.2 will continue to use the backup-unsafe
TRUNCATE TABLE code, so that neither the undo log nor the redo log
formats will change in an incompatible way.

Undo tablespace truncation will keep using the redo log only. Recovery
or backup with old code will fail to shrink the undo tablespace files,
but the contents will be recovered just fine.

In the MariaDB Server 10.2 series only, we introduce the configuration
parameter innodb_unsafe_truncate and make it ON by default. To allow
MariaDB Backup (mariabackup) to work properly with TRUNCATE TABLE
operations, use loose_innodb_unsafe_truncate=OFF.

MariaDB Server 10.3.10 and later releases will always use the
backup-safe TRUNCATE TABLE, and this parameter will not be
added there.

recv_recovery_rollback_active(): Skip row_mysql_drop_garbage_tables()
unless innodb_unsafe_truncate=OFF. It is too unsafe to drop orphan
tables if RENAME operations are not transactional within InnoDB.

LOG_HEADER_FORMAT_10_3: Replaces LOG_HEADER_FORMAT_CURRENT.

log_init(), log_group_file_header_flush(),
srv_prepare_to_delete_redo_log_files(),
innobase_start_or_create_for_mysql(): Choose the redo log format
and subformat based on the value of innodb_unsafe_truncate.
2018-10-11 08:17:04 +03:00

50 lines
1.3 KiB
Plaintext

--source include/have_innodb.inc
--source include/have_debug.inc
--source include/have_debug_sync.inc
--source include/count_sessions.inc
--echo #
--echo # Bug #23070734 CONCURRENT TRUNCATE TABLES CAUSE STALLS
--echo #
create table t1 (f1 int ,f2 int,key(f2)) engine=innodb;
begin;
insert into t1 values (10,45),(20,78),(30,88),(40,23),(50,78),(60,11),(70,56),(80,90);
delete from t1;
connect (con2,localhost,root,,);
# Stop the purge thread
START TRANSACTION WITH CONSISTENT SNAPSHOT;
connection default;
# Ensure that the history list length will actually be decremented by purge.
SET @saved_frequency = @@GLOBAL.innodb_purge_rseg_truncate_frequency;
SET GLOBAL innodb_purge_rseg_truncate_frequency = 1;
commit;
connect (con1,localhost,root,,);
SET DEBUG_SYNC= 'buffer_pool_scan SIGNAL started WAIT_FOR finish_scan';
send truncate table t1;
connection con2;
SET DEBUG_SYNC= 'now WAIT_FOR started';
# Allow purge to proceed, by discarding our read view.
COMMIT;
disconnect con2;
connection default;
--source include/wait_all_purged.inc
SET GLOBAL innodb_purge_rseg_truncate_frequency = @saved_frequency;
SET DEBUG_SYNC = 'now SIGNAL finish_scan';
connection con1;
reap;
disconnect con1;
connection default;
SET DEBUG_SYNC = 'RESET';
drop table t1;
--source include/wait_until_count_sessions.inc