• mysql-主从架构
• mysql-3种推荐主从架构
• mysql-主从复制工作原理
• mysql-主从复制同步方式4种
• mysql-GTID介绍
  • GTID参数
• mysql-主从复制配置参数
  • 1.基本参数
  • 2.binlog二进制日志参数
  • 3.relay_log中继日志参数
  • 4.同步方式参数
  • 5.GTID参数

mysql-主从架构

主从架构：一主两从，主库用于生产，从库用于数据容灾和主库备机
主从复制：
是mysql数据库的一种容灾备份方案，是mysql自带的功能，无需借助第三方工具，mysql的主从复制并不是数据库磁盘上的文件直接拷贝，而是通过逻辑的binlog日志复制到要同步的服务器本地，然后由本地的县城读取日志里面的sql语句重新应用到mysql数据库中。
应用场景：数据备份与容灾，读写分离，业务拆分

mysql-3种推荐主从架构

第一种：一对一。小型
第二种：一对多。中型
第三种：一对一对多。一个主对一个从，一个从对多个从。分担读读压力，相对安全

mysql-主从复制工作原理

复制分为3个步骤：
两个线程：拉日志线程，重做sql事件线程
1.master将改变记录到二进制日志(binary log)中。
2.slave将master的二进制日志拷贝到它的中继日志(relay log)
3.slave重做中继日志的事件，将日志操作还原并生成数据。

mysql-主从复制同步方式4种

mysql有4种同步方式：
1.异步复制
  优点：搭建简单，使用非常广泛，从mysql诞生就有这种架构，性能非常好。
	缺点：数据是异步的，有丢失数据库的风险
2.全同步复制
	优点：保证数据安全
	缺点：损失性能
3.传统半同步复制
	性能、功能都介于一步和全同步中间。从mysql5.5开始诞生。目的是为了折中前两种架构的性能和优缺点
4.无损复制，增强版的半同步复制
数据零丢失，性能好，mysql5.7诞生

mysql-GTID介绍

GTID:对于一个已提交事务的编号，事务的唯一编号，并且是一个全局唯一的编号。GTID和事务会记录到binlog中，用来表示事务。

GTID是用来替代以前传统的复制方法，mysql5.6.2开始支持GTID。

mysql支持GTID后，一个事务在集群中就不再孤单，在每一个节点中，如果存在具有相同标识符的情况，可以避免同一个事务，在同一个节点中出现多次的情况

GTID的出现，最直接的效果就是，每一个事务在集群中具有啦唯一性的意义，相对于行复制来讲数据安全性更高，故障切换更简单。

GTDID组成

GTID是由Server_uuid:Sequence_Number
Server_uuid(服务器uuid)：是一个mysql实例全局性唯一标识，存放在$datadir/auto.cnf

Sequence_Number(序列号):是mysql内部的一个事务编号，一个mysql实例不会重复的序列号，也表示在该实例上已经提交事务的数量，并且随着事务提交而递增。

根据GTID可以知道事务最初是在哪个实例上提交的，方便故障排查和切换

cat /mysql/data/3306/data/auto.cnf
[auto]
server-uuid=1592313eds-77er-98ij-0a90ad123

GTID参数

gtid_mode = on # gtid模式
log_slave_updates = 1
enforce_gtid_connsistenct = 1
# gtid_mode：
	-on:产生GTID,slave只接受带GTID的事务
  -NO_PERMISSIVE:产生GTID,slave接受不带GTID事务也接受带GTID的事务
  -OFF:不产生GTID，slave只接受不带参GTID的事务
  -OFF_PERMISSIVE:不产生GTID，slave接受不带GTID事务也接受带GTID的事务
 
# log_slave_updates：
	当从库log_slave_updates参数没有开启时，从库的binlog不会记录来源于主库的操作记录。
  只有开启log_slave_updates，从库binlog才会记录主库同步的操作日志。

# enforce_gtid_connsistenct：
 -on:当发现语句/事务不支持GTID时，返回错误信息
 -WARN:当发现不支持语句/事务，返回警告，并且日志中记录
 -OFF:不检查是否有GTID不支持的语句/事务
  

mysql-主从复制配置参数

