classic主从配置
主/从库核心配置 [mysqld] log-bin server-id #主从库server-id要不一致 gtid_mode=off #禁掉gtid#主库配置 grant replication slave on *.* to 'repl'@'%' identified by 'repl4slave'; flush privileges;
添加从库
#添加一个新的从库，获取主库上一个带binlog及pos偏移量的备份，在从库上恢复后 >change master to master_host='192.168.199.117', master_user='repl', master_port=7000, master_password='repl4slave', master_log_file='mysql-bin.000001', master_log_pos=200; >start slave; >show slave status\G; 错误跳过 stop slave; set global sql_slave_skip_counter=1; start slave; show slave status\G;GTID主从配置
一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次，GTID是用来替代以前classic的复制方法，mysql5.62支持，mysql5.6.10后完善
优点：相对于行复制来讲数据安全性更高，故障切换更简单
主从库核心配置
[mysqld] #GTID: gtid_mode=on enforce-gtid-consistency=on #binlog log-bin=mysql-bin log-slave-updates=1（从库要是想写binlog，打开此参数）
添加从库
GTID添加从库有两种方法： 1.如果master所有的binlog还在，安装slave后，直接change master 到master，原理是直接获取master所有的gtid并执行 优点是简单 缺点是如果binlog太多，数据完全同步需要的时间较长，并且需要master一开始就启用了GTID 总结：适用于master也是新建不久的情况 2.通过master或者其它slave的备份搭建新的slave. 原理：获取master的数据和这些数据对应的GTID范围，然后通过在slave设置@@GLOBAL.GTID_PURGED从而跳过备份包含的GTID 优点是可以避免第一种方法中的不足 缺点操作相对复杂 总结：适用于拥有较大数据集的情况
mysqldump在备份的时候需要指定--master-data=2 导出的语句中包括：set @@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497'; 恢复时，需要先在slave上执行一个reset master;再执行change master to perconaxtrabackup xtrabackup_binlog_info包含了GTID在信息 做从库恢复后，需要手工设置： set@@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497'; 恢复后，执行change master to >change master to master_host='192.168.199.117', master_user='repl', master_port=7000, master_password='repl4pass', master_auto_position=1; 错误跳过 stop slave; set gtid_next='xxxxxxxx:N'; begin; commit; set gtid_next='automatic'; start slave; 对比图
rpel
change master
error
classic
change master to
master_host='192.168.199.117',
master_user='repl',
master_port=7000,
master_password='repl4pass',
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='repl',
master_port=7000,
master_password='replpass',
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也可能会丢失事务。
binlog_format区别
级别
优点
缺点
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()函数
复制参数
master
slave
log-bin=/data/mysql/mysql3316/logs/mysql-bin
server-id=[ip]port
log-bin-index=mysql-bin.index
binlog_format=row
binlog_cache_size=1M
max_binlog_size=1G
sync_binlog=0
expire_logs_days=7
log_bin_trust_function_creators=1 #使用存储过程或函数打开
enforce-gtid-consistency=1
gtid-mode=on
gtid-next
gtid-purged
gtid-execued
执行过的gtid
复制过滤
建议能不用就不用，如果必须用，在从库上操作，不要在主库上设置
====================
binlog-do-db
binlog-ignore-db
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
官方半同步复制的概念： 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
