转自：http://blog.csdn.net/thundermeng/article/details/50401150
MySQL复制在业界里有叫：mysql同步，ab复制等。专业名称就是叫：复制
复制是单向的，只能从master复制到slave上，延时基本上是毫秒级别的。
一组复制结构中可以有多个slave，对于master一般场景推荐只有一个。
master用户写入数据，生成event记到binary log中
slave接收master上传来的binlog，然后按顺序应用，重现master上的用户操作。
记录最小的单位是一个event，日志前4个字节是一个magic number,接下来19个字节记录formatt desc event:FDE
MySQL5.6增加了GTID复制
classic主从配置
核心配置
[mysqld] log-bin server-id gtid_mode=off #禁掉gtid
>grant replication slave on *.* to identified by 'repl4slave'; >flush privileges;
| 级别 | 优点 | 缺点 |
| statement | binlog文件较小 日志是包含用户执行的原始SQL,方便统计和审计 出现最早，兼容较好 |
存在安全隐患，可能导致主从不一致 对一些系统函数不能准确复制或是不能复制 |
| row | 相比statement更加安全的复制格式 在某些情况下复制速度更快（SQL复杂，表有主键） 系统的特殊函数也可以复制 更少的锁 更新和删除语句检查是否有主键，如果有则直接执行，如果没有，看是否有二级索引，如再没有，则全表扫描 |
binlog比较大（myql5.6支持binlog_row_image） 单语句更新（删除）表的行数过多，会形成大量binlog 无法从binlog看见用户执行SQL（5.6中增加binlog_row_query_log_events记录用户的query） |
| mixed | 混合使用row和statement格式，对于DDL记录statument,对于table里的行操作记录为row格式。 如果使用innodb表，事务级别使用了READ_COMMITTED or READ_UMCOMMITTED日志级别只能使用row格式。 但是使用ROW格式中DDL语句还是会记录成statement格式。 |
mixed模式中，那么在以下几种情况下自动将binlog模式由SBR模式改成RBR模式。 当DML语句更新一个NDB表 当函数中包含UUID时 2个及以上auto_increment字段的表被更新时 行任何insert delayed语句时 用UDF时 视图中必须要求使用RBR时，例如创建视图使用了UUID()函数 |
添加一个新的从库
获取主库上一个带binlog及pos偏移量的备份
在从库上恢复后
>changemaster to
master_host='192.168.199.117',
master_user='slave',
master_port=7000,
master_password='slavepass',
master_log_file='mysql-bin.000008',
master_log_pos=896;
>startslave;
>showslave status\G;
GTID复制配置
一个事务对应一个唯一ID
一个GTID在一个服务器上只会执行一次
GTID是用来替代以前classic的复制方法
mysql5.62支持，mysql5.6.10后完善
优点：
相对于行复制来讲数据安全性更高
故障切换更简单
GTID
[mysqld]
#GTID:
gtid_mode=on
enforce-gtid-consistency=on
#binlog
log-bin=mysql-bin
log-slave-updates=1
GTID添加从库有两种方法：
1.如果master所有的binlog还在，安装slave后，直接changemaster 到master
原理是直接获取master所有的gtid并执行
优点是简单
缺点是如果binlog太多，数据完全同步需要的时间较长，并且需要master一开始就启用了GTID
总结：适用于master也是新建不久的情况
2.通过master或者其它slave的备份搭建新的slave.
原理：获取master的数据和这些数据对应的GTID范围，然后通过在slave设置@@GLOBAL.GTID_PURGED从而跳过备份包含的GTID
优点是可以避免第一种方法中的不足
缺点操作相对复杂
总结：适用于拥有较大数据集的情况
GTID添加从库：
mysqldump
在备份的时候需要指定--master-data
导出的语句中包括：set @@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';恢复时，需要先在slave上执行一个
reset master;再执行
changemaster to
perconaxtrabackup
xtrabackup_binlog_info包含了GTID在信息
做从库恢复后，需要手工设置：
set@@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';
恢复后，执行change master to
>changemaster to
master_host='192.168.199.117',
master_user='slave',
master_port=7000,
master_password='slavepass',
master_auto_position=1;
错误跳过
stopslave;
setgtid_next='xxxxxxxx:N';
begin;
commit;
setgtid_next='automatic';
startslave;
| rpel | change master | error |
| classic | change master to master_host='192.168.199.117', master_user='slave', master_port=7000, master_password='slavepass', master_log_file='mysql-bin.000008', master_log_pos=896; |
stop slave; set global sql_slave_skip_counter=1; start slave; show slave status\G; |
|
GTID |
change master to master_host='192.168.199.117', master_user='slave', master_port=7000, master_password='slavepass', master_auto_position=1; |
stop slave; set gtid_next='xxxxxxxx:N'; begin; commit; set gtid_next='automatic'; start slave; |
GTID的限制：
不支持非事务引擎（从库报错，stopslave; start slave; 忽略）
不支持create table … select 语句复制（主库直接报错）
不允许在一个SQL同时更新一个事务引擎和非事务引擎的表
在一个复制组中，必须要求统一开启CTID或是关闭GTID
开启DTID需要重启（5.7中可能不需要）
开启DTID后，就不在使用原来的传统的复制方式
对于createtemporary table 和drop temporary table语句不支持
不支持sql_slave_skip_counter
MySQL复制默认是异步复制，Master将事件写入binlog，但并不知道Slave是否或何时已经接收且已处理。在异步复制的机制的情况下，如果Master宕机，事务在Master上已提交，但很可能这些事务没有传到任何的Slave上。假设有Master->Salve故障转移的机制，此时Slave也可能会丢失事务。
官方半同步复制的概念：
1.当Slave主机连接到Master时，能够查看其是否处于半同步复制的机制。
2.当Master上开启半同步复制的功能时，至少应该有一个Slave开启其功能。此时，一个线程在Master上提交事务将受到阻塞，直到得知一个已开启半同步复制功能的Slave已收到此事务的所有事件，或等待超时。
3.当一个事务的事件都已写入其relay-log中且已刷新到磁盘上，Slave才会告知已收到。
4.如果等待超时，也就是Master没被告知已收到，此时Master会自动转换为异步复制的机制。当至少一个半同步的Slave赶上了，Master与其Slave自动转换为半同步复制的机制。
5.半同步复制的功能要在Master，Slave都开启，半同步复制才会起作用；否则，只开启一边，它依然为异步复制。
同步（社区增强半同步），异步，半同步复制的比较：
同步复制：Master提交事务，直到事务在所有的Slave都已提交，此时才会返回客户端，事务执行完毕。缺点：完成一个事务可能会有很大的延迟。
异步复制：当Slave准备好才会向Master请求binlog。缺点：不能保证一些事件都能够被所有的Slave所接收。
半同步复制：半同步复制工作的机制处于同步和异步之间，Master的事务提交阻塞，只要一个Slave已收到该事务的事件且已记录。它不会等待所有的Slave都告知已收到，且它只是接收，并不用等其完全执行且提交。
半同步,开启后严重影响性能
解决主库不关心日志是否被从库读到
半同步配置，在master和slave上都配置
master
[mysqld]
rpl_semi_sync_master_enabled=1
rp;_semi_sync_master_timeout=1000#1s
slave
[mysqld]
rpl_semi_sync_slave_enabled=1
复制参数
| master | slave |
|
log-bin=/data/mysql/mysql3316/logs/mysql-bin |
server-id log_slave_updates #会把复制的binlog也写到binlog中 relay_log_recover=1 #在slave崩溃或正常启动时，未应用完的relay_log会被删掉，重新从master请求binlog再次生成relay_log skip-slave-start slave_transaction_retries #slave复制中，如果因为innodb死锁或者锁超时导致复制线程执行的事务失败重试次数，一般为5 slave_parallel_workers #5.6引入基于库计并发复制的功能，默认是关闭的 read-only #打开只读，但对有super权限的用户无效 slave_net_timeout = 10#默认3600s slave_skip_errors log-slow-slave-statements #默认复制慢语句不会记录到慢日志中，启动此功能，会把复制中超过long_query_time的语句记录到慢日志中 max_relay_log_size 设置relay_log的最大大小，建议不设置 relay-log-info-file #relay_log的索引文件 relay_log_purge 默认开启，在relay_log使用完毕后，尽可能的清理掉 replicate-same-server-id 对于相同的server-id的binlog event默认不执行 slave_load_tmpdir 对于复制load data in file语句，slave指定创建临时文件的目录，默认是tmpdir relay_log_space_limit 限制relay_log战胜磁盘的总大小 =========================== #slave to filter replicate-do-db replicate-ignore-db repicate-rewrite-db 如果master和slave有个库同名了，可使用rewrite规则，将这个库上的复制重写到另一个新的库上 replicate-do-table replicate-ignore-table replicate-wild-do-table replicate-wild-ignore-table |
原文链接：MySQL主从复制原理及操作详解，转载请注明来源！