Scale up as you grow — whether you're running one virtual machine or ten thousand.

From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.

This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
I’m a little confused by this line:
sudo chown -R mysql: /var/lib/mysql
Am I correct in thinking that the colon can be omitted? You only need it if you’re setting the owner group, not the owner user.
Why are we setting the owner user and not the owner group? We’re not going to access the directory as the owner user, but by being a member of the owner group. So shouldn’t it be “:mysql” rather than “mysql:”?
Why not just set both to be sure?
sudo chown -R mysql:mysql /var/lib/mysql
Am I missing something?
Ross
Does the “preparing” operation access the original database, or is it an operation that is performed entirely on the backup tree?
If the latter, then it wouldn’t need to be done until a restore was necessary.
These instructions, specifically the sudo find /var/lib/mysql -type d -exec chmod 770 "{}" \; line would break some LAMP stacks. /var/lib/mysql gets set to 770, and renders the socket (/var/lib/mysql/mysql.sock) unavailable to anybody except root and mysql group. The httpd proccess wouldn’t be able to access the socket after that.
Making the MySQL data dir world-readable is really poor practice - having done so, any remote command execution can read the database off the system. Instead, create a new system user (or modify an existing user) and add it to the mysql group.
Any time advice is provided that suggests you modify the permissions on data you didn’t create, that should raise a flag, and the advice should be closely examined to determine the correct way of handling the task. In general, the only time modifying permissions is the right answer, is when permissions are being restricted, not widened.
I Backed up on Ubuntu and trying to restore on Centos got “innobackupex: completed OK!” then when i try to start mysql service having this issue:
Starting MySQL.The server quit without updating PID file (/[FAILED]mysql/<servername>.pid).
If anyone has issues when they try to run:
innobackupex --user=bkpuser --password=bkppassword /data/backups
To fix both these issues I had to run:
sudo innobackupex --user=bkpuser --password=bkppassword /data/backups --socket /var/lib/mysql/mysql.sock
This comment has been deleted
percona docs list an additional privilege (PROCESS) that is required. I get an error when using the grant above.
https://www.percona.com/doc/percona-xtrabackup/2.4/using_xtrabackup/privileges.html
GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'user'@'localhost';
does the trick