Mysql读写分离

路径配置

数据库的版本5.7版本

• mysql的数据文件和二进制文件： /var/lib/mysql/
• mysql的配置文件： /etc/my.cnf
• mysql的日志文件： /var/log/mysql.log

实际操作

• 配置master

  • 192.168.11.140为master
  • 创建一个用户’repl’,并且允许其他服务器可以通过该用户远程访问master，通过该用户去读取二进制数据，实现数据同步
    (1) Create user repl identified by ‘repl； //repl用户必须具有REPLICATION SLAVE权限，除此之外其他权限都不需要
    (2) GRANT REPLICATION SLAVE ON . TO ‘repl’@’%’ IDENTIFIED BY ‘repl’ ;
  • 修改140 my.cnf配置文件，在[mysqld] 下添加如下配置
    (1) log-bin=mysql-bin //启用二进制日志文件
    (2) server-id=130 服务器唯一ID
  • 重启数据库 systemctl restart mysqld
  • 登录到数据库，通过show master status 查看master的状态信息

• 配置slave

  • 192.168.11.142 为slave
  • 修改142 my.cnf配置文件， 在[mysqld]下增加如下配置
    (1) server-id=132 服务器id，唯一
    (2) relay-log=slave-relay-bin
    (3) relay-log-index=slave-relay-bin.index
    (4) read_only=1
  • 重启数据库： systemctl restart mysqld
  • 连接到数据库客户端，通过如下命令建立同步连接
    (1) change master to master_host=’192.168.11.140’, master_port=3306,master_user=’repl’,master_password=’repl’,master_log_file=’mysql-bin.000001’,master_log_pos=0;
    (2) master_log_file、master_log_pos这两个参数，从master的show master status可以找到对应的值，不能随便写。
  • 执行 start slave
  • show slave status\G; //查看slave服务器状态，当如下两个线程状态为yes，表示主从复制配置成功
    Slave_IO_Running=Yes
    Slave_SQL_Running=Yes

主从同步的原理

• 主库将变更写binlog日志，然后从库连接到主库之后，从库有一个IO线程，将主库的binlog日志拷贝到自己本地，写入一个中继日志中。接着从库中有一个SQL线程会从中继日志读取binlog，然后执行binlog日志中的内容，也就是在自己本地再次执行一遍SQL，这样就可以保证自己跟主库的数据是一样的。

• binlog介绍
  (1) binlog： 用来记录mysql的数据更新或者潜在更新（update xxx where id=x effect row 0）;
  (2) 文件内容存储在：/var/lib/mysql
  (3) mysqlbinlog --base64-output=decode-rows -v mysql-bin.000001 //查看binlog的内容
  (4) binlog的格式:

  • statement ： 基于sql语句的模式。update table set name =””; effect row 1000； uuid、now() other function
  • row： 基于行模式; 存在1000条数据变更； 记录修改以后每一条记录变化的值
  • mixed: 混合模式，由mysql自动判断处理

  (5) 修改binlog_formater,通过在mysql客户端输入如下命令可以修改

  set global binlog_format=’row/mixed/statement’;  或者在vim /etc/my.cnf  的[mysqld]下增加 binlog_format=‘mixed’
  

主从复制丢数据的问题和主从复制延时问题

• 从库为什么会丢数据
  (1) 在这个过程中从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行SQL的特点，在高并发场景下，从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。(网络传输、磁盘的读写耗时、文件通知更新都会造成从库慢于主库)
  (2) 如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了。

• 解决方案
  (1) 半同步复制，用来解决主库数据丢失问题
  semi-sync复制，指的就是主库写入binlog日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的relay log之后，接着会返回一个ack给主库，主库接收到至少一个从库的ack之后才会认为写操作完成了。
  (2) 并行复制，用来解决主从同步延时问题。
  指的是从库开启多个线程，并行读取relay log中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。

• 解决同步延迟问题的系列手段
  可以通过配置一些参数来降低延迟，但不是根本解决主从同步的方法，这个延迟时间一般在写并发在1000的时候延迟时间一般是几毫秒，在2000的时候会有几十毫秒，在4000、6000、8000并发时一般会达到几秒。
  (1) 减少slave同步延迟，可以修改slave库sync_binlog属性；

  • sync_binlog=0 表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。

  • sync_binlog=n 表示每sync_binlog次事务提交，MySQL调用文件系统的刷新操作将缓存刷入硬盘。

  最安全的就是sync_binlog=1了，表示每次事务提交，MySQL都会把binlog刷下去，是最安全但是性能损耗最大的设置。很多MySQL DBA设置的sync_binlog并不是最安全的1，而是100或者是0。这样牺牲一定的一致性，可以获得更高的并发和性能。

  (2) 分库，将一个主库拆分为4个主库，每个主库的写并发就500/s，此时主从延迟可以忽略不计
  (3) 打开“前文讲过的”mysql支持的并行复制，多个库并行复制，如果说某个库的写入并发就是特别高，单库写并发达到了2000/s，并行复制还是没意义。
  (4) 重写代码，写代码的同学，要慎重，插入数据之后，直接就更新，不要查询。如果确实是存在必须先插入，立马要求就查询到，然后立马就要反过来执行一些操作，对这个查询设置直连主库。不推荐这种方法，这么搞导致读写分离的意义就丧失了。
  (5) 增加延时监控
  —> Nagios做网络监控
  —> mk-heartbeat