MySQL传统主从复制
为什么要做主从复制
做主从复制的目的，并不是为了备份
为了解决主库的单点故障
为了减少主库的压力（读写分离）
复制是 MySQL 的一项功能，允许服务器将更改从一个实例复制到另一个实例。
1.主从复制将所有数据和结构更改记录到二进制日志中。
2.从属服务器从主服务器请求该二进制日志并在本地应用其内容。
3.IO：请求主库，获取上一次执行过的新的事件，并存放到relaylog
4.SQL：从relaylog中将sql语句翻译给从库执行
主从复制相关线程和文件
# 线程
dump线程：主库上的线程，从binlog中取出数据交给从库的IO线程
IO线程：从库上的线程，连接主库dump线程取数据，取出数据写入缓存(relay log中)
SQL线程：从库上的线程
# 文件
binlog日志：主库上的文件，记录所有更改库表的语句
master.info:主库上的文件，记录主库的binlog名字和位置点，IO线程更新/获取
relay-log:从库上的文件，记录从主库binlog拿来的新数据
mysql主从复制原理
主从复制前提条件
- 两台或两台以上的数据库实例
- 主库要开启二进制日志
- 主库要有复制用户
- 主库的server_id和从库不同
- 从库需要在开启复制功能前，要获取到主库之前的数据（主库备份，并且记录binlog当时位置）
- 从库在第一次开启主从复制时，必须要货值主库：ip、port、user、password、logfile、pos
- 从库要开启相关线程：IO、SQL
- 从库需要记录复制相关用户信息，还应该记录到上次已经从主库请求到哪个二进制日志
- 从库请求过来的binlog，首先要存下来，并且执行binlog，执行过的信息保存下来
文字版原理
-
通过change master to语句告诉从库主库的ip，port，user，password，file，pos
-
从库通过start slave命令开启复制必要的IO线程和SQL线程
-
从库通过IO线程拿着change master to用户密码相关信息，连接主库，验证合法性
-
从库连接成功后，会根据binlog的pos问主库，有没有比这个更新的
-
主库接收到从库请求后，比较一下 binlog信息，如果有就将最新数据通过dump线程给从库IO线程
-
从库通过IO线程接收到主库发来的binlog事件， 存储到TCP/IP缓存中，并返回ACK更新master.info
-
将TCP/IP缓存中的内容存到relay-log中 8）SQL线程读取
relay-log.info，读取到上次已经执行过的relay-log位置点，继续执行后续的relay-log日志，执行完成后，更新relay-log.info
主从复制搭建(数据一致)
环境准备
| 主机名 | WanIP | LanIP | 角色 | 数据 |
|---|---|---|---|---|
| mo1 | 10.0.0.53 | 172.16.1.53 | Master | 有 |
| db02 | 10.0.0.52 | 172.16.1.52 | Slave | 无 |
搭建主从(主从)
# 1.修改配置文件
[root@db03 ~]# vim /etc/my.cnf
log-bin=/tmp/zh-bin
server_id=1
# 2.重启
[root@db03 ~]# /etc/init.d/mysqld restart
# 3.给主库做全备
[root@db03 ~]# mysqldump -A -R --triggers --master-data=2 --single-transaction|gzip > /opt/full.sql.gz
# 4.将全备拷贝到从库
[root@db03 ~]# scp /opt/full.sql.gz 172.16.1.52:/opt/
# 5.创建主从复制用户
grant replication slave on *.* to rep@'172.16.1.%' identified by '123';
# 非生产环境
mysql> show master status;
+---------------+----------+
| File | Position |
+---------------+----------+
| zh-bin.000001 | 445 |
+---------------+----------+
搭建主从(从库)
# 1.修改配置文件
[root@db02 bin]# vim /etc/my.cnf
[mysqld]
server_id=2
# 2.重启数据库
[root@db02 bin]# /etc/init.d/mysqld restart
# 3.导入数据库
[root@db02 bin]# zcat /opt/full.sql.gz |mysql
# 4.查找位置点
[root@db02 bin]# zcat /opt/full.sql.gz |head -25
-- CHANGE MASTER TO MASTER_LOG_FILE='zh-bin.000001', MASTER_LOG_POS=154;
# 5.执行change master to语句
change master to
master_host='172.16.1.53',
master_user='rep',
master_password='123',
master_log_file='zh-bin.000001',
master_log_pos=154;
# 6.开启主从复制
mysql> start slave;
# 7.查看主从复制
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
#开启主从复制
start slave;
#关闭主从复制
stop slave;
# 重置主从复制
stop slave;
reset slave all;
主从复制故障处理
# 查看状态
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
# 1.IO线程故障
mysql> show slave status\G
Slave_IO_Running: No
Slave_SQL_Running: Yes
IP错了
用户名错了
密码错了
文件名错了
change master to
master_host='172.16.1.53',
master_user='rep',
master_password='123',
master_log_file='zh-bin.000001',
master_log_pos=154; // 不影响IO线程
# 排查流程
# IP错了：
ping 172.16.1.53
# 端口错了
telnet 172.16.1.53 3306
# 用户名错了 和 密码错了
mysql -urep -p123 -h172.16.1.61
# 报错：
Warning: Using a password on the command line interface can be insecure.ERROR 1045 (28000): Access denied for user 'rep'@'db01' (using password: YES)
# 解决办法：
vim /etc/my.cnf
[mysqld]
skip_name_resolve
/etc/init.d/mysqld restart
# 文件名错了
zcat /opt/full.sql.gz |head -25
## 解决方案
stop slave;
reset slave all;
change master to
master_host='172.16.1.53',
master_user='rep',
master_password='123',
master_log_file='zh-bin.000001',
master_log_pos=154; // 不影响IO线程
start slave;
# 2.SQL线程故障
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
# 主库从库数据不一致导致
# 情况一：主库有，从库没有
#查看状态
mysql> show slave status\G
Last_Errno: 1049
Last_Error: Error 'Unknown database 'test_sql_thread'' on query. Default database: 'test_sql_thread'. Query: 'create table tb1(id int)'
#### 解决方案一
# 1.停止从库的主从复制
mysql> stop slave;
# 2.跳过一次错误
mysql> set global sql_slave_skip_counter=1;
# 3.开启主从复制
mysql> start slave;
####解决方案二
1.重新备份数据库，恢复到从库
2.给从库设置只读
# 在命令行临时设置
set global read_only=1;
# 在设置文件中永久生效
read_only=1
##情况二：主库没有从库没有
# 临时停止同步
mysql> stop slave;
#将同步指针向下移动一个（可重复操作）
mysql> set global sql_slave_skip_counter=1;
#开启同步
mysql> start slave;
# 3.蠢货故障
mysql> show slave status\G
Slave_IO_Running: No
Slave_SQL_Running: No
# 解决办法
start slave;
延时从库
想用主从复制做备份
企业一般会延时3-6小时
配置延时从库
# 1.先停止slave
mysql> stop slave;
# 2.设置主从延时
change master to master_delay=120;
# 3.开启主从复制
mysql> start slave;
# 4.查看状态
SQL_Delay: 120
#5.没有主从时配置
change master to
master_host='172.16.1.53',
master_user='rep',
master_password='123',
master_log_file='zh-bin.000001',
master_log_pos=154;
master_delay=120;
# 启停SQL线程
mysql> stop slave sql_thread;
mysql> start slave sql_thread;
# 启停IO线程
mysql> stop slave io_thread;
mysql> start slave io_thread;
MySQL的半同步复制
从MYSQL5.5开始，支持半自动复制。之前版本的MySQL Replication都是异步（asynchronous）的，主库在执行完
一些事务后，是不会管备库的进度的。如果备库不幸落后，而更不幸的是主库此时又出现Crash（例如宕机），这时
备库中的数据就是不完整的。简而言之，在主库发生故障的时候，我们无法使用备库来继续提供数据一致的服务了。
半同步复制（Semi synchronous Replication）则一定程度上保证提交的事务已经传给了至少一个备库。 出发点是
保证主从数据一致性问题，安全的考虑。
5.5 出现概念，但是不建议使用，性能太差 5.6出现group commit 组提交功能，来提升开启半同步复制的性能 5.7更
加完善了，在group commit基础上出现了MGR 5.7的增强半同步复制的新特性：after commit； after sync；
# 主库操作
# 1.是否动态支持半同步复制
mysql> show global variables like 'have_dynamic_loading';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| have_dynamic_loading | YES |
+----------------------+-------+
# 2.插件的路径
[root@db02 plugin]# pwd
/application/mysql/lib/plugin
-rwxr-xr-x 1 mysql mysql 721549 Mar 22 02:14 semisync_master.so
-rwxr-xr-x 1 mysql mysql 163324 Mar 22 02:14 semisync_slave.so
# 3.主库安装半同步插件
mysql> install plugin rpl_semi_sync_master soname'semisync_master.so';
# 4.启动插件
mysql> set global rpl_semi_sync_master_enabled = 1;
# 5.设置超时时间
mysql> set global rpl_semi_sync_master_timeout = 1000;
# 6.修改配置文件
[root@db03 plugin]# vim /etc/my.cnf
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000
# 7.检查安装
mysql> show variables like'rpl%';
+-------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 1000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
| rpl_stop_slave_timeout | 31536000 |
+-------------------------------------------+------------+
# 8.查看半同步信息
mysql> show global status like 'rpl_semi%';
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 0 |
| Rpl_semi_sync_master_net_avg_wait_time | 0 |
####从库操作
# 1.安装从库半同步插件
mysql> install plugin rpl_semi_sync_slave soname'semisync_slave.so';
# 2.开启插件
mysql> set global rpl_semi_sync_slave_enabled = 1;
# 3.重启IO线程
mysql> stop slave io_thread;
mysql> start slave io_thread;
# 4.修改配置文件
[mysqld]
rpl_semi_sync_slave_enabled =1
# 注：相关参数说明 rpl_semi_sync_master_timeout=milliseconds 设置此参数值（ms）,为了防止半同步复制在没有收到确认的情况下发生堵塞，如果Master在超时之前没有收到任何确认，将恢复到正常的异步复制，并继续执行没有半同步的复制操作。
rpl_semi_sync_master_wait_no_slave={ON|OFF} 如果一个事务被提交,但Master没有任何Slave的连接，这时不可
能将事务发送到其它地方保护起来。默认情况下，Master会在时间限制范围内继续等待Slave的连接，并确认该事务
已经被正确的写到磁盘上。 可以使用此参数选项关闭这种行为，在这种情况下，如果没有Slave连接，Master就会恢
复到异步复制。
MySQL过滤复制
# 错误做法
mysql> grant replication slave on LOL.* to rep_lol@'172.16.1.%' identified by '123'; ERROR 1221 (HY000): Incorrect usage of DB GRANT and GLOBAL PRIVILEGES replication slave权限是一个全局的权限，只能针对*.* 所有库所有表
-
主库
- 黑名单：主库拒绝让从库，复制指定库的数据
- 原理：不记录指定数据库数据到binlog日志中
- binlog-ignore-db
- 白名单：主库只想让从库复制指定库的数据
- 原理：只记录指定的库数据到binlog日志中
- binlog-do-db
# 主库白名单配置 [root@db03 ~]# vim /etc/my.cnf [mysqld] binlog-do-db=lol show master status; # 配置多个库 binlog-do-db=lol binlog-do-db=cf - 黑名单：主库拒绝让从库，复制指定库的数据
-
从库
- 黑名单：从库SQL线程，不拿relay log中的指定库语句
- replicate-ignore-db=mysql
- replicate-ignore-table=mysql.user
- replicate-wild-ignore-table=mysql.t*
- 白名单
- replicate-do-db=mysql
- replicate-do-table=mysql.user
- replicate-wild-do-table=mysql.t*
- 黑名单：从库SQL线程，不拿relay log中的指定库语句