大家好，我是小鱼。在平时的工作中，我们使用最多的数据库是MySQL。随着业务的增加，如果我们只依赖一台服务器，负载会过大，很容易造成宕机。这样我们保存在MySQL数据库中的数据就会丢失，那么如何解决呢？其实MySQL本身就有主从复制功能，可以帮助我们实现负载均衡和读写分离。对于主服务器（Master），主要负责写，从服务器（Slave）主要负责读。在这种情况下，压力会大大降低，从而提高效率。接下来跟随小鱼看看它有哪些核心知识点：简介随着业务的增长，一台数据服务器已经不能满足需求，负载过重。这时候就需要解压，实现负载均衡，读写分离，一主一集群或者一主多从。主服务器只负责写，从服务器只负责读，提高了效率，减轻了压力。主从复制又可以分为：主从同步：当用户写入数据时，主服务器必须先与从服务器同步，然后才告诉用户写入成功，等待时间比较长。主从异步：只要用户访问写入数据的主服务器，就会立即返回给用户。主从半同步：当用户访问写数据主服务器写入并同步其中一台从服务器，会返回成功给用户。一主一从一主一从一主多从一主多从一主一从一主多从是我们现在看到的最常见的主从架构，使用起来简单有效，不仅可以实现HA，还可以读写分离，从而提高集群的并发能力。多主从多主从可以将多个MySQL数据库备份到一台服务器上，存储性能更好。Dual-masterreplicationDual-masterreplication双主复制，即相互主从复制，每个master既是另一台服务器的master又是slave。这样，任何一方所做的更改都将通过复制应用到另一方的数据库中。CascadeReplicationCascadeReplication在级联复制模式下，部分slave的数据同步不连接到master节点，而是连接到slave节点。因为如果master节点的slave节点太多，会损失一部分复制性能，那么我们可以在master节点上连接3到5个slave节点，其他的slave节点作为secondary或tertiary节点连接到slave节点上，这样不仅可以减轻主节点的压力，而且对数据一致性没有负面影响。原理MySQL主从复制是基于主服务器在二进制日志中跟踪数据库的所有变化。因此，要进行复制，必须在主服务器上启用二进制日志记录。每个从站接收从主站记录的数据。当从服务器连接到主服务器时，它会通知主服务器从哪里读取从服务器日志中的最后一次成功更新。slave接收此后发生的任何更新，并在master上执行相同的更新。然后阻止更新等待来自主服务器的通知。从服务器执行的备份不会干扰主服务器，主服务器可以在备份过程中继续处理更新。Process工作过程MySQL的主从复制工作过程大致如下：从库产生2个线程，1个I/O线程，1个SQL线程；I/O线程请求主库的binlog，并将获取到的binlog日志写入中继日志（relaylog）文件；主库会生成一个logdump线程，将binlog传输给从库I/O线程；SQL线程会读取中继日志文件中的日志，解析成具体的操作，实现主从操作一致，最终数据一致；工作过程请求过程MySQL建立主从请求的详细过程如下：当从服务器连接到主服务器时，主服务器会创建一个logdump线程发送binlog的内容。在读取binlog内容的操作中，master节点上的binlog会被锁定，读取完成后会解锁并发送给从服务器。当在slave节点上执行startslave命令时，slave节点会创建一个IO线程连接master节点，请求master库更新binlog。IO线程收到master节点的binlogdump进程发送过来的update后，保存在relay-log中。从节点SQL线程负责读取realy-log中的内容，解析成具体的操作执行，最终保证主从数据的一致性。该类型异步复制一个主库，一个或多个从库，数据异步同步到从库。在这种异步复制模式下，主节点不会主动向从节点推送数据。主库在执行完客户端提交的事务后会立即返回结果给客户端，并不关心从库是否接收并处理。这样一来，就会出现问题。如果主节点挂了，此时已经在主节点上提交的事务可能无法传输到从节点。数据不全。同步复制是MySQL集群中特有的一种复制方式。当主库执行一个事务时，所有的从库都复制了这个事务并执行成功，然后返回一个成功消息给客户端。因为需要等待所有从库都执行完事务才返回成功信息，所以全同步复制的性能必然会受到严重影响。半同步复制是在异步复制的基础上，保证在主库上的任何事务提交之前，至少有一个从库已经接收并记录了事务。半同步复制介于异步复制和全同步复制之间。主库在执行完客户端提交的事务后并不会立即返回给客户端，而是等待至少有一个从库接收并写入relaylog后才返回成功将信息发送给客户端（只能保证主库的Binlog已经传输到至少一个从节点），否则需要等到超时时间后切换到异步模式再提交。相对于异步复制，半同步复制提高了数据的安全性，一定程度上保证了数据能够成功备份到从库。同时也会造成一定的延迟，但是比全同步模式的延迟要低，是延迟最少的。是一次TCP/IP往返的时间。因此，半同步复制最适用于低延迟网络。MySQL没有内置半同步模式。从MySQL5.5开始集成，需要主从安装插件开启半同步模式。延迟复制是在异步复制的基础上，人为设置主库和从库的数据同步延迟时间，即保证数据延迟至少为这个参数。MethodMySQL主从复制支持两种不同的日志格式，也对应各自的复制方式。当然，也有结合两者的混合复制类型。Statement-basedreplicationStatement-basedreplication相当于逻辑复制，即将操作的语句记录在二进制日志中，通过在从库中重放这些语句来实现复制。这种方法简单，二进制文件小，传输带宽小。但是基于语句的更新依赖于其他因素，例如插入数据时使用时间戳。所以在开发的时候，我们应该尽量把业务逻辑逻辑放在代码层，而不是MySQL，不便于扩展。特点：传输效率高，延迟小。从存储库更新不存在的记录时，语句分配不会失败。另一方面，行复制会导致失败，从而允许及早发现主从之间的不一致。假设表中有一百万条记录，一条sql更新所有表。基于语句的复制只需要发送一条sql，而基于行的复制需要发送一百万条更新记录。Rowdatareplication相当于physicalReplication，即在binarylog中记录每一行实际更新的数据。导致复制压力比较大，日志占用空间大，传输带宽大。但是这种方法比基于语句的复制更精确。特点：无需执行查询计划。我不知道正在执行什么语句。比如一条更新用户总积分的语句，需要统计用户所有的积分，并写入到user表中。如果是基于语句复制，从库需要重新统计用户积分，而基于行复制，不统计用户积分，直接更新记录。混合类型的复制一般情况下，默认使用基于语句的复制。一旦发现statement-basedreplication不能准确复制，就会使用row-basedreplication。configuration配置要点如下：#如果双主复制结构中没有设置ID，会造成循环同步问题提交后，Mysql会执行一个fsync磁盘同步命令。将缓冲区数据刷新到磁盘。#如果为0，则频率由Mysql自己控制。如果sync_binlog=n#为0，则logbuffer每秒写入一次logfile并刷新到磁盘。#mysqld进程崩溃将在一秒钟内丢失所有事务。#如果为1，则每次事务的logbuffer都会被写入logfile并刷新到磁盘。(更安全)#在崩溃的情况下，只会丢失一笔交易。#如果是2，每个事务的logbuffer都会写入logfile，但是会每秒刷新一次到磁盘innodb_flush_logs_at_trx_commit=0#防止从库崩溃后自动复制，给一些时间修复可能出现的问题，#崩溃后可能的自动复制会导致更多问题。并且不一致skip_slave_start=1#是否将从库同步的事件记录到库本身的bin-log中#允许备库在自己的二进制日志中记录重放的事件，备库可以作为另一个主库库的从库log_slave_update#日志过期删除时间，如果延迟严重，日志文件会占磁盘而从库的SQL线程是单线程的，这样从库的SQL可能跟不上主库的处理速度。解决方案：网络方面：尽量保证主从库之间网络稳定，延迟小；硬件方面：从库配置更好的硬件，提高随机写的性能；在配置方面：尽量让MySQL操作在内存中完成，减少磁盘操作。或者升级MySQL5.7版本使用并行复制；在构建方面：事务中尽量读写主库，其他非事务性读从从库读取。消除一些延迟造成的数据库不一致。增加缓存以减少部分从库的负载。数据丢失当主库宕机时，数据可能会丢失。解决方案：使用半同步复制解决数据丢失问题。MySQL需要注意以下几点：MySQL主从复制是MySQL高可用和高性能（负载均衡）的基础；简单、灵活，部署方式多样，可以根据不同的业务场景部署不同的复制结构；在复制过程中应时刻监控复制状态，复制错误或延迟可能影响系统；MySQL主从复制目前存在一些问题，可以根据需要部署复制增强。主从复制的作用带来很多好处。当我们的主服务器出现问题时，我们可以切换到从服务器；我们可以在数据库层面进行读写分离；我们可以在从数据库上执行每日备份。还可以保证：数据更安全：做了数据冗余，不会因为单台服务器宕机而丢失数据；性能大幅提升：一主多从，不同用户读取不同数据库，性能提升；可扩展性更强优点：当流量增加时，可以方便的添加从服务器，不影响系统使用；负载均衡：一主多从相当于分担主机任务，做负载均衡。应用场景MySQL主从复制集群功能使得MySQL数据库支持大规模、高并发读写成为可能，同时在物理服务器宕机时有效保护数据备份。水平扩展将工作负载分散到各个Slave节点，从而提高系统性能。在这个场景下，所有的写入和更新操作都在Master节点上完成；所有读取操作都在Slave节点上完成。通过增加更多的Slave节点，可以提高系统的读取速度。数据安全数据从Master节点复制到Slave节点，复制过程可以在Slave节点上挂起。可以将Master节点对应的数据备份到Slave节点上，不影响Master节点的运行。数据分析Master节点上可以创建实时数据，Slave节点上可以对这些数据进行分析，不影响Master节点的性能。远程数据分发可以使用复制在远程主机上创建本地数据的副本，而无需与Master节点建立持久连接。拆分接入可以根据公司的业务拆分出若干个不同的从服务器。拆分可以帮助减轻主服务器的压力，也可以让数据库独立于外部用户浏览、内部用户业务处理、DBA备份。
