MDEV-22351: InnoDB may report incorrect binlog position information after RESET MASTER
From MariaDB 10.3.5, the saved binlog position is stored in multiple
entries in each rseg header, and during recovery the most recent of
them is selected as the postion to recover. The comparison between
different entries is by comparing the binlog file name and offset.
This fails if the binlog file name changes to something that compares
smaller, which can happen from RESET MASTER (which goes back to the
suffix .000001) or from renaming the basename of the binlog. As a
result, the wrong position can be recovered after RESET MASTER or
binlog rename.
This commit writes an 8-byte incrementing version number with each
position entry. The version is allocated during
innobase_commit_ordered(), which ensures that a higher version number
will correspond to a more recent commit. The recovered position is
then the entry with the highest version number.
If starting on a database written by earlier server version, the code
falls back to the old methods of comparing position entries.
Signed-off-by: Kristian Nielsen <email address hidden>
Fix mariabackup InnoDB recovered binlog position on server upgrade
Before MariaDB 10.3.5, the binlog position was stored in the TRX_SYS page,
while after it is stored in rollback segments. There is code to read the
legacy position from TRX_SYS to handle upgrades. The problem was if the
legacy position happens to compare larger than the position found in
rollback segments; in this case, the old TRX_SYS position would incorrectly
be preferred over the newer position from rollback segments.
Fixed by always preferring a position from rollback segments over a legacy
position.
Signed-off-by: Kristian Nielsen <email address hidden>
Revert: MDEV-22351 InnoDB may recover wrong information after RESET MASTER
This commit can cause the wrong (old) binlog position to be recovered by
mariabackup --prepare. It implements that the value of the FIL_PAGE_LSN is
compared to determine which binlog position is the last one and should be
recoved. However, it some cases it is seen that the FIL_PAGE_LSN order does
not match the binlog position commit order, as is assumed by the code.
In one example, the recovery first encountered this in trx_rseg_mem_restore():
lsn=27282754 binlog position (./master-bin.000001, 472908)
and then later:
lsn=27282699 binlog position (./master-bin.000001, 477164)
The last one 477164 is the correct position. However, because the LSN
encountered for the first one is higher, that position is recovered instead.
This results in too old binlog position, and a newly provisioned slave will
start replicating too early and get duplicate key error or similar.
Signed-off-by: Kristian Nielsen <email address hidden>
Restore getting InnoDB position from mariabackup --no-lock
Revert the patch for MDEV-18917, which removed this functionality.
This restores that mariabackup --prepare recovers the transactional
binlog position from the redo log, and writes it to the file
xtrabackup_binlog_pos_innodb.
This position is updated only on every InnoDB commit. This means that
if the last event in the binlog at the time of backup is a DDL or
non-transactional update, the recovered position from --no-lock will
be behind the state of the backup.
Signed-off-by: Kristian Nielsen <email address hidden>
MDEV-25886 CHECK TABLE crash with DB_MISSING_HISTORY if innodb_read_only
Occasionally, the test innodb.alter_copy would fail in MariaDB 10.6.1,
reporting DB_MISSING_HISTORY during CHECK TABLE. It started to occur during
the development of MDEV-25180, which introduced purge_sys.stop_SYS().
If we delay purge more during DDL operations, then the test would
almost always fail. The reason is that during startup we will restore
a purge view, and CHECK TABLE would still use REPEATABLE READ
even though innodb_read_only is set and other isolation levels
than READ UNCOMMITTED are not guaranteed to work.
ha_innobase::check(): Use READ UNCOMMITTED isolation level if
innodb_read_only is set or innodb_force_recovery exceeds 3.
dict_set_corrupted(): Do not update the persistent data dictionary
if innodb_force_recovery exceeds 3.
