MySQL主从复制&读写分离

概述

MySQL主从复制和读写分离是一些常用的数据库优化和高可用性方案。让我简单解释一下这两个概念：

1. 主从复制（Master-Slave Replication）：主从复制是一种数据库复制技术，通过该技术可以将一个MySQL数据库服务器（称为主服务器）上的数据同步到其他一个或多个MySQL数据库服务器（称为从服务器）上。主从复制的工作原理是主服务器将自己的更新操作记录在二进制日志中，然后从服务器连接到主服务器，获取这些更新操作并在自己的数据库上执行，从而保持数据的一致性。主从复制可以用于实现数据备份、读写分离、负载均衡等场景，提高数据库的可用性和性能。
2. 读写分离（Read/Write Splitting）：读写分离是指将对数据库的读操作和写操作分发到不同的数据库服务器上。通常情况下，写操作会发送到主数据库服务器，而读操作则会发送到从数据库服务器。这样做的目的是减轻主数据库服务器的负担，提高整个系统的并发处理能力和读取性能。读写分离通常与主从复制结合使用，通过主从复制实现数据的同步，然后通过读写分离实现对不同数据库服务器的负载均衡。
   总的来说，MySQL主从复制和读写分离是一些常见的数据库优化和高可用性方案，可以提高数据库的性能、可靠性和扩展性。这些技术在高负载、大流量的应用场景中特别有用，帮助提升系统的稳定性和性能。

MySQL 主从复制主要用途

MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表
1.读写分离
在开发工作中，有时候会遇见某个sql 语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。
2. 数据实时备份，当系统中某个节点发生故障时，可以方便的故障切换
3… 高可用HA
4. 架构扩展
随着系统中业务访问量的增大，如果是单机部署数据库，就会导致I/O访问频率过高。有了主从复制，增加多个数据存储节点，将负载分布在多个从节点上，降低单机磁盘，I/O访问的频率，提高单个机器的I/O性能。

MySQL 主从形式

一主一从，一主多从，提高系统的读性能。一主一从和一主多从是最常见的主从架构实施起来简单并且有效，不仅可以实现HA，而且还能读写分离，进而提升集群的并发能力。多主一从 （从5.7开始支持）多主一从可以将多个mysql数据库备份到一台存储性能比较好的服务器上。
双主复制，也就是互做主从复制，每个master既是master，又是另外一台服务器的slave。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。级联复制。级联复制模式下，部分slave的数据同步不连接主节点，而是连接从节点。
因为如果主节点有太多的从节点，就会损耗一部分性能用复制，那么我们可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。

MySQL 主从复制原理

MySQL主从复制涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在从节点。
主节点 binary log dump 线程
当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。
在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放。
从节点I/O线程
当从节点上执行start slave命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。
从节点SQL线程SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。
复制的基本过程如下：
从节点上的I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
主节点接收到来自从节点的I/O请求后，通过负责复制的I/O进程根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的bin-log file 的以及bin-log position；从节点的I/O进程接收到内容后，将接收到的日志内容更新到本机的relay log中，并将读取到的binary
log文件名和位置保存到master-info 文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”；
Slave 的 SQL线程检测到relay-log 中新增加了内容后，会将relay-log的内容解析成在祝节点上实际执行过的操作，并在本数据库中执行。

MySQL主从复制的原理
● 主库将数据库中数据的变化写入到 binlog从库连接主库。
● 从库会创建一个I/O线程向主库请求更新的 binlog
● 主库会创建一个 binlog dump 线程来发送 binlog ，从库中的 I/O 线程负责接收
● 从库的 I/O 线程将接收的 binlog 写入到 relay log 中
● 从库的 SQL 线程读取 relay log 同步数据本地（也就是再执行一遍 SQL ）
4. 读写分离具体怎么实施
常用组件有下面2个：
● Sharding-JDBC：定位为轻量级Java框架，在Java的JDBC层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。
● MyCat：实现了MySQL协议的服务器，前端用户可以把它看作是一个数据库代理，用MySQL客户端工具和命令行访问，而其后端可以用MySQL原生协议与多个MySQL服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信，其核心功能是分库分表，配合数据库的主从模式还可实现读写分离。

mysql读写分离：

在实际的应用中，绝大部分情况都是读远大于写。Mysql提供了读写分离的机制，所有的写操作都必须对应到Master，读操作可以在Master和Slave机器上进行，Slave与Master的结构完全一样，一个Master可以有多个Slave,甚至Slave下还可以挂Slave,通过此方式可以有效的提高DB集群的每秒查询率.
所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
此外，可以看出Master是集群的瓶颈，当写操作过多，会严重影响到Master的稳定性，如果Master挂掉，整个集群都将不能正常工作。
所以，1. 当读压力很大的时候，可以考虑添加Slave机器的分式解决，但是当Slave机器达到一定的数量就得考虑分库了。 2. 当写压力很大的时候，就必须得进行分库操作。

数据库读写分离的目的是什么

通常业务系统是读多写少，读写分离是将对数据库的读写操作分散到不同的节点上，能够小幅提升写性能，大幅提升读性能。通常采用数据库一主多从的方式，主库可以读写，从库只读。
读写分离会带来什么问题
主库和从库的数据存在延迟。比如写完主库之后，主库的数据同步到从库是需要时间的，这个时间差就导致了主库和从库的数据不一致性问题。解决办法是在不能忍受延迟的场景强制读主库

主从同步延迟的原因

主从延迟：
a. 主库的从库太多
b. 从库硬件配置比主库差
c. 慢 SQL 语句过多
d. 主从库之间的网络延迟
e. 主库读写压力大
一个服务器开放Ｎ个链接给客户端来连接的，这样有会有大并发的更新操作, 但是从服务器的里面读取 binlog 的线程仅有一个，当某个 SQL 在从服务器上执行的时间稍长 或者由于某个 SQL 要进行锁表就会导致，主服务器的 SQL 大量积压，未被同步到从服务器里。这就导致了主从不一致， 也就是主从延迟。

MySQL的主从复制实现读写分离的主从延迟怎么解决

主从同步延迟的解决办法
主服务器要负责更新操作，对安全性的要求比从服务器要高，所以有些设置参数可以修改，
比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置等。
选择更好的硬件设备作为 slave。
把一台从服务器当度作为备份使用， 而不提供查询， 那边他的负载下来了， 执行
relay log 里面的 SQL 效率自然就高了。
增加从服务器喽，这个目的还是分散读的压力，从而降低服务器负载。
解决办法是在不能忍受延迟的场景强制读主库