Comments - Mariabackup Overview

I have some vague memory that the Mariabackup was somehow dependent on the binary log but can't find anything in the documentation. Does the Mariabackup tool make use in any way of the binary log, is it safe to disable it?

I am not using replication and the database is relatively busy and the binary-log is filling up free space sometimes too quickly and I would rather disable it.

Mariabackup makes use of the binary log to perform point-in-time recovery. See the --binlog-info option.

I am having a problem when installing maria-backup. Here are command and logs:

sudo apt-get install mariadb-backup sudo: unable to resolve host DEV-MARIADB-015 Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package mariadb-backup

Try to update your repository first sudo apt-get update

Is your server's hostname DEV-MARIADB-015? If this is the case then the problem could basically be lying in your /etc/hostname or /etc/hosts.

Make sure your /etc/hostname file has your actual hostname. Then double check /etc/hosts and make sure an entry similar to this exists:

127.0.0.1 localhost localhost.localdomain DEV-MARIADB-015

I have a problem when I backup as below, I can not backup with mariabackup command:

mariabackup --backup --target-dir=/data/sms_replicate/ --datadir=/var/lib/mysql/ -u root --password=** [00] 2020-05-27 08:53:56 Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: not set [00] 2020-05-27 08:53:56 Using server version 10.3.8-MariaDB-log mariabackup based on MariaDB server 10.3.23-MariaDB Linux (x86_64) [00] 2020-05-27 08:53:56 uses posix_fadvise(). [00] 2020-05-27 08:53:56 cd to /var/lib/mysql/ [00] 2020-05-27 08:53:56 open files limit requested 0, set to 65536 [00] 2020-05-27 08:53:56 mariabackup: using the following InnoDB configuration: [00] 2020-05-27 08:53:56 innodb_data_home_dir = [00] 2020-05-27 08:53:56 innodb_data_file_path = ibdata1:12M:autoextend [00] 2020-05-27 08:53:56 innodb_log_group_home_dir = ./ [00] 2020-05-27 08:53:56 InnoDB: Using Linux native AIO 2020-05-27 8:53:56 0 [Note] InnoDB: Number of pools: 1 [00] 2020-05-27 08:53:56 mariabackup: Generating a list of tablespaces 2020-05-27 8:53:56 0 [Warning] InnoDB: Allocated tablespace ID 343 for portal_hdbank/users, old maximum was 0 [00] 2020-05-27 08:53:57 mariabackup: Incompatible TRUNCATE operation detected. Use --lock-ddl-per-table to lock all tables before backup. [00] 2020-05-27 08:53:57 Error: copying the log failed [00] FATAL ERROR: 2020-05-27 08:53:57 xtrabackup_copy_logfile() failed.

Is there a way to back up the binary log file and position when using the slave-info option?

This should help Setting up a Replication Slave with Mariabackup - right under the "File and Position" section.

Would it be an idea to include information here: https://mariadb.com/kb/en/library/mariabackup-overview/#installing-on-linux

- about the apparent fact that database needs to be restarted in order for it to re-read the information about mariabackup (does it also load libraries/plugins/mudules?) before it will work in any way?

( and maybe upgrade version informations? , there's a 10.2 now )

Why would database need a restart? I can't find a compelling reason. Server is unaware about mariabackup, it can not detect its presence even.

As for upgrade information, mariabackup should match the version of the mysqld, ideally 100% . I hope it is automated by DEB and RPMs.

Well, I've just tried it. Installing mariabackup on a galera cluster to switch from rsync to mariabackup for non-blocking SST. (Ubuntu , MariaDB 10.2.18) node1 running mariadb node2 running mariadb node3 running mariadb Galera working fine.

Then stop node2 and node3

Install mariadb on all 3 nodes, while node1 is running. (Incl changing my.cnf and the required wsrep_sst_method/ ..._auth on all 3 nodes) Try to start node2, and see SST fail miserably. Node1 is unable to read swrep_sst_auth and sst_method is still set to rsync. It doesn't help changing wsrep_sst_method online on node1, SST still fails.

Restart of node1, makes it aware of mariabackup sst settings and SST succeeds.

That's why I claim it requires restart,but I'd love to hear where I might assume wrong or forget an important detail ;) ?

I am wrong. It WILL work also with Galera, aithout restarting any online databases.

My error was that I overlooked the simple task of setting *both* wsrep_auth AND wsrep_method on the DONOR (And on JOINER I guess, in config file(s))

So: DONOR-MYSQL> SET GLOBAL WSREP_AUTH="username:password" DONOR-MYSQL> SET GLOBAL WSREP_METHOD="maribackup"

Start mariadb on the JOINER node that needs SST running non-blocking. It works fine.

My bad!

I'm talking in terms of general backup, you're talking about Galera, nodes, SST , which I do not know at all. Sorry.

Hi,

I created a mariabackup scripts based on xtrabackup since I couldn't find any backup scripts specific to mariadb.

https://github.com/nullart/debian-ubuntu-mariadb-backup

cheers!

MariaDB includes a binary named mbstream which is a copy of Percona XtraBackup xbstream that can be used to extract backup that were created using the --stream=xbstream option.

Most of the time you are going to use it to provision/rebuild new/existing slaves/replicas. The same command you run with Xtrabackup can be utilized with MariaBackup, changing the xbstream part by mbstream - works like a charm and it's part of a daily basis DBOps.