第二讲--mysql主从专题

第一题

讲解：

• 此题考查的是异步复制的特性与作用
• 异步复制(asynchronous replication)是主从之间不保证实时性与完成性的复制。B错。
• 主库不会等待从库完成relay log才提交(半同步复制semi-synchronous replication)，更不会等待从库完成relay log执行完成才commit(同步复制 synchronous replication)。 可以增加多个从库来分散数据库读压力，但不能分散写操作。A错，C正确。
• mysqlbackup不会自动备份从库，但在从库进行备份可以降低对主库的压力。D错，E正确。

第二题

讲解：

• 此题考查的是异步复制asynchronous replication的binlog基础
• 主从之间的binlog是包含了主库的所有写操作，也就是数据库变化，E正确。
• 主从之间同步是从库拉取主库的binlog(pull from master)，A正确。

第三题

?讲解：

• 此题考查的是组复制(group replication)开启的条件

组复制启用要求如下：

• 必须是Innodb 引擎表
• 要求每个表都有主键(primary key)或与主键等效的列(如unique索引列)
• binlog必须为row模式
• 必须开启log_slave_updates
• binlog_checksum必须关闭（8.0.20之前不支持checksum，8.0.21开始支持但不是必须）
• lower_case_table_names=1
• 每个节点的server-id唯一

第四题

讲解：

• 此题考查的是multi-source replication的基础

multi-source replication有以下特性：

• 可以基于GTID 模式建立replication，也可以基于FILE+POSITION建立replication，因此DE错。
• multi-source replication没有不一致检测与解决能力，因此F错，B正确。
• multi-source replication可以基于relay_log_recovery以弹性处理故障，而不需要重re-instanced

第五题

?讲解：

• 此题考查对主从同步状态show slave status\G的理解
• seconds_behind_master指的是从库本地SQL_THREAD提交的最近一个事务的时间与IO_THREAD接收到的最新一个事务日志的时间之差。
• 而在网络理想状态下，从库IO_THREAD接收到的最新一个事务日志的时间就是主库提交的最新一个事务的时间。

综合这两条，选项B正确。

第六题

?讲解：

• 此题考查的是主从同步中若主库磁盘空间因为binlog的增长而耗尽后如何处理

要清理binlog日志，可以有如下三种方式：

• 删除主库上已经同步到从库的那部分binlog，而不是删除全部binlog，选项B错误。
• 主库执行PURGE BINARY LOGS来已经同步到从库的那部分binlog。选项C正确。
• 设置主库的binlog_expire_logs_seconds以自动清理binlog

第七题

?讲解：

• 此题考查的是基于file+position的异步复制(asynchronous position-based replication)的从库relay log受损如何修复

当relay log受损后应采用如下步骤修复：

• stop slave，
• 删除relay log，
• 执行change master to重新建立主从关系(file+position为show slave status\G显示的值),
• start slave同步master binlog到本地relay log.

第八题

?讲解：

• 此题考查的是异步复制asynchronous replication的binlog基础，为第三题的变种
• IO_THREAD负责连接主库，并读取binlog到本地的relay log中，选项B正确。
• SQL_THREAD负责读取本地relay log并执行其中的sql语句。选项D错误。

第九题

讲解：

• 此题考查的是GTID-MODE的主从同步gtid_purged和gtid_executed的概念
• gtid_purged是指已经删除掉的binlog中包含的事务的gtid集合 gtid_executed是指已经执行过的事务的gtid集合
• 题干意思：当从库已经中断同步多天后要重新启动同步，基于题目中给出的master和slave的gtid_purged和gtid_executed值，启动同步会发生什么情况。
• 首先看master的值：gtid_executed中包含了bbbbbbbb:1-50的事务，gtid_purged中包含了bbbbbbbb:1-10的事务，也就是说master上现在只有bbbbbbbb:11-50的事务。
• 然后看slave的值，它的gtid_executed没有bbbbbbbb的事务执行记录，如果它要与主库同步则需要同步bbbbbbbb:1-50的事务。
• 显然master已经缺少了bbbbbbbb:1-10的事务，那么从库在启动同步后，io_thread会报错无法同步这部分事务的gtid。

选项A正确

第十题

讲解：

• 此题考查的是半同步复制何时会降级为异步复制（semi-synchronous replication degrade to asynchronous replication）
• 半同步的本质是主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端，也就是此时才会commit。
• 如果在规定时间内主库没有等到从库已经接收到事务日志的响应，则半同步复制会降级为异步，这个规定时间就是rpl_semi_sync_master_timeout。
• 题目中讲到rpl_semi_sync_master_timeout从来没有达到过，那说明半同步复制始终没有降级，也就是主从之间事务是一致的，从库没有丢失过主库的任何事务日志。 此时主库宕机，由于从库的relay log中有主库的全部事务日志，只要从库把relay log执行完成，就不会丢失任何事务。但如果realy log中是一个特别大的事务，从库执行relay log可能会消耗比较长时间，应用端立刻读取从库就会读到过时的数据。

因此，此题AD选项正确。

第十一题

讲解：

• 此题考察的是对seconds_behind_master的含义深层理解

seconds_behind_master指的是从库本地SQL_THREAD提交的最近一个事务的时间与IO_THREAD接收到的最新一个事务日志的时间之差。而在网络理想状态下，从库IO_THREAD接收到的最新一个事务日志的时间就是主库提交的最新一个事务的时间。

当seconds_behind_master持续增长的时候，只可能是发生了以下情况：

SQL_THREAD在执行一个很大的事务，导致长时间没有完成，而IO_THREAD在持续从master拉取binlog到本地relay_log，导致relay_log的时间戳不断增长。也就是SQL_THREAD卡了。

选项A描述因为主库繁忙，从库拿不到binlog而陷入等待，如果是这样的情况这个值是不会持续增大的。A错。

选项B描述跟没有主键有关，实际上这个值跟是否有主键无关。B错。

选项C描描述这个值持续增长是IO 延迟导致，并不能反应出事务队列大小。实际上主库事务并发很高，它是可以反映出事务队列的大小的。

因此选项DE正确。描述的都是从库的sql_thread卡住。

第二讲完成。

作者：老哥讲数据库

简介：数据库高级架构师，oracle 11g OCM认证，MySQL 5.7 & 8.0 OCP认证。

原创文章，转载请注明来源。