mysqldump对于导出10G以下的数据库或几个表，还是适用的，而且更快捷。一旦数据量达到100-500G，无论是对原库的压力还是导出的性能，mysqldump就力不从心了。Percona-Xtrabackup备份工具，是实现MySQL在线热备工作的不二选择，可进行全量、增量、单表备份和还原。（但当数据量更大时，可能需要考虑分库分表，或使用 LVM 快照来加快备份速度了）。
2.2版本xtrabackup能对InnoDB和XtraDB存储引擎的数据库非阻塞地备份，innobackupex通过perl封装了一层xtrabackup，对MyISAM的备份通过加表读锁的方式实现。2.3版本xtrabackup命令直接支持MyISAM引擎。
我想这是要在实施以前要想清楚的问题。是为了实现读写分离，减轻主库负载或数据分析？ 为了数据安全，做备份恢复？主从切换做高可用？
大部分场景下，以上三个问号一主一从都能够解决，而且任何生产环境都建议你至少要有一个从库，假如你的读操作压力特别大，甚至要做一主多从，还可以不同的slave扮演不同的角色，例如使用不同的索引，或者不同的存储引擎，或使用一个小内存server做slave只用于备份。（当然slave太多也会对master的负载和网络带宽造成压力，此时可以考虑级联复制，即 A->B->C ）。
还有需要考虑的是，一主一从，一旦做了主从切换，不通过其它HA（High Available，是双机集群系统简称，指高可用性集群，是保证业务连续性的有效解决方案，一般有两个或两个以上的节点，且分为活动节点及备用节点。）手段干预的话，业务访问的还是原IP，而且原主库很容易就作废了。于是“主-主”复制就产生了，凭借各自不同的server-id，可以避免“A的变化同步到B，B应用变化又同步到A”这样循环复制的问题。但建议是，主主复制，其中一个主库强制设置为只读，主从切换后架构依然是可用的。
复制过程是slave主动向master拉取，而不是master去推的，所以理想情况下做搭建主从时不需要master做出任何改变甚至停服，slave失败也不影响主库。
mysql系统库mysql库里面表的日志记录格式需要说明：在通过如INSERT、UPDATE、DELETE、TRUNCATE等方式直接修改数据的语句，使用binlog_format指定的方式记录，但使用GRANT、ALTER、CREATE、RENAME等改动的mysql库里数据的，会强制使用statement-based方式记录binlog。
可以在线修改二进制日志类型，如SET SESSION binlog_format=MIXED;，需要SUPER权限。
复制类型还可以分为：异步复制和半同步复制。
通常没说明指的都是异步，即主库执行完Commit后，在主库写入Binlog日志后即可成功返回客户端，无需等等Binlog日志传送给从库，一旦主库宕机，有可能会丢失日志。而半同步复制，是等待其中一个从库也接收到Binlog事务并成功写入Relay Log之后，才返回Commit操作成功给客户端；如此半同步就保证了事务成功提交后至少有两份日志记录，一份在主库Binlog上，另一份在从库的Relay Log上，从而进一步保证数据完整性；半同步复制很大程度取决于主从网络RTT（往返时延），以插件 semisync_master/semisync_slave 形式存在。
此外，在master中也有一个工作线程：和其它MySQL的连接一样，slave在master中打开一个连接也会使得master开始一个线程。复制过程有一个很重要的限制——复制在slave上是串行化的，也就是说master上的并行更新操作不能在slave上并行操作。
步骤：主从版本一致—>主库授权复制帐号—>确保开启binlog及主从server_id唯一—>xtrabackup恢复到从库—>记录xtrabackup_binlog_info中binlog名称及偏移量—>从库change master to —>slave start—>检查两个yes。
[root@localhost ~]# vim /etc/my.cnf
……
server-id=131
#自定义
log_bin=adailinux1
#指定log前缀
[root@adailinux ~]# /etc/init.d/mysqld restart
Shutting down MySQL...... SUCCESS!
Starting MySQL.................. SUCCESS!
在主库操作：
mysql> GRANT REPLICATION SLAVE ON *.* TO ‘rpl‘@‘192.168.8.%‘ IDENTIFIED BY ‘123456‘;
mysql> FLUSH PRIVILEGES;
分别在主、从服务器安装innobackupex工具：
安装innobackupex工具：
[root@adailinux ~]# rpm -ivh http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm
[root@adailinux ~]# yum install -y percona-xtrabackup
在主服务器操作！
这里假设比较简单的情况：全量备份，全量恢复，不涉及增量。
创建备份用户：
[root@adailinux ~]# mysql -uroot -p‘123456‘
Welcome to the MySQL monitor.
mysql> grant RELOAD, LOCK TABLES, REPLICATION CLIENT on *.* to ‘bakuser‘@‘localhost‘ identified by ‘123456‘;
Query OK, 0 rows affected (0.13 sec)
#该用户只需要有备份权限即可，所以在创建用户时只授予其部分权限
mysql> flush privileges；
Query OK, 0 rows affected (0.05 sec)
#刷新！
mysql> quit
Bye
创建备份文件存放目录：
[root@adailinux ~]# mkdir /data/backup
备份：
[root@adailinux ~]# innobackupex --defaults-file=/etc/my.cnf --user=bakuser --password=‘123456‘ -S /tmp/mysql.sock /data/backup
打包备份文件：
[root@adailinux backup]# cd /data/backup/
[root@adailinux backup]# tar -cvf 2017-09-01_00-41-06.tar 2017-09-01_00-41-06
默认会以当天 日期+时间 戳命名备份目录，如2017-08-31_22-30-51。一般会对它进行tar压缩，由于tar只能单进程，所以往往这个压缩过程会比备份过程耗时2倍还多。拷贝到需要恢复（做从库）的目录。如果手头有一份未压缩的全备数据，要在另一台恢复，其实还不如直接 rsync 过来，将近400G的数据压缩与解压缩过程特别漫长。
在从服务器操作！
关闭MySQL服务：
[root@adailinux ~]# /etc/init.d/mysqld stop
Shutting down MySQL......... SUCCESS!
清空/data/mysql/下文件：
创建备份文件存放目录：
[root@adailinux ~]# mkdir /data/backup
拷贝主库中的备份数据到从服务器：
[root@adailinux ~]# scp 192.168.8.131:/data/backup/2017-09-01_00-41-06.tar /data/backup
root@192.168.8.131‘s password:
2017-09-01_00-41-06.tar 100% 20MB 20.1MB/s 00:01
解包备份文件：
[root@adailinux ~]# cd /data/backup/
[root@adailinux backup]# ls
2017-09-01_00-41-06.tar
[root@adailinux backup]# tar xvf 2017-09-01_00-41-06.tar
开始恢复：
[root@adailinux backup]# innobackupex --apply-log /data/backup/2017-09-01_00-41-06
[root@adailinux backup]# innobackupex --defaults-file=/etc/my.cnf --copy-back /data/backup/2017-09-01_00-41-06
[root@adailinux ~]# chown -R mysql:mysql /data/mysql
至此，主库中的数据备份到了从库中！
[root@adailinux ~]# vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/tmp/mysql.sock
server-id=132
注意：
[root@adailinux ~]# /etc/init.d/mysqld start
Starting MySQL.Logging to ‘/data/mysql/adailinux.err‘.
................ SUCCESS!
如在从数据库复制时的备份，必要时使用reset slave all删除所有read log跟连接信息
[root@adailinux ~]# mysql -uroot
mysql> change master to master_host=‘192.168.8.131‘,master_port=3306,master_user=‘rpl‘,master_password=‘123456‘,master_log_file=‘adailinux1.000001‘,master_log_pos=120;
Query OK, 0 rows affected, 2 warnings (0.04 sec)
上面的master_log_file和master_log_pos即是输出的值，也可以在新的数据目录下xtrabackup_binlog_info找到信息。
开启同步：
mysql> start slave;
Query OK, 0 rows affected (0.38 sec)
mysql> show slave status\G
……
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
……
执行show slave status\G命令，出现“Slave_IO_Running: Yes；Slave_SQL_Running: Yes”信息，说明主从同步配置完成。
mysql> show slave status\G
Slave_IO_State: Waiting for master to send event
Master_Log_File: adailinux1.000001
Read_Master_Log_Pos: 120
Relay_Log_File: adailinux-relay-bin.000002
Relay_Log_Pos: 284
Relay_Master_Log_File: adailinux1.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Exec_Master_Log_Pos: 120
Relay_Log_Space: 461
Seconds_Behind_Master: 0
原文：https://www.cnblogs.com/cheyunhua/p/14664142.html