Mysql 12 复制1

备份，灾难恢复，大规模，水平扩展，高性能的基础，也是高可用，可扩展，及数据仓库的基础。

简述

开销

Mysql有两种复制方式：基于行的复制和基于语句的复制。
都是通过在主库上记录二进制日志，在备库上重放日志实现的。

主要开销来自于：

• 主库部分启用二进制日志带来的开销。
• 每个备库会增加网络开销

• 主库开多线程给备库同步数据开销会累加

  通常使用读写分离，在备库中读来获得读扩展

解决的问题

• 负载均衡 读写分离，度扩展
• 数据分布 用复制功能来简历多个不同的数据中心
• 备份
• 高可用性 避免单点失败，可以很快的切换到备库，缩短宕机时间
• 升级测试，用高版本作为备库，可以看看能否按照预期执行。

复制如何工作

• 主库事务提交时记录事件到二进制日志中
• 备库启动I/O线程去连接主库，主库启动一个线程来处理连接，然后又事务日志要写的时候，主库写日志给备库，备库处理到自己的中继日志中
• 重放中继日志，回写备库数据

配置复制

拢共分三步

• 在主备都创建复制账号
• 配置主库和备库
• 通知备库连接到主库复制数据

创建账号

注意权限，注意ip限制，因为有权利读取日志，所以还是限制了ip

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl1@'10.28.%.%' IDENTIFIED BY 'p4ssword';

配置主备库

主库打开二进制日志my.cnf加入：
log_bin = mysql-bin
server_id = 10
server_id是自己定的。必须是唯一的。
使用如下的语句检查：

SHOW MASTER STATUS;

备库的配置：

log_bin = mysql-bin
server_id = 2
##中继文件日志
relay_log = /var/lib/mysql/mysql-relay-bin
##允许把重复也记录到备库的binlog
log_slave_updates = 1       
read_only = 1
##放弃了master_port这样的配置方式

启动复制

在备库中执行：

CHANGE MASTER TO MASTER_HOST='主库ip',
-> MASTER_USER='repl', ## 刚才创建的
-> MASTER_PASSWORD='p4ssword',
-> MASTER_LOG_FILE='mysql-bin.000001', ## 主库中执行SHOW MASTER STATUS得到的
-> MASTER_LOG_POS=0; 从头读起

执行完成后使用 SHOW SLAVE STATUS来查看一下发现Slave_IO_Runing为NO
在执行
START SLAVE;来启动

还可以从主库上检查复制线程
SHOW PROCESSLIST

有库不是新库时

把已有库编成另一个的备库，我们需要如下的信息：

• 某一时刻快照
• 主库当前的二进制文件和快照在二进制文件中的坐标
• 从快照时间到现在的二进制日志
  一些克隆备库的方法：
• 冷备 ， 关闭数据库， 把数据复制到备份。 然后配置主备，重启之后会用新的日志文件，在被库中执行CHANGE MASTER TO 命令进行同步
• mysqldump –single-transaction –all-databases –master-data=1 –host=server1 mysql –host=server2
• 使用Percona Xtrabackup工具

推荐的复制配置

sync_binlog=1 开启则每次提交事务都会将二进制日志同步到磁
盘。
log_bin=/ 指明二进制文件名，免得默认的因为系统不同而有问题
relay_log_purge 控制重放完后尽快删除中继日志
read_only=
relay_log=

复制原理

基于语句

简单的记录执行的语句，放到备库去执行
优点：
更容易理解
更灵活及容错，因为都是sql语句的

缺点：
存储过程，触发器不行
一些依赖环境的内置方法也不行
必须顺序执行，会带来更多的锁

基于行

日志记录行的变更。
优点：
可以直接复制变更结果，对于一些耗时sql可以节约性能
不会受到触发器等特殊情况的限制

缺点：
无法判断执行了哪些sql,有点像黑盒子
不好跟踪问题
对于一些特殊语句比如update 全表的一个状态，这种基于行的开销会很大

Mysql会自动切换，当基于语句不行的时候就会尝试基于行的。

复制拓扑

• 一个备库只能有一个主库
• 每个备库必须有唯一id

• 打开log_slave_updates选项时，备库可以把其主库上的数据变化传播到其他备库

  一主多备

• 一个备库用于灾难恢复

• 适用于少写多读的场景。可以负载均衡
• 使用一个备库用于测试等等

• ALtertable这样的语句在备库执行，然后主备切换

  双主动双主库

  太乱，Mysql不支持

  主动-被动 双主结构

  可以认为是一个热备。 可以随时切换主备
  被动模式的主库也可以当备库一样使用

  主库带备库的 主动-被动 双主结构

  主动，被动两个库都各有一个备库

  分发主库

  作为被动的主库有多个备库。这种可以防止备库太多给主库带来负载
  但是这样就不能直接使用备库替换主库了。因为中转了一道bin_log不一样了

  树形

  一个主，多个备，备库又有备库的结构。
  好处跟分发主库有点像，可以减少多备库压力
  坏处在于如果沿途有节点除了问题，会影响多个节点

选择性复制

备库复制主库中不同的表。
简单的做法就是在主库中把表放入不同的数据库，然后备库只复制其中一个数据库。
这样每个备库都只有一部分的主库写入负载

备库的用途

• 数据分离 可以专门分离一个备库出来，做在线数据分析OLAP，而不是在线事务处理OLTP
• 数据归档 在备库上保存主库上删除的数据
  可以用过滤， 或者是user db1, replicate_ignore_db=db1这样的方式
• 备库做全文检索 把备库中的部分表用MyISAM引擎
• 只读备库

模拟多主库复制

Mysql不支持一个备库多主库， 可以让备库一会儿指向备库A，一会儿指向备库B， 这样增加一点额外的工作来记录bin-log位置

创建日志服务器

如果一个服务器崩溃了，我们去他的二进制日志或者中继日志，希望重放他。
这是可以勇mysqlbinlog工具。
更好的方式是，建立一个新的数据库，让他认为这些二进制文件时他的。然后启动他，让别的数据库来复制它来获得二进制文件进行重放
好处：

• 复制的速度很快
• 更方便处理错误
• 复制功能被测试过，运行良好

复制和容量规划

先看个计算，假设，读写消耗一样，读写比例2:8， 服务器只能每秒1000次请求。
这个时候做读写分离。 如果支撑请求翻倍需要增加多少台备库呢？
翻倍的话，要有400次写，1600次读，每个备库都会有400次写，那么这个时候就只能支撑600次读了，所以需要三台备库。

这样算下来，使用读写分离和备库的方式负载查询代价很高。
一般不要让读超过50%的负载，避免备库出现问题的时候造成单点热点过高。

可以停止备库，过一小时之后打开，看备库多久能赶上，来得到备库的执行性能
大多数情况下性能还是比较好的，在主库执行的耗时操作往往是备库延迟的原因。