|
值得注意的是，如果有n个从库，那么主库上就会有n个binlog dump线程。如果这个n比较大的话在复制的时候可能会造成主库的性能抖动。所以在从库较多的情况下可以采用级联复制。
2.2 级联复制
级联复制用大白话说就是套娃。
本来从库B、C、D、E、F、G都是复制的主库A，但是现在由于A的压力比较大，就不这么干了，调整成了如下的模式。
B、C复制A
D、E复制B
F、G复制C
阻塞信道就跟你在柜台一样，你要递归柜员一个东西，但是你和柜员之间没有可以放东西的地方，你就只能一直把文件拿着，直到柜员接手;而非阻塞信道就像你们之间有个地方可以放文件，你就直接放上去就好了，不用等柜员接手。
引入了Relay Log之后，让原本同步的获取事件、重放事件解耦了，两个步骤可以异步的进行，Relay Log充当了缓冲区的作用。Relay Log有一个relay-log.info的文件，用于记录当前复制的进度，下一个事件从什么Pos开始写入，该文件由SQL线程负责更新。
1.5 Relay Log核心参数
接下来让我们了解一下Relay Log的核心参数。
-
max_relay_log_size 中继日志的最大size，默认值0，如果为0就会取默认的size 1G，否则就为设置的值
-
relay_log 定义relay的名称，默认为主机名+relay-bin，例如像hostname-relay-bin
-
relay_log_basename 中继日志的全路径，即路径 + 文件名，例如/path/to/hostname-relay-bin，最大长度为256
-
relay_log_index 定义中继日志的索引文件的全路径，同样其最大的长度为256. 其默认值为hostname + relay-bin.index，例如/path/to/hostname-relay-bin.index
-
relay_log_info_file 定义relay-log.info文件的名称
-
relay_log_info_repository 存放relay log重放的数据的方式，可以设置为FILE和TABLE。FILE代表将中继日志重放的数据记录在relay-info.log中，TABLE则将其存放在slave_relay_log_info这张表里。
-
relay_log_purge 是否自动清空不需要的中继日志，默认值为ON
-
relay_log_recovery 当从库宕机后，如果relay log损坏了导致部分的中继日志没有进行同步，则自动放弃所有未进行重放的中继日志，并从主库重新获取，默认值为OFF
-
relay_log_space_limit 设置中继日志的最大值，防止写满磁盘。但是不建议设置这个值，建议还是给中继日志需要的空间，0就是不限制，0也是默认值
-
sync_relay_log 用于控制中继日志写入磁盘的变量，假设值为n，那么在中继日志每接受n次binlog事件之后就会调用fdatasync()函数将中继日志强制的刷入磁盘;相反，如果值为0，则写入OS的缓冲区内，由OS调度决定何时将中继日志刷入磁盘，这样一来如果在没有刷入之前报错了，那么中继日志就会丢失。默认值是10000，也就是每向中继日志中写入1w次binlog事件就将中继日志强制的刷入磁盘。
-
sync_relay_log_info 该参数的影响跟参数relay_log_info_repository有一定关系，同时也跟是否使用支持事务的存储引擎有关系。该值默认也是10000.
-
relay_log_info_repository为FILE，假设设置的值为N，那么每N次事务都会都会调用fdatasync()强制将relay-log.info刷入磁盘
-
relay_log_info_repository为TABLE，如果使用了支持事务的引擎，则该表每次事务结束都会被更新;如果没有使用事务引擎则会在写入N个binlog事件的时候更新该表。
-
relay_log_info_repository为FILE，MySQL不会调用fdatasync()，而是将刷入磁盘的调度交给OS;
-
relay_log_info_repository为TABLE，如果使用了支持事务的存储引擎，则每次事务的时候该表都会被更新;如果没有使用事务引擎，则永远不会被更新
-
当sync_relay_log_info为0时
-
当sync_relay_log_info大于0时
2. 复制模型
平常的开发中，其实很少说一上来就直接搞主从架构的。费时间、费钱还引入了额外的复杂度，最后发现投入了这么多一个单MySQL服务器就完全能handle。
这就跟一个产品的架构迭代是一样的，刚刚起步的时候一个单体应用足够了。当你的业务扩展，请求膨胀，单体无法抗住压力了，就会考虑开始部署多实例，开始采用微服务架构去做横向扩展、负载均衡。
2.1 一主多从
当然你也可以把它当成一主一从。
这是最简单的模型，特别适合少量写、大量读的情况。读请求被分到了各个从库上，有效的帮主库分散了压力，能够提升读并发。当然，你也可以只是把从库当成一个灾备库，除了主从复制之外，没有其他任何的请求和数据传输。
甚至你可以把其中一个备库作为你的预发环境的数据库，当然，这说到底还是直接动了生产环境的数据库，是一种过于理想的用途，因为这还涉及到生产环境数据库的数据敏感性。不是所有人都能够接触到的，需要有完善的权限机制。
（编辑：南昌站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
