主从复制架构演变介绍
职责：
1搭建主从复制
2主从原理的熟悉
3主从故障处理
4主从延时
5主从的特殊架构
6主从特殊架构的配置使用
7主从架构的演变
搭建主从
1准备多实例
重新初始化3307
mysqld--initialize-insecure--user=mysql--basedir=/app/mysql--datadir=/data/3307/data
修改my.cnf ,开启二进制日志功能
[root@db013307]# vim/data/3307/my.cnf log_bin=/data/3307/data/mysql-bin
主库创建复制用户3307
mysql -uroot -p123 -S /data/3307/mysql.sock -e "grant replication slave on *.* to ligang@'%' identified by '123'"
mysqldump -root -p123 -S /data/3307/mysql.sock -A --master-data=2 --single-transaction -R --triggers >/backup/full.sql
mysqldump -S /data/3307/mysql.sock-A--master-data=2--single-transaction-R--triggers>/backup/full.sql--CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002',MASTER_LOG_POS=154;
从库3308
set sql_log_bin=0
source /backup/full.sql
告诉主库谁是从库
mysql -S /data/3308/mysql.sock
help change master to
CHANGE MASTER TO
MASTER_HOST='192.168.80.134',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=437,
MASTER_CONNECT_RETRY=10;
开启复制线程
show slave status \G
告诉从库开始你的表演
show slave status \G
grant all on *.* to ligang@'%' identified by '123';
主从复制工作原理
主库：
binlog
从库：
relaylog
master.info
relaylog.info
主从涉及的线程：
主库：
binlog_dump thread :dump_t
从库：
slave_io_thread
slave_sql_thread
主从复制原理
监控
show full processlists;
show slave status \G
************************* 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.80.134
Master_User: repl
Master_Port: 3307
Connect_Retry: 10
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 733
Relay_Log_File: localhost-relay-bin.000002
Relay_Log_Pos: 616
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
show master status;
File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 | 733 | | | |
主从延时相关状态(非人为)
Seconds_Behind_Master: 0
延时从库有关的状态(人为)
SQL_Delay:0SQL_Remaining_Delay:NULL
GTID 复制有关的状态
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
主从复制故障 ******
从库：
io 线程故障
连接主库
网络，连接信息错误或者变更了，防火墙没开端口，连接数上线
排查思路：
使用复制用户手工登录
1stop slave
2reset slave all
3change master to
4 start slave
最容易出的问题 就是二进制日志的损坏
sql线程故障：
relay_log损坏
回放relayl_og
研究SQL语句为什么失败？
insert delete update
有可能连到从库
解决：一切以主库为准
主键冲突：
稳妥的结局方案，更新那个错误的主键然后 跳过那个。。
1 从库只读
2 读写分离中间件
mycat
主从延时 *****
主库做了修改操作,从库比较长时间才能追上.
网络
主从硬件差异较大
版本差异
参数因素
主库
(1)二进制日志写入不及时
[rep]>select @@sync_binlog;
(2)CR的主从复制中,binlog_dump线程,事件为单元,串行传送二进制日志(5.6 5.5)
1. 主库并发事务量大,主库可以并行,传送时是串行
2. 主库发生了大事务,由于是串行传送,会产生阻塞后续的事务.
解决方案:
1. 5.6 开始,开启GTID,实现了GC(group commit)机制,
可以并行传输日志给从库IO2. 5.7 开始,
不开启GTID,会自动维护匿名的GTID,也能实现GC,
我们建议还是认为开启GTID3. 大事务拆成多个小事务,可以有效的减少主从延时.
从库
SQL线程导致的主从延时
在CR复制情况下:从库默认情况下只有一个SQL,只能串行回放事务SQL
1. 主库如果并发事务量较大,从库只能串行回放
2. 主库发生了大事务,会阻塞后续的所有的事务的运行
解决方案:
1. 5.6 版本开启GTID之后,加入了SQL多线程的特性,但是只能针对不同库(database)下的事务进行并发回放.
2. 5.7 版本开始GTID之后,在SQL方面,提供了基于逻辑时钟(logical_clock),binlog加入了seq_no机制,
真正实现了基于事务级别的并发回放,这种技术我们把它称之为MTS(enhanced multi-threaded slave).
3. 大事务拆成多个小事务,可以有效的减少主从延时.[https://dev.mysql.com/worklog/task/?id=6314]
