mysql主从复制与读写分离
一、主从复制以及主从复制的作用
在实际的生产环境中，对数据库的读和写都在同一个数据库服务器中，是不能满足实际需求的，通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。
二、mysql主从复制的原理:
在每个事务更新数据完成之前，master在二进制日志记录这些改变。写入二进制日志完成后，master通知存储引擎提交事务。
Slave将master的binary log复制到其中继日志。首先slave开始一个工作线程（I/O），I/O线程在master上打开一个普通的连接，然后开始binlog dump process。binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件，I/O线程将这些事件写入中继日志。
Sql slave thread（sql从线程）处理该过程的最后一步，sql线程从中继日志读取事件，并重放其中的事件而更新slave数据，使其与master中的数据一致，只要该线程与I/O线程保持一致，中继日志通常会位于os缓存中，所以中继日志的开销很小。
三、Mysql主从复制实战
3.1 环境说明
- 两个CentOS7的虚拟机
- Master_IP:192.168.150.16
- slave_IP:192.168.150.17
注意：MySQL版本号最好一致，为了方便学习测试，建议大家直接克隆虚拟机然后修改下网卡配置文件，重新设置一个IP，并关闭防火墙。
mysql 5.6以后的复制引入了uuid的概念，各个复制结构中的server_uuid得保证不一样，但是查看到直接copy data文件夹后server_uuid是相同的
查看mysql uuid：
show variables like ‘%server_uuid%’;
解决办法：找到/var/lib/mysql文件夹下的auto.cnf文件，修改里面的uuid值，保证各个db的uuid不一样。
重启mysql即可。
3.2 复制的基本原则
- 每个Slave只有一个Master
- 每个Slave只能有一个唯一的服务ID
- 每个Master可以有多个Slave
3.3 实现MySQL主从复制需要进行的配置
主服务器：
- 开启二进制日志 binlog
- 配置唯一的server-id
- 获得master二进制文件名及位置
- 创建一个用于slave和master通信的用户账号
从服务器：
- 配置唯一的server-id
- 使用master分配的用户账号读取master二进制日志
- 启动slave服务
具体操作如下：
找到的配置文件my.cnf，我的在/etc/my.cnf,在[mysqld]部分插入如下：
修改master配置：
[mysqld]
#开启二进制日志
log-bin=mysql-bin
#设置server-id，建议使用ip最后2位
server-id=16
修改slave配置：
[mysqld]
#开启中继日志
relay-log=mysql-relay
#设置server-id，建议使用ip最后2位
server-id=17
重启mysql服务
3.4 在主机(master)上建立账户并授权slave
创建用于zcf并给予权限：
create user 'zcf'@'%' identified with mysql_native_password by 'Zcf@201104';
GRANT REPLICATION SLAVE ON *.* TO 'zcf'@‘%‘;
flush privileges;
查询master状态：
mysql> show master status \G;
*************************** 1. row ***************************
File: mysql-bin.000004
Position: 154
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)
ERROR:
No query specified
3.5 在(slave)告知从服务器二进制文件名与位置（从服务器操作)
这里要根据上面主服务器的状态来填写，不要直接用下面的SQL，需要根据实际值修改。
change master to
master_host = ‘192.168.42.16’, #主库的IP地址
master_user = ‘zcf’, #在主库上创建的复制账号
master_password = 'Zcf@201104', #在主库上创建的复制账号密码
master_log_file = ‘mysql-bin.000004’, #开始复制的二进制文件名（从主库查询结果中获取）
master_log_pos = 154; #开始复制的二进制文件位置（从主库查询结果中获取）
查询slave状态：
mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.150.16
Master_User: zcf
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 154
Relay_Log_File: mysql-relay.000014
Relay_Log_Pos: 367
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes ##
Slave_SQL_Running: 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: 154
Relay_Log_Space: 736
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: 16
Master_UUID: cbb62356-38c0-11ed-922a-000c2911fea4
Master_Info_File: /var/lib/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)
ERROR:
No query specified
查看从服务器状态
start slave; ##开启服务
注意：上述出现两个YES才正确连接