When the InnoDB log sequence number exceeds 4,294,967,295, mariabackup --backup would wrongly detect the first page of the InnoDB system tablespace as corrupted.
The first page is never encrypted. In the first page of the system tablespace, the field that was repurposed for the encryption key_version on other pages would contain the 32 most significant bits of the LSN at the latest InnoDB shutdown. If these bits are not 0, mariabackup --backup would fail with the following kind of output:
181229 22:54:31 [01] Copying ibdata1 to /dev/shm/10.1/mysql-test/var/tmp/backup/ibdata1
|
[01] mariabackup: Database page corruption detected at page 0, retrying...
|
[01] mariabackup: Database page corruption detected at page 0, retrying...
|
[01] mariabackup: Database page corruption detected at page 0, retrying...
|
[01] mariabackup: Database page corruption detected at page 0, retrying...
|
[01] mariabackup: Database page corruption detected at page 0, retrying...
|
[01] mariabackup: Database page corruption detected at page 0, retrying...
|
[01] mariabackup: Database page corruption detected at page 0, retrying...
|
[01] mariabackup: Database page corruption detected at page 0, retrying...
|
181229 22:54:32 >> log scanned up to (17596481013967)
|
[01] mariabackup: Database page corruption detected at page 0, retrying...
|
[01] mariabackup: Error: failed to read page after 10 retries. File ibdata1 seems to be corrupted.
|
[01] mariabackup: Error: xtrabackup_copy_datafile() failed.
|
[01] mariabackup: Error: failed to copy datafile.
|
We must skip this test for the very first page of any file.
Bug
Blocker
