主从复制配置步骤
1. 主库服务器配置
主服务器MySQ配置参数，参数主要依据《高性能MySQL 第三版》；从服务器配置与此稍有不同，主要是增加几个参数，如后节。
#replication
server-id=100
log-bin=mysql-bin
expire_logs_days=30
sync_binlog=1
relay_log=mysql-relay-bin
log_slave_updates=1
#replication safe for innodb engine
innodb_flush_logs_at_commit
innodb_support_xa=1
服务器id号；设置二进制日志文件名（隐含启用）；binlog文件过期天数（最大允许99，设为0则不过期）；每次写入binlog后同步到磁盘。接下几个参数实际是slave上使用的（参看文slave的配置所述），写在这里可以让主从配置参数都一致，方便实际使用时少出错，也方便多级式的复制拓扑。
2. 添加复制用户
只需要赋两个全局的权限: REPLICATION SLAVE, REPLICATION CLIENT
CREATE USER 'repl'@'192.168.10.132' IDENTIFIED BY '***';
GRANT REPLICATION SLAVE , REPLICATION CLIENT ON * . * TO 'repl'@'192.168.10.132' IDENTIFIED BY '***';
3. 备份主库，备份中加入binlog及位置
全面备份主库，备份前需要已经启用二进制日志。
mysqldump -hlocalhost --opt --master-data=1 --all-databases --max_allowed_packet=8M --net_buffer_length=128K -uroot -pyour-password >all.sql
为了获得一致性的备份，考虑加入参数--single-transaction 或 --lock-all-tables，分别针对事务型引擎及非事务型引擎，但它们不能同时使用。
注意其中--master-data=1参数，它将binlog及位置信息生成到备份文件中，大概如下一行
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=8747725;
4.iptables放行备库连入
允许从服务器ip到主服务器3306端口的连接
iptables -I INPUT 7 -s 192.168.10.132/32 -p tcp -m state --state NEW -m tcp --dport 3306 -j ACCEPT
5. 配置从服务器
server-id=201
log-bin=mysql-bin
expire_logs_days=30
sync_binlog=1
relay_log=mysql-relay-bin
log_slave_updates=1 # actually only for B in A->B->C
read_only=1
前四个与主配置一样；中继日志写入binlog （默认是不写的，这实在有点出乎意料）；中继日志文件名；数据只读（root用户不在此限）
6. 还原到从库服务器上
SOURCE /path/to/bakup.sql;
6. 配置从库，连接到主库
事实上下面的log_file,log_pos可以不用再指定，因为当初的备份里已经有该信息。当然这里再指定一次也没负作用。
change master to master_host='192.168.10.100',
master_user='repl',
master_password='repl-password',
master_log_file='mysql-bin.000004',
master_log_pos=8747725;
7. 启动slave
start slave
顺利的话即完成。
如报 Failed to open the relay log 的错误，先停止slave的mysql服务，删除 /var/lib/mysql/ 下的中继日志相关文件，主要是 *-relay-bin.* 及 relay-log.info，再启动重新start slave
配置中的一些注意事项
- 关于binlog_format 参数。该参数的默认值很可能是STATEMENT。它会造成一些问题，比如 insert into tablename select ... limit n 这样的语句，执行时会报warning错误，原因是limit结果在一致性上是非安全的。所以可以加入 binlog_format=MIXED 或者 binlog_format=ROW 的配置参数 。
- 至少在 Mariadb 5.5 上，RESET SLAVE 似乎并不起效，而要写成RESET SLAVE ALL; 才行。
- 如果是同时是主与从的服务器上，必须加入参数 log_slave_updates ，因为，MySQL默认不把中继日志写入二进制日志里（结果就是下级从库收不到相关binlog）。这实在出乎意料。
日常管理维护相关
查看二进制日志文件
即，查看 data 目录下都有哪些binlog文件，通过 SHOW BINARY LOGS 或 SHOW MASTER LOGS 语句，二者等价。还有中继日志，这个好像没有相关语句，要看只能到磁盘目录里看了。
查看二进制日志内容
可以通过SHOW BINLOG EVENTS语句，或者mysqlbinlog工具进行查看日志内容，即是每条binlog事件干了什么
> SHOW BINLOG EVENTS IN 'mysql-bin.000015' LIMIT 0, 30 # 这是sql语句
$ mysqlbinlog -vv mysql-bin.000016 # 注意，这是个可执行程序，跟 mysqldump 类似安装在bin目录中
刷新二进制日志
（这里flush的翻译为刷新不好，叫滚动日志文件更好。）刷新并终结当前的binlog二进制日志文件的写入，并开启一个新的二进制日志文件 FLUSH BINARY LOGS; 。
如果要刷新中继日志，则 FLUSH RELAY LOGS;（中继日志，一般不需要理它，事实上它主要由 chagne master ... 时会自动重设，一般不要手工指定）
自动定时清理binlog
通过参数 expire_logs_days 指定过期天数，过期自动清理；最大只允许99天，具体天数据按实际情况定（空间与同步延迟等）。该参数还可运行时设定。
手工清理binlog
mysql的root用户登录客户端，执行purge命令。
> PURGE {MASTER | BINARY} LOGS TO 'log_name'
> PURGE {MASTER | BINARY} LOGS BEFORE 'date'
其中 log_name是show master logs; 显示的日志文件名，如 mysql-bin.000001. 应用举例：
> PURGE MASTER LOGS TO 'mysql-bin.000003'; //清除mysql-bin.000003(含)之前的日志
> PURGE MASTER LOGS BEFORE '2016-11-05 10:00:00'; //清除2016-11-05 10:00:00前的日志
> PURGE MASTER LOGS BEFORE DATE_SUB(NOW(),INTERVAL 3 DAY);
//清除3天前日志，使用BEFORE函数计算日期，变量的date自变量还可以为'YYYY-MM-DD hh:mm:ss'格式。详查手册
清理二进制日志的影响。如果当前服务器有一个活跃的从属服务器，该从服务器当前正在读取您正在试图删除的日志之一，则本语句不会起作用，而是会失败，并伴随一个错误。不过，如果从属服务器是休止的，并且您碰巧清理了其想要读取的日志之一，则从属服务器启动后不能复制。当从属服务器正在复制时，本语句可以安全运行。您不需要停止它们。（参考）
正常运行若干时间后的复制失败后的维护
如果正常复制运行一段时间以后，出现了异常（通常时进程异常结束、断电等），复制故障了，这里通过 SHOW SLAVE STATUS 可以看到 slave状态里有报执行错误的语句，可以据些解决。如果不奏效，或许需要重配置slave才可以解决问题，
stop slave;
SOURCE /path/to/bakup.sql;
RESET SLAVE ALL;
change master to ...
show slave status; #检查状态，确认主库及连接账号等
START SLAVE;
如果确认可以无视相关错误而继续往后执行，则这时可以设置变量 SET GLOBAL sql_slave_skip_counter = N 跳N个binlog事件。这里有个小技巧，可以一次性把N设置得大一些，如果后面的事件可以正常执行了，再把这这个变量归0（要先停掉 slave ，再设0，再启动slave）。
深入二进制日志
binlog的传递
假定有三台服务器，设置成级联的主从复制，A->B->C，有一条binlog事件在A生成。通过SHOW BINLOG EVENTS语句查看binlog日志内容时，可以看到其中的一列“Server_id”；亦即配置文件里的server-id。该条事件在经过B传递给C，其中的服务器id是保持不变的；事件信息Info也是不变的，直接传给下级slave。这里并不是说，原事件在B上重放时，再生成一次，然后把新生成的传递下去。也正是因此，才可以把B配置成binlog日志服务器（即把B上的表设置成blackhole引擎，这样B上的表里没有数据，而只有binlog），专用做binlog日志分发。
binlog的内容及存储占用
事实上ROW格式的binlog事件也一样可以认为是相关的sql语句，主要ddl 及 insert, update, delete等，但深入探查一下，会发现 update 的相关的binlog 里，同时包含了更新前后的所有字段的值，也就是整行数据。所以，字段多且长的表，如果频繁update，binlog将占用更多的磁盘空间。类似的，删除行的delete操作，也记录了完整的数据。（参看手册）
这也很出乎意料，可能我们原本会以为，只需要通过主键追踪有更新的字段即可，却并不是。大概，这是为了适应主键不一致或没有主键的情况，主库生成binlog时不要做判断，只管无脑的做记录，当slave重放时由sql线程决定是否用主键。
不同主键情况的影响表现
经实验表明（也就是说，手册中没有找到相关的官方说明），slave的sql进程在重放事件时，对于update与delete两类事件，相当于执行一条update或delete语句，其中where条件包括了所有列，即，所有字段都同时匹配的行。这很自然。但，如果本地表有主键或惟一键，那么只按其做更新，而不管其他列。这也可以理解，毕竟有惟一键就不用全表扫描了。
不过，深入想一下，如果主从库的惟一键并不一致，那么，就会造成一些奇异的表现。有时或许当“特性”而hack利用。
