mysql系列(七)mysql 主从复制和mysql查询优化

1. 什么是MySQL主从复制

MySQL数据库自身提供的主从复制功能可以方便的实现数据的多处自动备份，实现数据库的拓展。多个数据备份不仅可以加强数据的安全性，通过实现读写分离还能进一步提升数据库的负载性能。

2. mysql 的不同复制类型

2.1异步复制

MySQL复制默认是异步复制，Master将事件写入binlog，提交事务，自身并不知道slave是否接收是否处理；这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

缺点：不能保证所有事务都被所有slave接收。

2.2 同步复制

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端，也就是说Master提交事务，直到事务在所有slave都已提交，才会返回客户端事务执行完毕信息；

缺点：需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

2.3 半同步复制（半同步复制在5.5后才支持）

当Master上开启半同步复制功能时，至少有一个slave开启其功能。当Master向slave提交事务，且事务已写入relay-log中并刷新到磁盘上，slave才会告知Master已收到；若Master提交事务受到阻塞，出现等待超时，在一定时间内Master 没被告知已收到，此时Master自动转换为异步复制机制。

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。

缺点：

此时，客户端会收到事务提交失败的信息，客户端会重新提交该事务到新的主上，当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中，会发现，该事务在从库中被提交了两次，一次是之前作为主的时候，一次是被新主同步过来的。
此时，从库已经收到并应用了该事务，但是客户端仍然会收到事务提交失败的信息，重新提交该事务到新的主上。

3. 配置主从复制（异步复制）

1.Master将改变记录到二进制日志(binary log)中（需开启bin log）

2. Slave将Master的binary log events拷贝（通过IO线程）到它的中继日志(relay log)

3. Slave重做中继日志中的事件，将改变反映它自己的数据

3.1 配置主服务器

1：修改 mysql的配置文件 my.conf（yum安装在 /etc/my.conf）

server_id MySQL集群唯一编号（唯一标识）

log_bin 二进制日志（bingary log）的选项。指定文件名。

2：重启mysql服务器
systemctl restart mysql
或者下方命令根据自己的服务来重启
systemctl restart mysqld

3：主机上（master）上建立同步复制的用户并赋权（IP可以使用%表示范围，）

create user 'repl'@'slave主机IP' identified by '123456';

grant replication slave on *.* to 'repl'@'slave主机IP' identified by '123456';

3.2 配置slave服务器，从机上（slave）上建立和主机同步连接

如果主服务器已经有数据需要先手动的把数据导入到从服务器---方式很多自行，dump

#如果作为slave启动过
stop slave;
#执行作为从服务器得命令
#master_host='10.10.10.1' 主服务器的IP
#master_user='repl' 指定在主服务器给的同步的用户名
#MASTER_PASSWORD='123456'  指定用户对应的密码
#MASTER_LOG_FILE='mysql-bin.000001' 指定主服务器的bin日志名
#MASTER_LOG_POS=1818 bin日志起始位置  可以在主服务器使用show master status;查看

change master to master_host='主ip', master_user='repl',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=1818;

#开始命令

start slave;

执行完毕后：

#使用 show slave status \G  查看从服务器的状态

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event (代表等待主服务器的同步)
                  Master_Host: ###########         (主服务器的IP)
                  Master_User: repl                (同步使用的用户名)
                  Master_Port: 3306                (主服务器的端口) 
                Connect_Retry: 60                  (失败重连间隔) 
              Master_Log_File: mysql-bin.000001    (主服务器的bin log日志名称) 
          Read_Master_Log_Pos: 1818                (读取bin log起始偏移量)
               Relay_Log_File: iZ2zehf3z0yo0vu7y8zj9hZ-relay-bin.000002
                Relay_Log_Pos: 320
        Relay_Master_Log_File: mysql-bin.000001
             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: 1818
              Relay_Log_Space: 545
              Until_Condition: None

使用：show binlog events in 'mysql-bin.000001' from 0; 查看bin-log日志

4.查询缓存(mysql5.8已取消)

很多数据库产品都能够缓存查询的执行计划，对于相同类型的SQL就可以跳过SQL解析和执行计划生成阶段。但是MySQL还有另一种不同的缓存类型：缓存完整的SELECT查询结果，也就是“查询缓存”(在缓存中)。 MySQL查询缓存保存查询返回的完整结果。当查询命中该缓存，MySQL会立刻返回结果，跳过了解析、优化和执行阶段(还没到存储引擎)。查询缓存系统会跟踪查询中涉及的每个表，如果这些表发生变化，那么和这个表相关的所有的缓存数据都将失效。

如何判断缓存命中？

MySQL判断缓存命中的方法很简单：缓存存放在一个引用表中，通过一个哈希值引用，这个哈希值包括了查询SQL本身、当前要查询的数据库、客户端协议的版本等一些其他可能会影响返回结果的信息。当判断缓存是否命中时，MySQL不会解析查询语句，而是直接使用SQL语句和客户端发送过来的其他原始信息。任何字符上的不同，例如空格、注释，都会导致缓存的不命中。当查询语句中有一些不确定的数据时，则不会被缓存。例如包含函数NOW()或者CURRENT_DATE()的查询不会被缓存。事实上，如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql 库中的系统表，或者任何包含列级别权限的表，都不会被缓存。