Day.11 搞懂主从架构- 主从复制(Master Slave Replication)

在前一篇我们提到binlog可以当作资料恢复的重要纪录，今天要介绍的是binlog另一个主要功能用於MYSQL主从复制(Master-Slave Replication)。

What is 主从复制？

Ans: 藉由主从复制将数据从主库(Master)复制到1至多台从服务器(Slave)，达到主从数据一致，增加数据可用性。

因为资料是一致的所以相当於多一个备用系统能在发生单点故障问题时或实务应用查询资料上使用。

实务应用

• 生产环境下的效能:

采数据读写分离，所有写入更新异动操作皆由主库(Master)执行，而读取相关的捞资料语法转至从库(Slave)执行。

解决目的:
不但能分散单点在大量负载请求下的压力，也能避免部分长时间语法造成表锁导致无法正常使用服务的问题。

• 扩展性&系统异常处理:

在一主多从的架构下可以增加服务数据可用性，且当主从服务器有任一台发生异常时，可以透过切换节点，直接取代掉有问题的那台上线运作。

针对以上图例子来说，看例子好理解～ ps.遇到紧急无法及时处理的状况

1. master 主服务有问题 --处理--> 将其中一台slave转master

   (可能要注意一些只在master上的参数记得做切换)

2. slave 从服务有问题 --处理--> 将备援slave转正式slave，保持系统可用性。

• 资料备份：

在从库上实施日常例行备份，同时也能避免在备份时可能造成的效能影响及空间上占用，减少影响主库的因素！

流程图

搭建主从架构前先从以下图了解主从复制在流程上是如何运作!!

首先对於每个 Master-Slave 连接来说都会启用3个线程来完成主从复制的动作。

• Master -> (binlog dump thread) 日志: binlog
• Slave -> (I/O thread & SQL thread) 日志: relay log(中继日志)

1. master- 产生binlog纪录

   • 在master开启binlog下，当client端写入更新资料，在该次事务完成之前，会以事件形式将该次异动写入binlog日志。

2. slave- I/O thread作用

   • 当slave建立用户端启动I/O thread连接master後，master会为当前连接建一个binlog dump thread 用来读取发送binlog内容。

   • I/O thread 通过请求主库的binlog dump thread读取指定binlog文件内的指定位置之後的事件，将内容(除了日志讯息还会包含本次返回的binlog文件&位置纪录)回给slave的I/O thread。

   • 当I/O thread 获取到binlog的更新内容後，会将其写入中继日志，另外会将该次读取到的binlog文件位置记录到master.info文件中。 (ps. relay log 和 master.info文件皆位於slave的mysql目录下。)

3. Slave- SQL thread作用

   • slave的 SQL thread 会检测中继日志读取新增的事件内容，解析事件内容执行重放更新slave的资料，使slave与master中的数据一致。

Q: 为何还要分I/O & SQL thread 存取relay log 而不选择一条龙流程做好更新？

Ans: 将2个线程分成独立工作，I/O(获取更新内容)＆SQL(执行更新内容)。

这样就能避免掉互相等待的状况，像是slave执行更新完成才能送下一个新的事件内容。

今天我们了解主从机制流程上的运行後，明天来实际搭建一个主从架构～