mysql 主从

mysql主从

什么是mysql主从复制

 MySQL主从复制是其最重要的功能之一。主从复制是指一台服务器充当主数据库服务器，另一台或多台服务器充当从数据库服务器，主服务器中的数据自动复制到从服务器之中。对于多级复制，数据库服务器即可充当主机，也可充当从机。MySQL主从复制的基础是主服务器对数据库修改记录二进制日志，从服务器通过主服务器的二进制日志自动执行更新。

主从复制类型

基于语句的复制

 主服务器上面执行的语句在从服务器上面再执行一遍，在MySQL-3.23版本以后支持。
 
 缺点：时间上可能不完全同步造成偏差，执行语句的用户也可能是不同一个用户。

基于行的复制

 把主服务器上面改编后的内容直接复制过去，而不关心到底改变该内容是由哪条语句引发的，在MySQL-5.0版本以后引入。
 
 缺点：比如一个工资表中有一万个用户，我们把每个用户的工资+1000，那么基于行的复制则要复制一万行的内容，由此造成的开销比较大，而基于语句的复制仅仅一条语句就可以了。

混合类型的复制

 MySQL默认使用基于语句的复制，当基于语句的复制会引发问题的时候就会使用基于行的复制，MySQL会自动进行选择。
 
 在MySQL主从复制架构中，读操作可以在所有的服务器上面进行，而写操作只能在主服务器上面进行。主从复制架构虽然给读操作提供了扩展，可如果写操作也比较多的话（多台从服务器还要从主服务器上面同步数据），单主模型的复制中主服务器势必会成为性能瓶颈。

原理

主从（master-slave）

 主服务器上面的任何修改都会保存在二进制日志Binary log里面，从服务器上面启动一个I/O thread（实际上就是一个主服务器的客户端进程），连接到主服务器上面请求读取二进制日志，然后把读取到的二进制日志写到本地的一个Realy log里面。从服务器上面开启一个SQL thread定时检查Realy log，如果发现有更改立即把更改的内容在本机上面执行一遍。

主从从（master-slave-slave）

 一主多从的话，这时主库既要负责写又要负责为几个从库提供二进制日志。此时可以稍做调整，将二进制日志只给某一从，这一从再开启二进制日志并将自己的二进制日志再发给其它从。或者是干脆这个从不记录只负责将二进制日志转发给其它从，这样架构起来性能可能要好得多，而且数据之间的延时应该也稍微要好一些。

注意

 在老版本的MySQL中，主从复制的slave段并不是由两个进程完成的，而是由一个进程完成的，之后就出现了很多风险和性能的相关问题。具体有以下问题：

一个进程会使复制bin-log日志和解析日志并在自身执行的过程成为一个串行的过程，性能受到了一定的限制，异步复制的延迟也会比较长。

 Slave端从Master端获取bin-log过来之后，需要接着解析日志内容，然后在自身执行。在这个过程中，Master端可能又产生了大量变化并新增了大量的日志。如果在这个阶段Master端的存储出现了无法修复的错误，那么在这个阶段所产生的所有变更都将永远无法找回。如果在Slave端的压力比较大的时候，这个过程的时间可能会比较长。

MySQL主从复制的过程

两种情况：

同步复制
异步复制
生产环境中大多数采用异步复制。

复制的基本过程：

 slave上面的I/O进程连接上master，并请求从指定文件的指定位置（或者从最开始的日志）之后的日志内容。
 
 Master接收到来自Slave的IO进程的请求后，负责复制的IO进程会根据请求信息读取日志指定位置之后的日志信息，返回给Slave的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置。
 
 Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”。
 
 Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。

配置

环境

 centos 6.9
 mysql 5.6
 mysql环境一致
 初始化表

主服务器

 vim /etc/my.conf
 [mysqld]
 log-bin= jinc  //取名随意，启用二进制日志
 server-id= 51   //任意数字，服务器唯一ID，默认为1，我们可以设置为ip后面的数字
 保存退出

创建账户并授权slave

 mysql> grant replication slave on *.* to 'jinc'@'10.0.0.%' identified by '123456';
 --jinc  //用户
 --123456  //密码
 mysql> show master status;
 +-------------+----------+--------------+------------------+-------------------+
 | File        | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
 +-------------+----------+--------------+------------------+-------------------+
 | jinc.000001 |      530 |              |                  |                   |
 +-------------+----------+--------------+------------------+-------------------+
 1 row in set (0.00 sec)

–查询mysql主服务器状态

从服务器配置

 mysql -uroot -p
 mysql> change master to master_host='10.0.0.51',  //mysql 主服务器地址
 mysql> master_user='jinc',  //之前在主上创建的用户名
 mysql> master_password='123456' // 密码
 mysql> master_log_file='jinc.000001',  //主服务器状态中的二进制文件名
 mysql> master_log_pos=530;  //主服务器状态中的position值

启用slave

 mysql> start slave

查看mysql从服务器的状态

 mysql> show slave status；
 下面是一大堆，挑主要的
 Slave_IO_Running: No  --这里必须是yes才是正确的，所以，我这里是有问题的
 Slave_SQL_Running: Yes

问题解决

 看了一下错误日志，也百度了一下，出现这样的原因是因为我的从服务器是由主服务器克隆出来的，所以他们的UUID是一样的，这时我们只要把从服务器上的auto.conf 文件修改一下，在重启就好
 
 mv auto.conf auto.conf.bak
 service mysqld restart

再次回到数据库，执行show slave status\G

 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
 已经正常了

测试

主

 mysql> show databases;
 +--------------------+
 | Database           |
 +--------------------+
 | information_schema |
 | dedecms            |
 | dz                 |
 | mysql              |
 | performance_schema |
 | test               |
 | wordpress          |
 +--------------------+
 7 rows in set (0.08 sec)
 
 mysql> create database slave;
 Query OK, 1 row affected (0.06 sec)

从

 mysql> show databases;
 +--------------------+
 | Database           |
 +--------------------+
 | information_schema |
 | dedecms            |
 | dz                 |
 | mysql              |
 | performance_schema |
 | slave              |
 | test               |
 | wordpress          |
 +--------------------+
 8 rows in set (0.07 sec)