mysql主从复制、读写分离

1、MySql介绍

MySQL做为世界上使用最为普遍的数据库之一，免费是其缘由之一。但不可忽略的是它自己的功能的确很强大。随着技术的发展，在实际的生产环境中，由单台MySQL数据库服务器不能知足实际的需求。

此时数据库集群就很好的解决了这个问题了。采用MySQL分布式集群，可以搭建一个高并发、负载均衡的集群服务器。在此以前咱们必需要保证每台MySQL服务器里的数据同步。

数据同步咱们能够经过MySQL内部配置就能够轻松完成，主要有主从(master slave )复制和主主复制。

2、主从复制介绍

在MySQL集群环境中，能够分为主节点与从节点，经过主从复制能够实现数据备份、故障转移、MySQL集群、高可用、读写分离等。

MySQL的主从复制是MySQL自己自带的一个功能，不须要额外的第三方软件就能够实现，其复制功能并非copy文件来实现的，而是借助binlog日志文件里面的SQL命令实现的主从复制，能够理解为我再Master端执行了一条SQL命令，那么在Salve端一样会执行一遍，从而达到主从复制的，同步数据的效果。

理解图:

3、主从复制原理

Mysql 中有一种日志叫作 bin 日志（二进制日志）。这个日志会记录下全部修改了数据库的SQL 语句（insert,update,delete,create/alter/drop table, grant 等等）。

MySQL的主从复制是MySQL自己自带的一个功能，不须要额外的第三方软件就能够实现，其复制功能并非copy文件来实现的，而是借助binlog日志文件里面的SQL命令实现的主从复制，

能够理解为我再Master端执行了一条SQL命令，那么在Salve端一样会执行一遍，从而达到主从复制的效果。

从库生成两个线程，一个I/O线程，一个SQL线程； i/o线程去请求主库 的binlog，并将获得的binlog日志写到relay log（中继日志） 文件中；

主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog； SQL 线程，会读取relay log文件中的日志，并解析成具体操做，来实现主从的操做一致，而最终数据一致；

复制流程图（来自网络）:

本身理解画图:

 复制过程:

一、主节点必须启用二进制日志，记录任何修改了数据库数据的事件。
二、从节点开启一个线程（I/O Thread)把本身扮演成 mysql 的客户端，经过 mysql 协议，请求主节点的二进制日志文件中的事件
三、主节点启动一个线程（dump Thread），检查本身二进制日志中的事件，跟对方请求的位置对比，若是不带请求位置参数，则主节点就会从第一个日志文件中的第一个事件一个一个发送给从节点。
四、从节点接收到主节点发送过来的数据把它放置到中继日志（Relay log）文件中。并记录该次请求到主节点的具体哪个二进制日志文件内部的哪个位置（主节点中的二进制文件会有多个，在后面详细讲解）。
五、从节点启动另一个线程（sql Thread ），把 Relay log 中的事件读取出来，并在本地再执行一次。

复制中线程的做用：

从节点：

I/O Thread: 从 Master 节点请求二进制日志事件，并保存于中继日志中。
Sql Thread: 从Relay log 中读取日志事件并在本地完成重放。

主节点：

Dump Thread:为每一个 Slave 的 I/O Thread 启动一个 dump 线程，用于向从节点发送二进制事件。
**思考：**从节点须要创建二进制日志文件吗？
看状况，若是从节点须要做为其余节点的主节点时，是须要开启二进制日志文件的。这种状况叫作级联复制。若是只是做为从节点，则不须要建立二进制文件。

Mysql复制特色：

一、异步复制：主节点中一个用户请求一个写操做时，主节点不须要把写的数据在本地操做完成同时发送给从服务器并等待从服务器反馈写入完成，再响应用户。

主节点只须要把写入操做在本地完成，就响应用户。可是，从节点中的数据有可能会落后主节点，可使用（不少软件来检查是否落后）
二、主从数据不一致。

主从复制配置过程：

主服务器节点 

1. 启用二进制日志。
2. 为当前节点设置一个全局惟一的server_id。
3. 建立有复制权限的用户帐号 REPLIACTION SLAVE ,REPLIATION CLIENT。

 vi  /etc/my.cnf  新增如下内容

server_id=177 ###服务器id log-bin=mysql-bin   ###开启日志文件

重启mysql服务 service mysqld restart

验证是否已经配置成功

show variables like '%server_id%';

可以查询对应配置文件中的server_id 说明已经配置成功,以下图:

show master status;

可以看到同步的文件，和行数 说明已经配置成功。如图

 

从服务节点:

            一、克隆服务器

            二、启动中继日志。

           三、为当前节点设置一个全局惟一的server_id。

           四、使用有复制权限的用户帐号链接至主节点，并启动复制线程。

vi /etc/my.cnf server_id=178 ###从服务器server_id log-bin=mysql-bin ###日志文件同步方式 binlog_do_db=test   ###同步数据库

 

重启mysql服务 service mysqld restart

验证是否已经配置成功

show variables like '%server_id%';

可以查询对应配置文件中的server_id 说明已经配置成功

从服务器同步主服务器配置

CHANGE MASTER TO MASTER_HOST='192.168.80.135',MASTER_USER='root',MASTER_PASSWORD='root', MASTER_LOG_FILE='mysql-bin.000004',MASTER_LOG_POS=415

参数详解： 
master_host： 主服务器的IP 
master_user： 主服务器上新建立的用户名 
master_password： 用户的密码 
master_port： 主服务器的端口，若是不曾修改，默认便可。 
master_log_file： 主服务器二进制日志文件的名称，填写查看主服务器的master状态时显示的File的值 
master_log_pos： 日志的位置，填写查看主服务器的master状态时显示的Position的值

开始同步 

start slave

检查从服务器复制功能状态

SHOW SLAVE STATUS

主要看这Slave_IO_Running、Slave_SQL_Running状态，为Yes则代表设置成功。

Slave_IO_Running：链接到主库，并读取主库的日志到本地，生成本地日志文件

Slave_SQL_Running:读取本地日志文件，并执行日志里的SQL命令。

 若是以下错误:

Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

解决办法

由于服务器克隆的时候交UUID产生了重复 ，解决办法

Cat  /etc/my.cnf

cd /var/lib/mysql

rm -rf auto.cnf

重启服务器便可

service mysqld restart