MySQL的主从复制
👨💻个人主页： 才疏学浅的木子 🙇♂️ 本人也在学习阶段如若发现问题，请告知非常感谢 🙇♂️ 📒 本文来自专栏： MySQL 🌈 每日一语：人的一生，好不好只有自己知道，乐不乐只有自己明白。 🌈
本文目录
主从复制流程
MySQL主从复制是基于主服务器在二进制日志跟踪所有对数据库的更改。因此要进行复制，必须在主服务器上启用二进制日志。 每个从服务器从主服务器接收已经记录到日志的数据，当从服务器连接到主服务器时，它通知主服务器从服务器日志中读取最后一个更新成功的位置 从服务器接收从那时起的任何更新，并在主机上执行相同的更新，然后封锁等待主服务器通知的更新 从服务器执行备份不会干扰主服务器，在备份过程中主服务器可以继续处理更新
过程
从库有两个线程，一个I/O线程，一个SQL线程 I/O线程去请求主库的binlog，并将binlog写到relay log(中继日志)文件中 主库会生成一个log dump线程用来给从库I/O线程传binlog SQL线程会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致
主从复制的类型
异步复制
这种模式下，主节点不会主动推送数据到从节点，主库在执行完客户端提交的事务后会立即将结果返回给客户端，并不关心从库是否接收并处理 这样就会有一个问题，主节点如果崩溃掉，此时主节点已经提交的事务可能并没有传到从节点上，如果此时，强行将从提升为主，可能导致新主节点上的数据不完整
同步复制
在主库执行完一个事务，然后所有的从库都复制了该事务并成功执行完后才返回成功信息给客户端 因为需要等待所有从库执行完该事务才能返回成功信息，所以同步复制的性能必然会收到影响
半同步复制
介于全同步复制与异步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收并写到relay log中才返回信息给客户端，否则需要等待直到超时然后切换成异步模式再提交
主从复制内容方式
主从复制基于两种不同的日志格式，这两种日志格式也对应了各自的复制方式。当然也有二者相结合的混合类型复制
语句复制
基于语句的复制相当于逻辑复制，即二进制日志中记录了操作的语句，通过这些语句在从数据库中重放来实现了复制 这种方式简单，二进制文件小，传输带宽占用小。但是基于语句更新依赖于其它因素，比如插入数据时利用了时间戳。 数据小的原因举例：更新100w条数据只需要一条SQL，而如果记录行数据就需要记录100w行 因此在开发当中，我们应尽量将业务逻辑放在代码层，而不应该在MySQL
行数据复制
基于行的复制相当于物理复制，即二进制日志记录的实际更新数据的每一行 这样会导致复制的压力比较大，日志占用的空间大，传输带宽占用大 不需要执行查询计划
混合类型的复制
一般情况下，默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用行的复制
主从复制的优点
1、数据更安全：做了数据冗余，不会因为单台服务器的宕机 2、性能提升：一主多从，不同用户从不同数据库读取 3、扩展性更优：流量增大时，可以方便的增加从服务器，不影响系统使用 4、负载均衡：一主多从相当于分担了主机任务，做了负载均衡
腾讯云开发者
