共计 4391 个字符，预计需要花费 11 分钟才能阅读完成。
今天就跟大家聊聊有关 MySQL 中主从复制的原理分析，可能很多人都不太了解，为了让大家更加了解，丸趣 TV 小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
1.1.1 MySQL 主从复制介绍
MySQL 数据库支持单向、双向、链式级联、环状等不同业务场景的复制。在复制过程中，一台服务器充当主服务器（Master），接收来自用户的内容更新，而一个或多个其他的服务器充当从服务器（Slave），接收来自主服务器 binlog 文件的日志内容，解析出 SQL 重新更新到从服务器，使得主从服务器数据达到一致。
如果设置了链式级联复制，那么，从（slave）服务器本身除了充当从服务器外，也会同时充当其下面从服务器的主服务器。链式级复制类似 A rarr;B rarr;C 的复制形式。
1.1.2 MySQL 主从复制的企业应用场景
MySQL 主从复制集群功能使得 MySQL 数据库支持大规模高并发读写称为可能，同时有效地保护了物理服务器宕机场景的数据备份。
应用场景 1：从服务器作为主服务器的实时数据备份
主从服务器架构的设置，可以大大加强 MySQL 数据库架构的健壮性。例如：当主服务器出现问题时，我们可以人工或设置自动切换到从服务器继续提供服务，此时从服务器的数据和宕机时的主数据库几乎是一致的。
这类似 NFS 存储数据通过 inotify+rsync 同步到备份的 NFS 服务器，只不过 MySQL 的复制方案是其自带的工具。
利用 MySQL 的复制功能做备份时，在硬件故障、软件故障的场景下，该数据备份是有效的，但对于人为地执行 drop、delete 等语句删除数据的情况，从库的备份功能就没有用了，因为从服务器也会执行删除的语句。
应用场景 2：主从服务器实时读写分离，从服务器实现负载均衡
主从服务器架构可通过程序（PHP、Java 等）或代理软件（mysql-proxy、Amoeba）实现对用户（客户端）的请求读写分离，即让从服务器仅仅处理用户的 select 查询请求，降低用户查询响应时间及读写同时在主服务器上带来的访问压力。对于更新的数据（例如 update、insert、delete 语句）仍然交给主服务器处理，确保主服务器和从服务器保持实时同步。
应用场景 3：把多个从服务器根据业务重要性进行拆分访问
可以把几个不同的从服务器，根据公司的业务进行拆分。例如：有为外部用户提供查询服务的从服务器，有内部 DBA 用来数据备份的从服务器，还有为公司内部人员提供访问的后台、脚本、日志分析及供开发人员查询使用的从服务器。这样的拆分除了减轻主服务器的压力外，还可以使数据库对外部用户浏览、内部用户业务处理及 DBA 人员的备份等互不影响。具体可以用下图说明：
2.1 实现 MySQL 主从读写分离的方案
（1）通过程序实现读写分离（性能和效率 ***，推荐）
PHP 和 Java 程序都可以通过设置多个连接文件轻松地实现对数据库的读写分离，即当语句关键字为 select 时，就去连接读库的连接文件，若为 update、insert、delete 时，则连接写库的连接文件。
通过程序实现读写分离的缺点就是需要开发人员对程序进行改造，使其对下层透明，但这种方式更容易开发和实现，适合互联网业务场景。
（2）通过开源软件实现读写分离
MySQL-proxy、Amoda、Mycat、Altas 等代理软件也可以实现读写分离功能，这些软件的稳定性和功能一般，不建议生产使用。绝大多数公司常用的还是应用端开发程序实现读写分离。
（3）大型门户独立开发 DAL 层综合软件
百度、阿里等大型门户都有开发牛人，会花大力气开发适合自己业务的读写分离、负载均衡、监控报警、自动扩容，自动收缩等一系列功能的 DAL 层软件。
3.1 MySQL 主从复制原理介绍
MySQL 的主从复制是一个异步的复制过程（虽然一般情况下感觉是实时的），数据将将从一个 MySQL 数据库（我们称之为 Master）复制到另一个 MySQL 数据库（我们称之为 Slave），在 Master 于 Slave 之间实现整个主从复制的过程是由三个线程参与完成的。其中有两个线程（SQL 和 IO 线程）在 Slave 端，另外一个线程（I/ O 线程）在 Master 端。
要实现 MySQL 的主从复制，首先必须打开 Master 端的 Binlog 记录功能，否则就无法实现。因为整个复制过程实际上就是 Slave 从 Master 端获取 BInlog 日志，然后再在 Slave 上以相同顺序执行获取的 binlog 日志中记录的各种 SQL 操作。
要打开 MySQL 的 BInlog 记录功能，可通过在 MySQL 的配置文件 my.cnf 中的 mysqld 模块增加“log-bin”参数选项来实现，具体信息如下：
[mysqld] log-bin3.2 MySQL 主从复制原理过程详细描述
下面简单描述下 MySQL Replication 的复制原理过程。
1）在 Slave 服务器上执行 start slave 命令开启主从复制开关，主从复制开始进行。
2）此时，Slave 服务器的 I / O 线程会通过在 Master 上己经授权的复制用户权限请求连接 Master 服务器，并请求从指定 Binlog 日志文件的指定位罝（日志文件名和位置就是在配罝主从复制服务时执行 change master 命令指定的）之后开始发送 Binlog 日志内容。
3）Master 服务器接收到来自 Slave 服务器的 I / O 线程的请求后，其上负责复制的 I / O 线程会根据 Slave 服务器的 I / O 线程请求的信息分批读取指定 Binlog 日志文件指定位置之后的 Binlog 日志信息，然后返回给 Slave 端的 I / O 线程。返回的信息中除了 Binlog 日志内容外，还有在 Master 服务器端记录的新的 Binlog 文件名称以及在新的 Binlog 中的下一个 指定更新位置。
4）当 Slave 服务器的 I / O 线程获取到 Master 服务器上 I / O 线程发送的日志内容及日志文件及位置点后，会将 Binlog 日志内容依次写入到 Slave 端自身的 Relay Log（即中继日志） 文件 (MySQL-relay-bin.xxxxxx) 的最末端，并将新的 Binlog 文件名和位置记录到 master-info 文件中，以便下一次读取 Master 端新 Binlog 日志时能够告诉 Master 服务器需要从新 Binlog 日志的指定文件及位置开始请求新的 Binlog 日志内容。
5）Slave 服务器端的 SQL 线程会实时地检测本地 Relay Log 中 I / O 线程新增加的日志内容，然后及时地把 Relay Log 文件中的内容解析成 SQL 语句，并在自身 Slave 服务器上按解析 SQL 语句的位置顺序执行应用这些 SQL 语句，并记录当前应用中继日志的文件名及位置点在 relay-log.info 中。
经过了上面的过程，就可以确保在 Master 端和 Slave 端执行了同样的 SQL 语句。当复制状态正常的情况下，Master 端和 Slave 端的数据是完全一样的。当然，MySQL 的复制机制也有一些特殊情况，具体请参考官方的说明，大多数情况下，大家不用担心。
下面针对 MySQL 主从复制原理的重点小结
主从复制是异步的逻辑的 SQL 语句级的复制
复制时，主库有一个 I / O 线程，从库有两个线程，I/ O 和 SQL 线程。
作为复制的所有 MySQL 节点的 server-id 都不能相同。
binlog 文件只记录对数据库有更改的 SQL 语句（来自数据库内容的变更），不记录任何查询（select，slow）语句。
5.6 SQL 多线程写入
GTID（不用找位置点了）
3.3 主从复制实践
1、准备
主库 log_bin
主从 server-id 不同
2、主库准备
mysql -S /data/3306/mysql.sock grant replication slave on *.* to rep @ 172.16.1.% identified by oldboy123 flush privileges;3、把数据从主库搞到从库。
复制前 让从和主一致。
mysql -S /data/3306/mysql.sock mysql flush table with read lock; 不能关窗口 mysql show master status; +-------------------+----------+ | File | Position | +-------------------+----------+ | oldboy-bin.000002 | 405 |单开窗口
mysqldump -A -B --master-data=2 -S /data/3306/mysql.sock|gzip /opt/3306.sql.gz原窗口
mysql unlock table;从库恢复：
gzip -d /opt/3306.sql.gz mysql -uroot -poldboy123 -S /data/3307/mysql.sock /opt/3306.sql5、指定主机、用户、位置点同步
mysql CHANGE MASTER TO MASTER_HOST= 172.16.1.51 , MASTER_PORT=3306, MASTER_USER= rep , MASTER_PASSWORD= oldboy123 , MASTER_LOG_FILE= mysql-bin.000001 , MASTER_LOG_POS=405; #查看 MASTER_LOG_FILE 使用 sed -n 22p /opt/3306.sql#查看主库 # 从库6、开启同步开关，检查是否同步。
mysql start slave; mysql show slave statusG Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 0从库配置信息说明
mysql CHANGE MASTER TO MASTER_HOST= 172.16.1.51 , #这里是主库的 ip MASTER_PORT=3306, # 这里是主库的端口，从库的端口可以和主库不同 MASTER_USER= rep , # 这里是主库上建立的用于复制的用户 rpo MASTER_PASSWORD= oldboy123 , ## 这里是 rep 用户的密码 MASTER_LOG_FILE= mysql-bin.000001 , ###这里是 show master status 时查看到的二进制日志文件名称，注意不能多空格 MASTER_LOG_POS=405; ## 这里是 show master status 时查看到的二进制日志文件偏移量，注意不能多空格看完上述内容，你们对 MySQL 中主从复制的原理分析有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注丸趣 TV 行业资讯频道，感谢大家的支持。
