
资源由 www.eimhe.com 美河学习在线收集提供
MySQL 面试题
1, mysql 的复制原理以及流程。
(1) 先问基本原理流程,3 个线程以及之间的关联。
MySQL 的复制原理:Master 上面事务提交时会将该事务的 binlog event 写入
binlog file,然后 master 将 binlog event 传到 slave 上面,slave 应用该 binlog event 实现
逻辑复制。
MySQL 的复制是基于如下 3 个线程的交互(多线程复制里面应该是 4 类线程):
a. Master 上面的 binlog dump 线程,该线程负责将 master 的 binlog event 传到
slave;
b. Slave 上面的 IO 线程,该线程负责接收 Master 传过来的 binlog,并写入 relay
log;
c. Slave 上面的 SQL 线程,该线程负责读取 relay log 并执行;
d. 如果是多线程复制,无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真
正的多线程复制,SQL 线程只做 coordinator,只负责把 relay log 中的 binlog
读出来然后交给 worker 线程,woker 线程负责具体 binlog event 的执行;
(2) 再问一致性延时性,数据恢复。
一致性可以从以下几个方面来讲:
a. 在 MySQL5.5 以及之前,slave 的 SQL 线程执行的 relay log 的位置只能保存
在文件(relay-log.info)里面,并且该文件默认每执行 10000 次事务做一次
同步到磁盘,这意味着 slave 意外 crash 重启时,SQL 线程执行到的位置和
数据库的数据是不一致的,将导致复制报错,如果不重搭复制,则有可能会
导致数据不一致。MySQL 5.6 引入参数 relay_log_info_repository,将该参
数设置为 TABLE 时,MySQL 将 SQL 线程执行到的位置存到
mysql.slave_relay_log_info 表,这样更新该表的位置和 SQL 线程执行的用
户事务绑定成一个事务,这样 slave 意外宕机后,slave 通过 innodb 的崩溃
恢复可以把 SQL 线程执行到的位置和用户事务恢复到一致性的状态。
b. MySQL 5.6 引入 GTID 复制,每个 GTID 对应的事务在每个实例上面最多执行
一次,这极大地提高了复制的数据一致性;
c. MySQL 5.5 引入半同步复制,用户安装半同步复制插件并且开启参数后,设
置超时时间,可保证在超时时间内如果 binlog 不传到 slave 上面,那么用户
提交事务时不会返回,直到超时后切成异步复制,但是如果切成异步之前用
户线程提交时在 master 上面等待的时候,事务已经提交,该事务对 master
评论