文章目录
- 主从原理
- 主从搭建
- 一、安装数据库实例
- 二、创建主从复制用户
- 三、备份主库数据恢复到从库
- 四、进行从库change master to
- 主从异常
- 主从故障
- IO_thread故障
- SQL_thread故障
- SQL_thread故障分析
- 主从延时（原理）
主从原理
主从复制主要是针对MySQL的主备库进行数据复制、备份。能保证主库输入的数据复制到从库的一种操作。
主从复制特点、实现、具备条件：
1、需要主库开启binlog日志，所有用户的记录都记录到主库的binlog
2、从库会请求基于主库的binlog日志进行数据复制的操作
3、主从复制还能处理对物理的损坏（在数据库外磁盘坏道、文件丢失、系统故障、数据删除等）
4、如果逻辑损坏处理起来比较麻烦，因为主库内进行删除，也会删除从库
（需要进行备份恢复或者做延时从库）
5、基于主从能延展更多的架构（高可用、高性能、分布式）主从复制搭建的条件：
1、需要两台或两台以上服务器或者两个数据库实例也行
2、需要创建专用的复制用户进行复制操作（replication slave）
3、主库开启二进制日志
4、主库如果有数据，需要进行全备，恢复到从库（适合于主库有大量数据）
5、在从库做change master to 操作，对主库进行连接作用
change master to（ip port user password,start position/GTID）
6、线程的开启（主：dump thread 从：io thread 、SQL thread）主从复制相关文件及线程
主库：
mysql-bin.000001 二进制日志
从库：
hdfeng-relay-bin.000002 中继日志文件
master.info 查看主库信息
relay-log.info 中继日志信息
主库线程：
dump_thread
从库线程：
IO_thread
SQL_thread主从复制原理描述：
涉及到的内容有以上这些
主从具体进行步骤为以上几步
文字描述：
1、实例搭建完成以后，进行从库的change master to配置，我们录入的信息会全部记录到master.info文件中
2、IO_thread通过master.info与dump_thread建立通道
3、主库会有一个dump_thread相应从库，
4、随后IO_thread通过master.info中的binlog和position号来告诉dump_thread线程进行binlog日志的读取
5、dump_thread检查主库的binlog，如果有最新的立即告诉IO_thread让它来拿数据
6、IO_thread拿到数据以后存入TCP/IP buffer，返回ACK给dump_thread，再把file以及pos位置记录到master.info，存储数据到realy-log
7、SQL_thread读取relay-log.info，获取执行的位置，SQL_thread再从获取的位置往后执行
8、SQL_thread执行完成以后更新relay-log.info文件
9、relay-log进行自动日志清理。
注：主库一旦有新的日志生成，会告诉dump_thread，然后让IO线程再进行请求主从搭建
一、安装数据库实例
准备好相应的软件包，开始安装：
初始化两个数据库("&"为两台机器都需要配置的内容)：
mysqld --initialize-insecure --user=mysql --basedir=/opt/mysql-basedir/mysql --datadir=/opt/mysql-replication/mysql3310&mysql3320/mysql
配置各自的my.cnf文件
vim /opt/mysql-replication/mysql3310&mysql3320/mysql/my.cnf
[mysqld]
basedir=/opt/mysql-basedir/mysql
datadir=/opt/mysql-replication/mysql3310&mysql3320/mysql
root=3310&3320
server_id=10&20
log_error=/opt/mysql-replication/mysql3310&mysql3320/mysql/
log_bin=/opt/mysql-replication/mysql3310/binlog/mysql-bin 主库开启二进制日志
配置文件写完，再写成服务：
vim /etc/systemd/system/mysqld3310.service&mysqld3320.service
[Unit]
Description=MySQL Server
Documentation=man:mysqld(8)
Documentation=http://dev.mysql.com/doc/refman/en/using-systemd.html
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
[Service]
User=mysql
Group=mysql
ExecStart=/opt/mysql-basedir/mysql/bin/mysqld --defaults-file=/opt/mysql-replication/mysql3310/mysql/my.cnf
LimitNOFILE=5000
增加权限：
[root@hdfeng system]# chown -R mysql.mysql /opt/mysql-replication/*
启动服务：
systsemctl start mysqld3310&mysqld3320
注：如果启动失败，那么就是配置文件出错，或者没有权限的问题，或者service服务配置错误
确认环境启动正常：
[root@hdfeng system]# mysql -S /opt/mysql-replication/mysql3310/mysql/mysql.sock -e "select @@server_id";
+-------------+
| @@server_id |
+-------------+
| 10 |
+-------------+
[root@hdfeng system]# mysql -S /opt/mysql-replication/mysql3320/mysql/mysql.sock -e "select @@server_id";
+-------------+
| @@server_id |
+-------------+
| 20 |
+-------------+二、创建主从复制用户
设置ROOT密码
[root@hdfeng mysql]# mysqladmin -uroot -p password -S /opt/mysql-replication/mysql3310&mysql3320/mysql/mysql.sock
Enter password:
New password:
Confirm new password:
Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety.登录数据库并创建Replication帐户：
mysql -uroot -p -S /opt/mysql-replication/mysql3310/mysql/mysql.sock
[(none)]>grant replication slave on *.* to repl@'192.168.%.%' identified by '123';
Query OK, 0 rows affected, 1 warning (0.01 sec)三、备份主库数据恢复到从库
使主从库达成数据上的一致：
备份主库：
mysqldump -uroot -p -S /opt/mysql-replication/mysql3310/mysql/mysql.sock -A --master-data=2 --single-transaction -R --triggers -E >/tmp/mysql3310.sql
查看备份文件的position号，后面需要用到：
[root@hdfeng mysql]# head -n 20 /tmp/mysql3310.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=707;从库恢复数据：
[root@hdfeng mysql]# mysql -uroot -p -S /opt/mysql-replication/mysql3320/mysql/mysql.sock
[(none)]>set sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)
[(none)]>source /tmp/mysql3310.sql;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
恢复完成！四、进行从库change master to
配置模板能直接从数据库中help change master to查看到
CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;对从库进行配置：
之前看的那个position号就需要在这里用到
CHANGE MASTER TO
MASTER_HOST='192.168.28.78',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3310,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=707,
MASTER_CONNECT_RETRY=10;
Query OK, 0 rows affected, 2 warnings (0.03 sec)开启线程：
[mysql]>start slave;
Query OK, 0 rows affected (0.02 sec)监控从库是否正常：
[mysql]>show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.28.78
Master_User: repl
Master_Port: 3310
Connect_Retry: 10
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 707
Relay_Log_File: hdfeng-relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes 这里为yes表示主从搭建成功
Slave_SQL_Running: Yes 这里为yes表示主从搭建成功
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 707
Relay_Log_Space: 528
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 10
Master_UUID: 7381b2f3-6345-11ea-a94a-000c29b6e0ec
Master_Info_File: /opt/mysql-replication/mysql3320/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)监控信息解读：
主库相关信息：
Slave_IO_State: Waiting for master to send event 表示等待主库发送事件
Master_Host: 192.168.28.78 主库ip
Master_User: repl 主库复制帐号
Master_Port: 3310 主库端口
Connect_Retry: 10
Master_Log_File: mysql-bin.000001 主库binlog日志
Read_Master_Log_Pos: 707 主库position号从库相关信息：
Relay_Log_File: hdfeng-relay-bin.000002 从库relaylog执行的文件
Relay_Log_Pos: 320 从库relaylog的position号
Slave_IO_Running: Yes 从库的IO线程去进行复制使用
Slave_SQL_Running: Yes 从库SQL线程负责写
Last_IO_Errno: 0 查看IO的报错信息
Last_IO_Error:
Last_SQL_Errno: 0 查看SQL的报错信息
Last_SQL_Error:
Replicate_Do_DB: 过滤复制相关信息
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Seconds_Behind_Master: 0 主从延时的信息（数据库自身的）
SQL_Delay: 0 延时从库相关信息（可人为操作）
SQL_Remaining_Delay: NULL
Retrieved_Gtid_Set: GTID相关内容
Executed_Gtid_Set:
Auto_Position: 0主从异常
主从故障
IO_thread故障
可能影响到的几个点：
1、ip error
2、port error
3、user，password error
4、user No permission
5、firewall
6、network
7、connection
8、master binlog损坏连接出现问题的一些图内容：
端口错误
ip错误
帐号密码错误
数据库未启动
连接数上限
这种就是典型的连接上限
master binlog损坏模拟（其中一种，其它被删除的操作也会造成以下情况）
主库中执行：
[(none)]>reset master;
Query OK, 0 rows affected (0.02 sec)
从库：
Slave_IO_Running: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'could not find next log; the first event 'mysql-bin.000002' at 154, the last event read from '/opt/mysql-replication/mysql3310/binlog/mysql-bin.000003' at 154, the last byte read from '/opt/mysql-replication/mysql3310/binlog/mysql-bin.000003' at 154.'
生产环境的话禁止使用reset master命令，可以使用expire进行定期的清理二进制日志。处理以上故障：
重新搭建主从
从库：
[(none)]>stop slave; 停止从库
Query OK, 0 rows affected (0.01 sec)
[(none)]>reset slave all ; 重置从库
Query OK, 0 rows affected (0.00 sec)
[(none)]>show slave status; 从库信息就没了
Empty set (0.00 sec)
因为测试环境数据比较少，所以恢复起来比较快
查看主库的binlog文件，还有position号进行change master to重新搭建
CHANGE MASTER TO
MASTER_HOST='192.168.28.78',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3310,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
Query OK, 0 rows affected, 2 warnings (0.04 sec)
[(none)]>start slave;
Query OK, 0 rows affected (0.01 sec)
[(none)]>show slave status\G;
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
主从重构成功！
如果是生产库需要重新导入备份文件以及二进制日志进行数据的恢复，然后再进行从库的搭建就行了。处理连接线数上限问题
vim /opt/mysql-replication/mysql3310/mysql/my.cnf
max_connections=100
或者直接在session中配置即可解决！
[(none)]>set global max_connections=100;SQL_thread故障
SQL线程的功能及会遇到的问题：
SQL线程的话主要是用来读写relay-log.info，如果relay-log有损坏，比如中间有数据漏掉了，或者接收到的pos号不对应，接收的SQL都无法进行执行。
SQL_thread故障分析
原因：
1、版本的差异
2、SQL_MODE原因
3、参数的差异
4、数据类型的差异
5、DML、DDL等操作已存在或者已删除，有一些意外的修改
一般的话都是从库做了写入操作所以才会发生以上问题故障演示：
在从库创建了一个库
[(none)]>create database t1;
Query OK, 1 row affected (0.00 sec)
[(none)]>show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| t1 |
+--------------------+
5 rows in set (0.00 sec)
然后去主库再创建这个库：
[(none)]>create database t1 charset utf8mb4;
Query OK, 1 row affected (0.00 sec)
这样的话SQL线程就会发生故障
Slave_SQL_Running: No
Last_SQL_Errno: 1007
Last_SQL_Error: Error 'Can't create database 't1'; database exists' on query. Default database: 't1'. Query: 'create database t1'解决方法：
方法1(有隐患)
从库中做以下操作
stop slave;
set global sql_slave_skip_counter=1;
start slave；进行隐患的验证：
主库做这个操作
[t1]>create table test(id int,sname varchar(20));
Query OK, 0 rows affected (0.03 sec)
[t1]>insert into test values(1,'wfed');
Query OK, 1 row affected (0.08 sec)
当去从库看的时候发现没有这条记录，因为字符编码不一样，现在SQL线程就报错了
[t1]>select * from test;
Empty set (0.01 sec)
报以下错误
Last_SQL_Errno: 1677
Last_SQL_Error: Column 1 of table 't1.test' cannot be converted from type 'varchar(80(bytes))' to type 'varchar(20(bytes) latin1)'虽然这种方法能解决问题，但是存在安全隐患，以上字符编码就是其中一种，在生产环境中使用可能会有风险，所以不是很建议使用这一种。
方法2
配置文件进行编辑：
vim /etc/my.cnf
slave-skip-errors =1007，1032，1062
跳过这些错误
1007：对象存在
1032：无法执行DML语句
1062：有key冲突以上的两种方法其实都是有风险的，最安全的就是重新构建主从，一切以主库为主
以下方法会更有效的避免这些情况的发生：
[t1]>set global read_only=1;
Query OK, 0 rows affected (0.00 sec)
设置从库只读状态，但是只针对普通用户，管理员用户无效。
注：也可以加中间件，使数据库进行读写分离。主从延时（原理）
GC（group commit） MTS（enhanced multi threaded slave）
主从延时主要就是主库操作完以后，从库需要延时一段时间才能赶上的一种过程。
主要的原因：
1、网络问题
2、主库和从库硬件配置差别过大
3、版本差异
4、参数等原因
主库层面的问题：
1、有可能存在二进制日志写入不及时的问题
相关参数：
select @@sync_binlog;
2、classic replication的主从复制中，dump_thread以事件为单元对binlog进行串行传输（5.6，5.5版本中）
缺点：
（1）主库并发事务量大的时候，主库可以并行写入，但是传入从库时只能串行传输
（2）主库有大事务进行的时候，由于要串行传输，会阻塞其它事务主库解决方案
1、5.6版本以后加入了GTID以后，必须开启GTID才有GC（group commit）机制，能并发进行传输日志到从库的IO了
2、到了5.7版本以后，就算不开启GTID，也能实现group commit的并行传输的操作，是匿名的GTID，建议的话还是进行开启GTID
3、大事务可以拆分成很多个小事务进行传输，适当的减少主从延时的时间从库层面的问题：
1、SQL线程导致的主从延迟
（1）从库默认情况下是单SQL线程，只能串行回放日志事务SQL，而主库能有多个不同的线程去执行操作，所以会导致延迟
（2）主库发生并发事务量较大，但是从库只能串行回放
（3）主库发生了大事务，阻塞后续的事务进行解决的方案
1、5.6版本开启GTID（必须开启）,加入了SQL多线程的机制，但是只能针对不同库下的事务进行并发回放。
2、5.7版本中，开启GTID，在SQL多线程方面，实现了逻辑时钟（logical_clock）级别的并发回放，在二进制日志中加入了seq_number机制，实现了基于事务级别的并发回放，叫做并行复制原理MTS（enhanced multi-threaded slave）
3、大事务还是只能拆成小事务进行传输，适当的减少主从延时时间
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
