主从复制介绍
- 主从复制基于binlog来实现的
- 主库发生新的操作,都会记录到binlog
- 从库取得主库的binlog进行“回放”
- 主从复制的过程是异步的
搭建主从复制的前提
- 2个或以上的数据库实例
- 主库需要开启二进制日志
- server_id要不同,区分不同的节点
- 主库需要建立专用的复制用户 (replication slave)
- 从库应该通过备份主库,恢复的方法进行"补课"
- 人为告诉从库一些复制信息(CHANGE MASTER TO)
- 从库应该开启专门的复制线程
主从复制工作过程
- 从库执行change master to 命令(主库的连接信息+复制的起点)
- 从库会将以上信息,记录到master.info文件
- 从库执行 start slave 命令,立即开启IO线程和SQL线程
- 从库 IO线程,读取master.info文件中的信息
- 从库IO线程请求连接主库,主库专门提供一个DUMP线程,负责和IO线程交互
- IO线程根据binlog的位置信息(mysql-bin.000004 , 444),请求主库新的binlog
- 主库通过DUMP线程将最新的binlog,通过网络TP给从库的IO线程
- IO线程接收到新的binlog日志,存储到TCP/IP缓存,立即返回ACK给主库,并更新master.info
- IO线程将TCP/IP缓存中数据,转储到磁盘relaylog中.
- SQL线程读取relay.info中的信息,获取到上次已经应用过的relaylog的位置信息
- SQL线程会按照上次的位置点回放最新的relaylog,再次更新relay.info信息
- 从库会自动purge应用过的relay进行定期清理
一旦主从复制构建成功,主库当中发生了新的变化,都会通过dump线程发送信号给IO线程,增强了主从复制的实时性.
主从复制的作用
- 备份。主库down了自动切换到从库
- 在数据库层面上实现读写分离
主从复制搭建
构建MySQL多实例
-
准备多个数据目录
[root@localhost ~]# mkdir -p /data/3307/data -
准备配置文件
cat > /data/3307/my.cnf <<EOF [mysqld] basedir=/app/mysql datadir=/data/3307/data socket=/data/3307/mysql.sock log_error=/data/3307/mysql.log port=3307 server_id=7 log_bin=/data/3307/mysql-bin binlog_format=row ----------启用GTID模式构建主从 gtid-mode=on --启用gtid类型，否则就是普通的复制架构 enforce-gtid-consistency=true --强制GTID的一致性 log-slave-updates=1 --slave更新是否记入日志 sync_binlog=1 --每次事务提交都立即刷写binlog到磁盘 最高安全模式 innodb_flush_log_at_trx_commit=1(0：一秒会发生n多事务，断电可能会丢失1秒内的所有事务；2(分两步提交事务，一步只保证刷写到os buffer。)) Innodb_flush_method=O_DIRECT 最高性能: innodb_flush_log_at_trx_commit=0 innodb_flush_method=fsync EOF -
初始化数据库
mv /etc/my.cnf /etc/my.cnf.bak mysqld --initialize-insecure --user=mysql --datadir=/data/3307/data --basedir=/application/mysql -
设置以systemd的方式启动数据库(Centos6省略)
cd /etc/systemd/system cp mysqld.service mysqld3307.service vim mysqld3307.service # 修改为: ExecStart=/application/mysql/bin/mysqld --defaults-file=/data/3307/my.cnf -
授权数据目录
chown -R mysql.mysql /data/* -
启动数据库
systemctl start mysqld3307.service //Centos6启动方式 mysqld_safe --defaults-file=/data/3307/my.cnf & //Centos6关闭方式 mysqladmin -S /data/3307/mysql.sock shutdown //Centos6设置多实例密码 mysqladmin -uroot -S /data/3307/mysql.sock password '2' -
验证多实例
netstat -lnp|grep 330 -
开启binlog
log_bin=/data/3307/mysql-bin -
在主库创建复制用户
mysql -uroot -p1 -e "grant replication slave on *.* to repl@'192.168.63.%' identified by '123'" -
要求数据完全一致则先备份主库的数据导入从库
mysqldump -uroot -p2 -p 3306 -A --master-data=2 --single-transaction -R -E --triggers >/tmp/full.sql -
在从库导入数据
mysql> source /tmp/full.sql -
告诉从库信息
CHANGE MASTER TO MASTER_HOST='192.168.63.128', //主库IP地址 MASTER_USER='repl', 主库授权给从库的用户名及密码 MASTER_PASSWORD='123', MASTER_PORT=3306, 主库端口 #MASTER_LOG_FILE='mysql-bin.000006', vim /tmp/full.sql查看主库的binlog及pos #MASTER_LOG_POS=1210, 主库pos MASTER_AUTO_POSITION=1;开启了GTID模式则不需加以上两行 #MASTER_AUTO_POSITION=？;如果是导如通过xtrabackup备份的数据应该查看binlog填写 MASTER_CONNECT_RETRY=10; 重连次数 -
从库开启复制线程(IO,SQL)
mysql> start slave; -
检查主从复制状态、排错
mysql> show slave status \G
主从复制故障
- IO线程故障（connecting）
可能原因：
(1)网络、防火墙、连接数上限
解决：
stop slave;
reset slave all;
change master to
start slave
(2)请求binlog遇到的问题，比如binlog没开启或者损坏
解决：
主库：reset master
从库：stop slave；
reset slave all；
change master to
start slave
- SQL线程故障
可能原因：
relay-log损坏
合理解决方法：
把握一个原则,一切以主库为准进行解决.
如果出现问题,尽量进行反操作
最直接稳妥办法,重新构建主从
暴力的解决方法
方法一：
stop slave;
set global sql_slave_skip_counter = 1;
start slave;
#将同步指针向下移动一个，如果多次不同步，可以重复操作。
start slave;
方法二：
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常见的错误代码：
1007：对象已存在
1032：无法执行DML
1062：主键冲突，或约束冲突
为了很大程度避免SQL线程故障，我们一般配置主从读写分离:
从库只读：
read_only
super_read_only
使用读写分离中间件，比如mycat、atlas、proxySQL、Maxscale
主从延时监控主要原因
(1) binlog写入不及时
sync_binlog=1
(2) 默认情况下dump_t 是串行传输binlog *****
在并发事务量大时或者大事务,由于dump_t 是串行工作的,导致传送日志较慢，如何解决问题?
必须启用GTID,使用Group commit方式.可以支持DUMP_T并行
(3) 主库极其繁忙
慢语句
锁等待
从库个数
网络延时
从库方面可能原因：
(1) 传统复制(Classic)中
如果主库并发事务量很大,或者出现大事务，由于从库是单SQL线程,导致不管传的日志有多少,只能一次执行一个事务.
5.6 版本,有了GTID,可以实现多SQL线程,但是只能基于不同库的事务进行并发回放.(database)
5.7 版本中,有了增强的GTID,增加了seq_no,增加了新型的并发SQL线程模式(logical_clock),MTS技术
(2) 主从硬件差异太大
(3) 主从的参数配置
(4) 从库和主库的索引不一致
(5) 版本有差异