1、MySQL 的复制原理以及流程
(1)、复制基本原理流程
- 1）主服务：Binlog dump 线程——记录下所有改变了数据库数据的语句，放进 master 上的 binlog 中；
- 2）从服务器：IO 线程——在使用 start slave 之后，负责从 master 上拉取 binlog 内容，放进自己的 relay log中；
- 3）从服务器：SQL 执行线程——执行 relay log 中的语句。
(2)、MySQL 复制的线程有几个及之间的关联
MySQL 的复制是基于如下 3 个线程的交互（ 多线程复制里面应该是 4 类线程）
- 1）Master 上的 Binlog dump 线程，该线程负责将 master 的 binlog event 传到 Slave；
- 2）Slave 上的 IO 线程，该线程负责接收 Master 传过来的 binlog，并写入 relay log；
- 3）Slave 上的 SQL 线程，该线程负责读取 relay log 并执行；
重要：如果是多线程复制，无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制， SQL 线程只做 coordinator，只负责把 relay log 中的 binlog读出来然后交给 worker 线程， woker 线程负责具体 binlog event 的执行；
(3)、MySQL如何保证复制过程中数据一致性及减少数据同步延时
一致性主要有以下几个方面：
参考来源：
https://www.cnblogs.com/hugb/articles/5827658.html
https://blog.csdn.net/u011277123/article/details/71126741
- 1）在 MySQL 5.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 线程执行到的位置和用户事务恢复到一致性的状态。
- 2）MySQL 5.6 引入 GTID 复制，每个 GTID 对应的事务在每个实例上面最多执行一次， 这极大地提高了复制的数据一致性；
- 3）MySQL 5.5 引入半同步复制， 用户安装半同步复制插件并且开启参数后，设置超时时间，可保证在超时时间内如果 binlog 不传到 Slave 上面，那么用户提交事务时不会返回，直到超时后切成异步复制，但是如果切成异步之前用户线程提交时在 master 上面等待的时候，事务已经提交，该事务对 Master上的其他 session 是可见的，如果这时 Master 宕机，那么到 Slave 上该事务又不可见了，该问题直到 5.7 才解决；
2、MySQL 中 myisam 与 innodb 的区别，至少 5 点
(1)、问 5 点不同
1. InnoDB 支持事物，而 MyISAM 不支持事物
2. InnoDB 支持行级锁，而 MyISAM 支持表级锁
3. InnoDB 支持MVCC, 而 MyISAM 不支持
4. InnoDB 支持外键，而 MyISAM 不支持
5. InnoDB 不支持全文索引，而 MyISAM 支持。
6. InnoDB 不能通过直接拷贝表文件的方法拷贝表到另外一台机器， myisam 支持
7. InnoDB 表支持多种行格式， myisam 不支持
8. InnoDB 是索引组织表， myisam 是堆表
参考地址：https://www.cnblogs.com/panwenbin-logs/p/8366940.html
参考地址：http://www.ywnds.com/
