MySQL主从复制原理简介

MySQL主从复制原理详解：
一、mysql主从复制介绍
(1)mysql支持单双向、链式级联、异步复制。在复制过程中一个充当主服务器(Master),一个或多个充当从服务器(Slave)。在复制过程中一个充当主服务器

(2)如果设置了链式级联复制，那么，从服务器(Slave)本身除了充当从服务器外，也会同时充当其下面服务器的主服务器。
链式级联复制类似A---}B---}C---}D---}E---}F的复制形式、

(3)当配置好主从复制后，所有对数据库内容的更新就必须在主服务器上进行，以避免用户对主服务器上数据内容的更新
与对从服务器上数据库内容的更新之间发生冲突。生产环境中一般会，忽略授权表同步，然后对从服务器上的用户授权select读权限；
或者在my.cnf配置文件中加read-only参数来确保从库只读，当然二者同时操作效果更佳。
mysql主从复制有利于数据库健壮性，访问速度和系统维护管理等特性。

1.主从服务器架构的设置，可以大大的加强数据库架构的健壮性。当主服务器出现故障时，我们可以切换到从服务器继续提供服务。

2.主从服务器架构可以实现对用户请求实现读写分离，即通过在从服务器上处理用户select查询请求；
降低查询响应时间，及读写给主服务器带来的压力。对于数据更新(update,insert,delete等)任然交给主服务器处理，确保主服务器和从服务器保持实时同步。

如果网站已非更新业务为主，如blog，www首页展示等业务。一般读多写少，这台服务器的负载均衡策略效果就很明显。这就是传说中的读写分离架构。

3.可以把几个不同的从服务器，根据公司的业务进行拆分。有为外部用户提供查询服务的从服务器，有专门用来备份的从服务器。
还有提供公司内部后台，脚本，日志分析及开发人员服务的从服务器。这样就减轻了主服务器的压力，使得对外用户浏览；
对内处理公司内部用户业务，及DBA备份业务互补影响，
具体可用下面架构来说明：

MySQL---}S1----}对外部用户提供服务(浏览帖子、浏览博客
---}S2----}对外部用户提供服务(浏览帖子、浏览博客)
---}S3----}对外部用户提供服务(浏览帖子、浏览博客)
---}S4----}对内部用户提供服务(后台访问、脚本任务、数据分析、开发人员浏览)
---}S5----}数据库备份服务务(开启从服务器的binlog功能、可以实现增量分别及恢复)。

二、生产场景Mysql主从复制常用基本架构：

Replication--复制架构图

MySQL Master MySQL Slave1 MySQL Slave2 MySQL Slave3 MySQL Slave4

write read read read read

Web-Client Web-Client Web-Client Web-Client

Load Balancer(调度器-负载均衡)

Clients
(1)MySQL主从复制原理介绍
MySQL的主从复制是一个异步复制过程(但是看起来也是实时的)，数据库数据从一个MySQL数据库(我们称之为Master)
复制到另一个MySQL数据库(我们称之为Slave)。在Master与Slave之间实现整个主从复制的过程有三个线程参与完成。
其中两个线程(SQL线程和IO线程)在Slave端，另外一个线程(IO线程)在Master端。

要实现MySQL的主从复制，首先必须打开Master端的Binlog(MySQL-bin.xxxxxxx)功能，否则无法实现主从复制。因为
整个复制过程实际上就是Slave从Master端获取Binlog日志，然后再在Slave自身上以相同顺序执行binlog日志中所记录
的各种操作；打开MySQL的Binlog可以通过在MySQL的配置文件my.cnf中的mysqld模块[mysqld]后面增加“log-bin”参数项。

(2)MySQL 主从复制过程描述：
下面简单描述下MySQL Replication的复制过程
1.Slave 服务器上执行start slave，开启主从复制开关。

2.此时，Slave服务器的IO线程会通过在Master上授权的复制用户请求连接Master服务器，并请求知道Bin-log日志文件的指定位置；
（日志文件和位置是在配置主从服务器时change master时指定的）之后的binlog日志内容；

3.Master 服务器接收来自Slave服务器的IO线程的请求后，Master服务器上负责复制的IO线程根据Slave上的IO线程
请求的信息读取指定Binlog日志文件指定位置之后的binlog日志信息；然后返给Slave端的IO线程，返回的信息中
除了日志内容外，还有本次返回的日志内容后在Master服务器端的 新的binlog日志文件名称已经在binlog中的指定位置。

4.当Slave服务器的IO线程获取到来自Master服务器上IO线程发送日志内容及日志文件及位置点后，然后将binlog日志内容
依次写入到Slave端自身的Relay LOG（即中继日志）文件（MySQL-relay-bin.xxxxxxx）的最末端，并将新的binlog文件和位置
记录到master-info文件中，以便下一次读取Master端新binlog日志时能够及时告诉Master服务器需要从新的
binlog日志的哪个文件哪个位置开始请求新的binlog日志内容。

5.Slave服务器的SQL线程会实时的检测本地的Relay Log 中新增加的日志内容，然后及时把LOG文件中的内容解析成在
Master端曾经执行的SQL语句的内容，并在自身Slave服务器上按语句的顺序执行应用这些SQL语句。

6.经过了上面的过程，就可以确保在Master端和Slave端执行了同样的SQL语句。当复制状态正常的请求下，Master端和Slave端的数据是否完全一样。

三、MySQL 主从数据复制结构图集

(1)主从复制基本结构图 1

MySQL(Master) MySQL(Master)
IO/Thread IO/Thread SQL Thread
1 1 2
3 4 4
DateFile BinLog master-info Relay-Log DataFile

图2。。。。。。图5

本文出自 “山猫” 博客，转载请与作者联系！