I found a viable but ugly work around.

Will Mayall

what's your workaround?
Why are you using --use-memory , mariabackup --backup does not have a buffer pool. Also xbstream and targetdir do not make sense.

I am running the mariabackup from a Production Server, I don't care if it takes mariabackup more time to complete than cause issue to my server (increased load), therefore I limit the resources mariabackup can use.

I have been working on MySQL for around 20 years, I haven't had an issue using --use-memory with xtrabackup, the error doesn't indicate that --use-memory is the issue.

I have tried many combinations with xbstream and mbstream, same results, I have to uncompress the tables that fail for corruption, then the backup completes.

Again, I have around 100 Servers, each server has 2K databases with the same schemas, the data is different. mariabackup has failed on every server I have tried, but the corruption doesn't happen on every table, maybe 10 to 20 tables, and it is only ONE Table Definition that mariabackup fails on.

CREATE TABLE `attribution` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`device_id` bigint(20) unsigned NOT NULL DEFAULT 0,
`install_id` bigint(20) NOT NULL,
`attribution_prompt` varchar(32) DEFAULT NULL,
`attribution_action` varchar(32) DEFAULT NULL,
`prompt_date` datetime DEFAULT NULL,
`attribution_date` datetime DEFAULT NULL,
`network_id` int(11) DEFAULT NULL,
`campaign_id` bigint(20) DEFAULT NULL,
`site_id` varchar(512) DEFAULT NULL,
`creative_id` varchar(512) DEFAULT NULL,
`identifiers` text DEFAULT NULL,
`ad_information` text DEFAULT NULL,
`device_information` text DEFAULT NULL,
`country_code2` char(2) DEFAULT NULL,
`country_code3` char(3) DEFAULT NULL,
`date_last_updated` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `device_id` (`device_id`),
KEY `network_id` (`network_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED

But each time it fails, I have to uncompress that table and start the backup over.

Looks like page validation (page_is_corrupted) bug, which is either marko or thiru

Adding most probably cause MDEV-18025

Backups are supposed to be taken and prepared (logs applied) by the same major version of backup as the server.

That said, there should not have been any compatibility-breaking changes other than MDEV-12353 (10.5) and MDEV-14425 (10.8). Therefore, this could affect an upgrade to 10.4 as well. An upgrade to 10.5 or later will be refused with a message like the one in MDEV-24412.

Is this reproducible with newer versions of MariaDB?

I no longer work for the company where I experienced the issue.  
Will

Sent from Yahoo Mail for iPhone

On Friday, April 14, 2023, 6:55 AM, Marko Mäkelä (Jira) <jira@mariadb.org> wrote:

    [ https://jira.mariadb.org/browse/MDEV-23464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marko Mäkelä updated MDEV-23464:
--------------------------------
    Status: Needs Feedback  (was: Open)

Is this reproducible with newer versions of MariaDB?

–
This message was sent by Atlassian Jira
(v8.20.16#820016)

Thank you.

In InnoDB itself, the fix of MDEV-18025 only affected the treatment of encrypted page_compressed=1 tables, while this error is about ROW_FORMAT=COMPRESSED tables.

For mariadb-backup, MDEV-18025 changed some things in xb_fil_cur_read(). The intention was to change the treatment of page_compressed=1 tables only. It seems possible that one cursor->page_size should actually have been cursor->zip_size:

+		const ulint* const end = reinterpret_cast<ulint*>(

+			page + cursor->page_size);

Already in MariaDB 10.3.21 the code looks different:

static bool page_is_corrupted(const byte *page, ulint page_no,

                              const xb_fil_cur_t *cursor,

                              const fil_space_t *space)

{

        byte tmp_frame[UNIV_PAGE_SIZE_MAX];

        byte tmp_page[UNIV_PAGE_SIZE_MAX];

        const ulint page_size = cursor->page_size.physical();

        ulint page_type = mach_read_from_2(page + FIL_PAGE_TYPE);

…

                const ulint* const end = reinterpret_cast<const ulint*>(

                        page + page_size);

This looks definitely correct to me. I do not believe that this is a regression due to MDEV-18025.

To analyze the bug, we would have needed a copy of the data file page that was claimed to be corrupted.