面试题：MySQL主从复制三个线程，11个参数？
MySQL 主从复制涉及到三个线程：
一个在主节点的线程：log dump thread
从库会生成两个线程：一个 I/O 线程，一个 SQL 线程
主库会生成一个 log dump 线程,用来给从库 I/O 线程传 Binlog 数据。
从库的 I/O 线程会去请求主库的 Binlog，并将得到的 Binlog 写到本地的 relay log (中继日志)文件中。
SQL 线程,会读取 relay log 文件中的日志，并解析成 SQL 语句逐一执行。
复制的基本过程
- 在从节点上执行
sart slave命令开启主从复制开关，开始进行主从复制。从节点上的 I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容。 - 主节点接收到来自从节点的 I/O 请求后，通过负责复制的 I/O 进程（log Dump Thread）根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的 Binlog file 以及 Binlog position（Binlog 下一个数据读取位置）。
- 从节点的 I/O 进程接收到主节点发送过来的日志内容、日志文件及位置点后，将接收到的日志内容更新到本机的 relay log 文件（Mysql-relay-bin.xxx）的最末端，并将读取到的 Binlog文件名和位置保存到
master-info文件中，以便在下一次读取的时候能够清楚的告诉 Master ：“ 我需要从哪个 Binlog 的哪个位置开始往后的日志内容，请发给我”。 - Slave 的 SQL 线程检测到relay log 中新增加了内容后，会将 relay log 的内容解析成在能够执行 SQL 语句，然后在本数据库中按照解析出来的顺序执行，并在
relay log.info中记录当前应用中继日志的文件名和位置点。
| 关键角色 | 描述 | |||
主节点 log dump 线程 |
当从节点连接主节点时，主节点会为其创建一个 log dump 线程，用于发送和读取 Binlog 的内容。在读取 Binlog 中的操作时，log dump 线程会对主节点上的 Binlog 加锁；当读取完成发送给从节点之前，锁会被释放。主节点会为自己的每一个从节点创建一个 log dump 线程。 | |||
从节点I/O线程 |
当从节点上执行start slave命令之后，从节点会创建一个 I/O 线程用来连接主节点，请求主库中更新的Binlog。I/O 线程接收到主节点的 log dump 进程发来的更新之后，保存在本地 relay-log（中继日志）中。 |
|||
relay log |
这里又引申出一个新的日志概念。MySQL 进行主主复制或主从复制的时候会在要复制的服务器下面产生相应的 relay log。 relay log 是怎么产生的呢？ 从服务器 I/O 线程将主服务器的 Binlog 日志读取过来，解析到各类 Events 之后记录到从服务器本地文件，这个文件就被称为 relay log。然后 SQL 线程会读取 relay log 日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致。中继日志充当缓冲区，这样 master 就不必等待 slave 执行完成才发送下一个事件。 |
|||
| 11个参数 |
mysql> show variables like '%relay%'; +---------------------------+------------------------------------------------------------+ | Variable_name | Value | +---------------------------+------------------------------------------------------------+ | max_relay_log_size | 0 | | relay_log | yangyuedeMacBook-Pro-relay-bin | | relay_log_basename | /usr/local/mysql/data/yangyuedeMacBook-Pro-relay-bin | | relay_log_index | /usr/local/mysql/data/yangyuedeMacBook-Pro-relay-bin.index | | relay_log_info_file | relay-log.info | | relay_log_info_repository | TABLE | | relay_log_purge | ON | | relay_log_recovery | OFF | | relay_log_space_limit | 0 | | sync_relay_log | 10000 | | sync_relay_log_info | 10000 | +---------------------------+------------------------------------------------------------+ 11 rows in set (0.03 sec)
|
| 参数名称 | 描述 | |||
| max_relay_log_size | 标记 relay log 允许的最大值，如果该值为 0，则默认值为 max_binlog_size(1G)；如果不为 0，则max_relay_log_size 则为最大的 relay_log 文件大小。 | |||
| relay_log_purge | 是否自动清空不再需要中继日志时。默认值为1(启用)。 | |||
| relay_log_recovery | 当 slave 从库宕机后，假如 relay log 损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的 relay log，并且重新从 master 上获取日志，这样就保证了 relay log 的完整性。默认情况下该功能是关闭的，将 relay_log_recovery 的值设置为 1 时，可在 slave 从库上开启该功能，建议开启。 | |||
| relay_log_space_limit | 防止中继日志写满磁盘，这里设置中继日志最大限额。但此设置存在主库崩溃，从库中继日志不全的情况，不到万不得已，不推荐使用。 | |||
| sync_relay_log |
这个参数和 Binlog 中的 当设置为 0 时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘 I/O 操作。这个值默认是 0，可动态修改，建议采用默认值。 |
|||
| sync_relay_log_info | 当设置为 1 时，slave 的 I/O 线程每次接收到 master 发送过来的 Binlog 日志都要写入系统缓冲区，然后刷入 relay-log.info 里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量 I/O。当设置为 0 时，并不是马上就刷入 relay-log.info 里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘 I/O 操作。这个值默认是0，可动态修改，建议采用默认值。 | |||
注意事项
Master 开启二进制日志，Master 和 Slave 的 server_id 在局域网内必须唯一；
配置主从复制步骤
Master数据库
(1) 安装数据库；
(2) 修改数据库配置文件，指明 server_id，开启二进制日志(log-bin)；
(3) 启动数据库，查看当前是哪个日志，position 号是多少；
(4) 登录数据库，授权数据复制用户（IP 地址为从机 IP 地址，如果是双向主从，这里的 还需要授权本机的 IP 地址，此时自己的 IP 地址就是从 IP 地址)；
(5) 备份数据库（记得加锁和解锁）；
(6) 传送备份数据到 Slave 上；
(7) 启动数据库；
以上步骤，为单向主从搭建成功，想搭建双向主从需要的步骤：
(1) 登录数据库，指定 Master 的地址、用户、密码等信息（此步仅双向主从时需要）；
(2) 开启同步，查看状态；
Slave 上的配置
(1) 安装数据库；
(2) 修改数据库配置文件，指明 server_id（如果是搭建双向主从的话，也要开启二进制 日志 log-bin）；
(3) 启动数据库，还原备份；
(4) 查看当前是哪个日志，position 号是多少（单向主从此步不需要，双向主从需要）；
(5) 指定 Master 的地址、用户、密码等信息；
(6) 开启同步，查看状态。
参考：https://www.cnblogs.com/rickiyang/p/13856388.html