Ubuntu的mysql下xtrabackup热备案例①

 

mysql通过xtrabackup热备，实现slave主从同步。以及遇到的问题并解决。主节点拿备份

前言：基于业务正常运行情况下，主从slave有延迟，或者slave中断的情况下，在不中断业务的同时对数据库进行热备操作。本此记录写的内容页亦可以为从库1-2进行热备操作。下图为计划图:

 

 

 

操作方式(执行的命令我都标蓝色了)：

 

 

 

在主库1-1上操作，下载xtrabackup的安装包
wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.9/binary/debian/trusty/x86_64/Percona-XtraBackup-2.4.9-ra467167cdd4-trusty-x86_64-bundle.tar
解压

 

 

 

tar -xvf Percona-XtraBackup-2.4.9-ra467167cdd4-trusty-x86_64-bundle.tar

 

 

 

 

 

 

解压完成后执行dpkg -i *.deb的时候报错了 ，此时dpkg缺少依赖包需要修复

 

 

 

 dpkg -i *.deb

 

 

 

 

 

 

apt-get -f install =apt-get install -f 来修复这个问题，这是修复依赖关系（depends）的命令，就是假如你的系统上有某个package不满足依赖条件，这个命令就会自动修复，安装那个package依赖的package。此时执行apt-get install -f 并输入Y

 

 

 

apt-get install -f

 

 

 

修复完成=解压安装完毕，这个时候我们就可以开始执行备份了。

 

 

 

从主库1-1执行备份数据（经过测试基本上不影响业务正常使用，不过如果原本数据库存储量大的话备份下来的库也是非常大的）备份本地（ Error: Unsupported server version: '5.7.17-log' 如果报错即apt-get-f install 重新dpkg 安装）

 

 

 

克隆slave时，常用参数--slave-info和--safe-slave-backup。

 

 

 

--slave-info会将master的binlog文件名和偏移量位置保存到xtrabackup_slave_info文件中 (未用到)
--safe-slave-backup会暂停slave的SQL线程直到没有打开的临时表的时候开始备份。备份结束后SQL线程会自动启动，这样操作的目的主要是确保一致性的复制状态。由于我们从主库拿数据库所以不需要加任何参数（下一篇文章介绍从从库1-2拿数据做热备，虽然都差不多 哈哈）。

 

 

 

 

先在主库mysql上添加新从库的slave权限

更新时间2018年3月20日15:31:49
http://blog.csdn.net/wayne_primes/article/details/79625729

 

grant replication slaveon *.* to 新账号 @'从库1-3的IP' identified by '密码';
下面这个命令使用于执行备份主库mysql的所有数据
innobackupex --defaults-file=/etc/mysql/my.cnf --user=主库mysql账号 --password=主库mysql密码 --socket=/run/mysqld/mysqld.sock  --no-timestamp /备份的路径

 

 

案例:
innobackupex --defaults-file=/etc/mysql/my.cnf --user=root --password=123456 --socket=/run/mysqld/mysqld.sock /app/

 

 

 

继续操作：

 

 

 

备份完成后会有一个类似于下面一条Mysql binlog postion这样的提示，将它复制先放在一个文本中切记，切记，切记。这个是主库的master的节点

 

 

 

MySQL binlog position: filename 'mysqlbin-log.000011', position '475586928'

 

 

 

完成后将备份下来的数据是一个以当前时间命名的文件夹，将它复制到从库1-3上

 

 

 

 scp –r 该文件夹 root@从库1-3的的ip:/var/lib/（在这之前可以先备份从库1-3的/var/lib/mysql或者是你指定的msql的路径），然后等待传输完成

 

 

 

下一步在从库1-3上执行命令

 

 

 

修改这个备份下下一步在从库1-3上执行命令来的文件 修改文件夹名为mysql

 

 

 

添加mysql用户组和用户的权限ls

 

 

 

chown –R mysql.mysql /var/lib/mysql

 

 

 

执行还原命令（或者是你指定的mysql文件的路径，若无修改就在/var/lib/mysql）

 

 

 

innobackupex --apply-log --redo-only /var/lib/mysql

 

 

 

重启mysql

 

 

 

service mysql restart

 

 

 

重启完成后登陆从库1-3的mysql,开始主从复制（对应节点就是刚刚备份完成后出现的提示MySQL binlog position: filename 'mysqlbin-log.000011', position '475586928'）

 

 

 

change master to master_host='主库1_1的IP',master_user='之前创建的新账号',master_password='主库密码',master_log_file='mysqlbin-log.000075',master_log_pos= 475586928;   

 

 

 

start slave

 

 

 

show slave status\G;

 

 

 

 

这个时候多执行几次show slave status\G;可以看看主从延迟Seconds_Behind_Master会不会持续降低

 

 

 

 

 

 

 

这条命令在从库上执行可以查询出hang住的表，从而查找出具体的原因出于哪张表

 

show open tables where In_use=1; 

下面的参数在从库上修改的话，可以在某种程度上可以提高主从备份的速度，这里就不一一讲解了，这篇文章在工作中磕磕碰碰写的有点久了，下篇再分析这些参数。（PS：如果非常着急提升从库的性能的话，可以复制下面的参数自行google）
旧
slave-parallel-type=DATABASE
slave_parallel_workers=0
master_info_repository=FILE
relay_log_info_repository=FILE
relay_log_recovery=OFF
新
slave-parallel-type=LOGICAL_CLOCK
 slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON


编辑时间2018年1月18日16:35:54