1.基本参数

bind-address=192.168.0.214  # 绑定ip
server_id = 143306  # 主从不相同，一般主ip结尾+3306
skip_name_resolve = off # 关闭（跳过主机名/域名解析）
transaction-isolation = read-committed # 事务隔离级别

2.binlog二进制日志参数

log_bin = /mysql/log/3306/binlog/itpuxdb-binlog # binlog二进制日志路径
log_bin_index = /mysql/log/3306/binlog/itpuxdb-binlog.index # 二进制文件索引路径
binlog_format = row # 二进制文件格式(必须为行)
binlog_rows_query_log_events = on #（打开） 二进制日志中记录详细的sql操作
sync_binlog = 1 # 默认1，mysql每次提交事务之前会将二进制同步到磁盘上，保证服务器崩溃时不会丢失事件
innodb_flush_log_at_trx_commit = 1 # 默认1，每次事务提交时mysql都会把log buffer的数据写入log file,并且flush（刷到磁盘）中去。
log_bin_trust_function_creators = 1 # 默认为0，同步函数和存储过程
max_binlog_size = 2048M # 默认为1024M
expire_logs_days = 7 # 过期时间天
binlog_cache_size = 1M # 默认32K,binlog缓存大小，设置当心，建议1～4M，根据情况而定
innodb_support_xa = 1 # 默认1，主库上设置，是否支持分布式事务，系统崩溃时启动日志恢复可以按照时间线来恢复数据库

3.relay_log中继日志参数

relay_log = /mysql/log/3306/relaylog/itpuxdb-relay.log # relay_log中继日志路径
relay-log-recover = 1 # 中继日志恢复打开
# 解释：
# 如果relay_log中继日志发生损坏，就自动删除relay_log日志，重新从主节点拉取，完成中继日志的恢复
relay_log_info_repository = table # 默认file,设置table表方式
# 解释：
# 默认时file文件方式，SQL线程数据回放是写数据库操作，relay-info是写文件操作，这两个操作很难保持一致性，设置成table方式，relay-info将写入到mysql.slave_relay_log_info表中

master_info_repository = table # 默认file,设置table表方式
# 解释：
# IO线程也是接收一个个事务，将接收到的事务通过设置参数master_info_repository可以将数据写到什么位置，设置table表方式有很大提高，可靠性也保证。数据写入到mysql.slave_master_info

4.同步方式参数

plugin_dir = /mysql/app/mysql/lib/plugin/
plugin_load = "rpl_semi_sync_master=semisync_master;rpl_semi_sync_slave=semisync_slave.so"
loose_rpl_semi_sync_master_enabled = 1 # mysql5.6开启半同步复制
loose_rpl_semi_sync_slave_enabled = 1  # mysql5.6开启半同步复制
loose_rpl_semi_sync_master_timeout = 5000 # 超时5秒，切回异步
rpl_semi_sync_master_wait_for_slave_count = 1 # 至少收到一个slave发回的ack
rpl_semi_sync_master_wait_point=AFTER_SYNC # mysql5.7的方法，开启无损复制
rpl_semi_sync_master_wait_point=AFTER_COMMIT # mysql5.7的方法，开启半同步复制

5.GTID参数

gtid_mode = on # gtid模式
log_slave_updates = on
enforce_gtid_connsistenct = on
binlog_gtid_simple_recovery = on
# gtid_mode：
	-on:产生GTID,slave只接受带GTID的事务
  -NO_PERMISSIVE:产生GTID,slave接受不带GTID事务也接受带GTID的事务
  -OFF:不产生GTID，slave只接受不带参GTID的事务
  -OFF_PERMISSIVE:不产生GTID，slave接受不带GTID事务也接受带GTID的事务
 
# log_slave_updates：
	当从库log_slave_updates参数没有开启时，从库的binlog不会记录来源于主库的操作记录。
  只有开启log_slave_updates，从库binlog才会记录主库同步的操作日志。

# enforce_gtid_connsistenct：
 -on:当发现语句/事务不支持GTID时，返回错误信息
 -WARN:当发现不支持语句/事务，返回警告，并且日志中记录
 -OFF:不检查是否有GTID不支持的语句/事务