主从复制
- 介绍一下 MySQL 主从复制？
- 主从复制是基于 binlog 来实现的；
- 主库发生新的操作，都会记录到 binlog 中；
- 从库取得主库的 binlog 进行回放；
- 主从复制的过程是异步的；
- 主从复制的前提（搭建主从复制）？
- 2 个或以上的数据库实例；
- 主库需要开启 binlog 日志文件；
- server_id 要不同，区分不同节点；
- 主库需要建立专门用于复制的用户（replication slave）；
- 从库应该通过备份主库，恢复数据的方法进行补数据；
- 人为告诉从库一些复制信息（比如 IP、PORT、User、Password 等）；
- 从库开启专门的复制线程；
- 从库如何告诉主库复制信息？
- 执行
change master to命令，例如：
mysql
代码解读
复制代码
CHANGE MASTER TO
MASTER_HOST='172.21.0.3',
MASTER_USER='repl',
MASTER_PASSWORD='',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=3596,
MASTER_CONNECT_RETRY=10;
- 复制线程都有什么，如何开启？
- 有 IO 线程和 SQL 线程；
- 开启方式：从库执行
start slave;
- 如何检查主从同步是否成功？
- 方法一：主库插入一条数据，看看从库是否有该条数据；
- 方法二：从库执行
show slave status;命令：
- 查看 IO 线程和 SQL 线程的状态
- 主从复制涉及的文件有哪些？
- 主库：
- binlog
- 从库：
- relaylog：中继日志
- master.info：主库信息文件
- relaylog.info：relaylog 应用的信息
- 主从复制涉及到的线程有哪些？
- 主库：
- Binlog_Dump 线程
- 从库：
- SLAVE_IO 线程
- SLAVE_SQL 线程
- 主从复制过程（原理）？
- 从库执行
change master to命令（主库的连接信息 + 复制的起点）； - 从库会将以上信息记录到
master.info文件中； - 从库执行
start slave命令，立马开启 IO 线程和 SQL 线程； - 从库 IO 线程读取
master.info文件里的信息，获取到 Host、Port、IP、User、Password、Binlog 的位置信息； - 从库 IO 线程请求连接主库，主库专门提供一个 DUMP 线程，用于与 IO 线程交互；
- IO 线程根据 binlog 的位置信息（mysql-bin.000001），请求主库新的 binlog；
- 主库通过 DUMP 线程将最新的 binlog 通过网络传送给从库的 IO 线程；
- IO 线程接收到新的 binlog 日志，存储在 TCP/IP 缓存中，立即返回 ACK 给数据库，并更新
master.info信息。 - IO 线程将 TCP/IP 缓冲区中的数据转存到
relaylog中； - SQL 线程读取
relaylog.info信息，获取上次已经应用过的 relaylog 的位置信息； - SQL 线程会按照上次的位置点回放最新的
relaylog，并在此更新relaylog.info信息 - 从库会对已经用过的 relaylog 自动清理；
- 从库如何知道主库有新的 binlog 日志产生？
- 一旦主从复制建立成功，主库如果有任何更新，则会通过 DUMP 线程，给 IO 线程发送信号，让 IO 线程进行同步数据。
- 如何查看主从复制是否延迟？
- 执行
show slave status;命令，查看Master_Log_File和Read_Master_Log_Pos两个字段，和主库保持一致就是不延迟。
- 主从复制出现故障一般都是什么？如何排查？如何解决？
- IO 线程（主要关注从库线程）：
- 可能出现的问题：
- 无法连接主库；
- 无法请求 binlog；
- 解决方案：
- 手动使用复制账号登录；
stop slave；reset slave all；change master to；start slave;
- SQL 线程：
- 具体看哪个 SQL 有问题，解决冲突即可
- 主从延时可能会有哪些原因？如何解决？
- 主库方面：
- binlog 写入不及时：
sync_binlog=1：写入日志必写磁盘
- DUMP 线程：默认情况下 DUMP 线程是串行传输 binlog，在并发事务量大时，由于 DUMP 线程是串行的，导致传输数据较慢。
- DUMP 并行执行（必须开启 GTID，使用 Group Commit 方式）
- 长事务（同上）
- 主库极其繁忙
- 慢 SQL
- 锁等待
- 从库较多
- 锁等待
- 从库方面：
- SQL 线程串行执行：
- 5.6 版本，基于 GTID，实现 SQL 线程并行执行（针对多个数据库并行，同一数据库还是串行的）
- 主从延迟如何监控？
- 查看从库状态，同步了多少，执行了多少，和主库日志位置对比。
