MySQL复制即相关维护
## MySQL复制原理及简介
1 复制的优点
如果主库出现问题,可以快速切换到从库。
可以再从从库上执行查询操作,降低主库的访问压力。
可以在从库上实现备份,避免备份期间影响主库服务。
2 复制流程概述
1 首先,MySQL主库在事务提交时会把数据变更作为时间Events记录在二进制日志文件Binlog中;MySQL主库上的sync_binlog控制binlog日志刷新到磁盘。
当这个值是0或者1 的时候这个延时是由binlog_group_commit_sync_delay(即磁盘上等待多长时间统一提交)指定的。而次数大于n的时候意思是每n此提交。源自MySQL5.7文档
2 主库推送二进制日志文件Binlog中的事件到从库的中继日志Relay Log,之后从库根据中级日志重做数据变更操作,最终达到主从一直的目的。
3 MySQL通过三个线程来完成主从库之间的数据复制:Binlog Dump线程跑在主库上,I/O线程和SQL线程跑在从库上。当从库启动复制的时候,首先创建i/O线程连接主库,主库随后创建Binlog Dump线程读取数据库时间发送给I/O线程,I/O线程获取到事件数据后更新到中继日志中去,之后从库的SQL线程读取中继日志中的更新并运用。
show processlist可以查看主库上的Binlog Dump线程
show slave status 可以查看从库复制状态
3 Binlog 三种复制方式
1、Statement基于SQL语句级别的Binlog,每条修改数据的SQL都会保存。
2、Row基于行级别,记录每一行数据的变化。不会因为存储过程或者触发器造成主从库不一致,但是记录日志量会比上一个大很多。
3、Mixed,混合Statement和Row模式默认情况下采用Statement模式某些情况下采用Row。
使用binlog-format 变量记录,更改设置方法
set global binlog_format = ‘Row’如果没有global则是当前session。
show binlog events 可以查看Update操作在Binlog日志文件中对应的位置。
4 常见架构
1 一主多从
2 多级复制 减小主机压力
可以使用BLACKHOLE引擎来降低多级复制的延时,他的操作仅在Binlog里面记录。
3 双主架构,避免了从库的额外工作。
搭建过程
1 首先尽量保证版本一致且版本最新。(我是5.6 5.7 成功但是还是建议版本号越近越新越好。)
2 在主库上设置使用账户给予REPLICATION SLAVE权限
GRANT REPLICATION SLAVE ON . to ‘repl‘@’ip地址’ identified by ‘password’;
3 修改主库上的my.cnf配置文件开启binlog设置server-id1
2
3
4
5
6
7
8
9
10
11
12
13server-id=1 //给数据库服务的唯一标识,一般为大家设置服务器Ip的末尾号
log-bin=master-bin
log-bin-index=master-bin.index
```
4 封住主库避免修改影响主从同步。
>flush tables with read lock;
5 得到主库当前的二进制日志名和偏移量值。**并记录下来**
>show master status;
6 主从复制保持同步。并解锁。
7 配置从库
server-id=2
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin1
8 创建到主库的连接
change master to master_host=’192.168.0.104’, //Master 服务器Ip
master_port=3306,
master_user=’repl’,
master_password=’mysql’,
master_log_file=’master-bin.000001’,//Master服务器产生的日志
master_log_pos=0;`
9 在从库上启动slave线程
start slave;
10 之后就可以在主库上插入点数据看看啦~~~测试是否成功
其它配置
log-slave-updates
用来配置从库的更新是否写入二进制文件,以便将其作为其他的主库。
master-connect-retry
用来设置和主库的连接丢失重试的时间间隔,默认是60s
read-only
只允许超级用户更新操作。
replicate0do-db、replicate-do-table、replicate-ignore-db、replicate-ignore-table
表示记录的表以及忽略的表在binlog中
日常维护
1、 查看从库状态
show slave status
进程 Slave_IO_Running :从此进程负责的从库和主库上读取BINLOG日志,并写入从库上的中继日志。
进程 Slave_SQL_Running 此进程负责读取并执行中继日志中的binlog日志。
2、主从同步维护
由于双机性能不同可能导致主从性能不同,同步不同。
1、主库上首先阻止读入。
FLUSH TABLESWITH READ LOCK
2、在从库上使用MASTER_POS_WAIT()函数的参数是钱买步骤中得到的日志位置值。
select MASTER_POS_WAIT(‘日志名’,’位置值’)
这个日志会阻塞知道从库抵达该位置,返回0.如果返回-1则代表超时。
3、UNLOCK解锁。
UNLOCK TABLES
3、复制出错
如果复制出现问题首先确认是不素食表结构不一致导致的,如果是则修改表结构到一致 。
如果不是那么是某一句话出现的问题可以采用忽略这句话,或者是不将其记录到log中在在从库中进行操作保证服主从同步。
4、查看从库复制进度
使用show processlist 列表中的Slave_SQL_Running 线程的time进行比较。
也可以用show slave status查看从库落后主库的事件。(Seconds_Behind_Master)
另外为了提高从库复制效率还可以将主库的数据库分别复制到不同的从库上分担性能。也就是一个数据库中只负责主库的几个数据库。
5、主从切换
1、首先确保所有的从库都已经执行了relay log中的全部更新,在每个从苦涩,执行STOP SLAVE IO_THREAD然后检查SHOW PROCESSLIST的输出知道状态都是 Has read all relay log。
2、在从库A1上,执行STOP SLAVE以停止服务,然后执行RESET MASTER以重置成主数据库;
3、在其余数据库上执行STOP SLAVE以停止服务,然后执行CHANGE MASTER TO MASTER_HOST =’S1’重新设置主库,在执行START SLAVE以启动复制。
4、通知所有的客户端将主库指向S1。