Hello @Zody,
Percona Xtrabackup (PXB) is the preferred way to handle backups. You can use PXB on any node in the cluster to perform backups. Ideally you would use PXB on one of the reader nodes, not the current writer node.
But when trying to prepare the backup the following error occurs:
2025-04-01T09:57:04.089902-00:00 0 [ERROR] [MY-012574] [InnoDB] Unable to lock ./#innodb_redo/#ib_redo0 error: 13
2025-04-01T09:57:04.089977-00:00 0 [Note] [MY-012575] [InnoDB] Check that you do not already have another mysqld process using the same InnoDB data or log files.
2025-04-01T09:57:04.090020-00:00 0 [Note] [MY-012894] [InnoDB] Unable to open './#innodb_redo/#ib_redo0' (error: 11).
2025-04-01T09:57:04.090066-00:00 0 [ERROR] [MY-012930] [InnoDB] Plugin initialization aborted with error Cannot open a file.
2025-04-01T09:57:04.168315-00:00 0 [ERROR] [MY-011825] [Xtrabackup] innodb_init(): Error occured
which leads me to this article:
Which leads to:
We will have to investigate if there is anything we can do here, for now, please prepare the backup on your local filesystem
Am I just missing a mount option or is the aforementioned case with the double renaming still the case?
Would love to do the prepare within the SAMBA/CIFS Share, cause otherwise we would need to mount another SSD Volume with a large amount of Space just to have a temp dir to create and prepare the backup, cause the local filesystem is very tiny (for example /var/lib/mysql is also just another SSD volume mounted)
To create and prepare the backup, i’m having a backup script running from a remote server which checks which node he will use (checking that it’s in Synced state). Actually we dont have a read only node, thats why the backup and prepare happens on a read/write node.
The mysql backup_user we use got created as follows:
CREATE USER 'backup_user'@'%' IDENTIFIED BY 'IDONTTELLYOU';
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backup_user'@'%';
GRANT SELECT ON performance_schema.global_status TO 'backup_user'@'%';
GRANT SELECT ON performance_schema.replication_group_members TO 'backup_user'@'%';
GRANT SELECT ON performance_schema.keyring_component_status TO 'backup_user'@'%';
GRANT SELECT ON performance_schema.log_status TO 'backup_user'@'%';
GRANT BACKUP_ADMIN ON *.* TO 'backup_user'@'%';
FLUSH PRIVILEGES;
Okay then i would more likely bring a read only node into the game which handles the backups and that one will have enough local space to handle the backup.
But then i would have 3 read/write and 1 read-only. Does that brings splitbrain issues? I wouldnt use the read-only in our proxysql to get requests loadbalanced.
Why not just add more local space to any of the existing nodes? If you’re going to need more space on a new node, why not just instead add that space to an existing node?
Curious, why do you want to do the prepare at this stage? Typically, you do the prepare as part of the restore process, not the backup process. This would greatly simplify things if you just moved that part of the process to restore action.