mysql是一种关系数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。
mysql所使用的 sql 语言是用于访问数据库的常用标准化语言。mysql 软件采用了双授 权政 策，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择mysql 作为网站数据库。
在这篇文章，小编要跟大家介绍的是在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 宕机，那么到 slave 上面该事务又不可见了，该问题直到 5.7 才解决;
d. mysql 5.7 引入无损半同步复制，引入参 rpl_semi_sync_master_wait_point，该参数默认为 after_sync，指的是在切成半同步之前，事务不提交，而是接收到 slave 的 ack 确认之后才提交该事务，从此，复制真正可以做到无损的了。
e.可以再说一下 5.7 的无损复制情况下，master 意外宕机，重启后发现有 binlog没传到 slave 上面，这部分 binlog 怎么办?分 2 种情况讨论，1 宕机时已经切成异步了，2 是宕机时还没切成异步?这个怎么判断宕机时有没有切成异步呢???分别怎么处理???
延时性：
可以讲下5.5 是单线程复制，5.6 是多库复制(对于单库或者单表的并发操作是没用的)，5.7 是真正意义的多线程复制，它的原理是基于 group commit，只要master 上面的事务是 group commit 的，那 slave 上面也可以通过多个 worker线程去并发执行。和 mairadb10.0.0.5 引入多线程复制的原理基本一样。数据恢复?他想问什么?
(3)再问各种工作遇到的复制 bug 的解决方法
复制的bug?上面说的算吗?我还真没遇到过，5.6 的多库复制有时候自己会停止，我们写了一个脚本重新 start slave;待补充…
