MySQL 主从，5 分钟带你掌握

MySQL 主从一直是面试常客，里面的知识点虽然基础，但是能回答全的同学不多。

比如楼哥之前面试小米，就被问到过主从复制的原理，以及主从延迟的解决方案，因为回答的非常不错，给面试官留下非常好的印象。你之前面试，有遇到过哪些 MySQL 主从的问题呢？

所谓 MySQL 主从，就是建立两个完全一样的数据库，一个是主库，一个是从库， 主库对外提供读写的 *** 作，从库对外提供读的 *** 作 ，下面是一主一从模式：

对于数据库单机部署，在 4 核 8G 的机器上运行 MySQL 5.7 时，大概可以支撑 500 的 TPS 和 10000 的 QPS， 当遇到一些活动时，查询流量骤然，就需要进行主从分离。

大部分系统的访问模型是读多写少，读写请求量的差距可能达到几个数量级，所以我们可以通过一主多从的方式， 主库只负责写入和部分核心逻辑的查询，多个从库只负责查询，提升查询性能，降低主库压力。

MySQL 主从还能做到服务高可用，当主库宕机时，从库可以切成主库，保证服务的高可用，然后主库也可以做数据的容灾备份。

整体场景总结如下：

MySQL 的主从复制是依赖于 binlog 的，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上二进制日志文件。

主从复制就是将 binlog 中的数据从主库传输到从库上，一般这个过程是异步的，即主库上的 *** 作不会等待 binlog 同步的完成。

详细流程如下：

当主库和从库数据同步时，突然中断怎么办？因为主库与从库之间维持了一个长链接，主库内部有一个线程，专门服务于从库的这个长链接的。

对于下面的情况，假如主库执行如下 SQL，其中 a 和 create_time 都是索引：

我们知道，数据选择了 a 索引和选择 create_time 索引，最后 limit 1 出来的数据一般是不一样的。

所以就会存在这种情况：在 binlog = statement 格式时，主库在执行这条 SQL 时，使用的是索引 a，而从库在执行这条 SQL 时，使用了索引 create_time，最后主从数据不一致了。

那么我们改如何解决呢？

可以把 binlog 格式修改为 row，row 格式的 binlog 日志记录的不是 SQL 原文，而是两个 event:Table_map 和 Delete_rows。

Table_map event 说明要 *** 作的表，Delete_rows event用于定义要删除的行为，记录删除的具体行数。 row 格式的 binlog 记录的就是要删除的主键 ID 信息，因此不会出现主从不一致的问题。

但是如果 SQL 删除 10 万行数据，使用 row 格式就会很占空间的，10 万条数据都在 binlog 里面，写 binlog 的时候也很耗 IO。但是 statement 格式的 binlog 可能会导致数据不一致。

设计 MySQL 的大叔想了一个折中的方案，mixed 格式的 binlog，其实就是 row 和 statement 格式混合使用， 当 MySQL 判断可能数据不一致时，就用 row 格式，否则使用就用 statement 格式。

有时候我们遇到从数据库中获取不到信息的诡异问题时，会纠结于代码中是否有一些逻辑会把之前写入的内容删除，但是你又会发现，过了一段时间再去查询时又可以读到数据了，这基本上就是主从延迟在作怪。

主从延迟，其实就是“从库回放” 完成的时间，与 “主库写 binlog” 完成时间的差值， 会导致从库查询的数据，和主库的不一致 。

谈到 MySQL 数据库主从同步延迟原理，得从 MySQL 的主从复制原理说起：

总结一下主从延迟的主要原因 ：主从延迟主要是出现在 “relay log 回放” 这一步，当主库的 TPS 并发较高，产生的 DDL 数量超过从库一个 SQL 线程所能承受的范围，那么延时就产生了，当然还有就是可能与从库的大型 query 语句产生了锁等待。

我们一般会把从库落后的时间作为一个重点的数据库指标做监控和报警，正常的时间是在毫秒级别，一旦落后的时间达到了秒级别就需要告警了。

解决该问题的方法，除了缩短主从延迟的时间，还有一些其它的方法，基本原理都是尽量不查询从库。

具体解决方案如下：

在实际应用场景中，对于一些非常核心的场景，比如库存，支付订单等，需要直接查询从库，其它非核心场景，就不要去查主库了。

两台机器 A 和 B，A 为主库，负责读写，B 为从库，负责读数据。

如果 A 库发生故障，B 库成为主库负责读写，修复故障后，A 成为从库，主库 B 同步数据到从库 A。

一台主库多台从库，A 为主库，负责读写，B、C、D为从库，负责读数据。

如果 A 库发生故障，B 库成为主库负责读写，C、D负责读，修复故障后，A 也成为从库，主库 B 同步数据到从库 A。

在MySQL日常运维工作中，经常会用到各种管理工具，这些工具属于mysql自带的管理工具，存储在mysql目录下的bin目录中，例如对象查看，备份，日志分析等，熟练使用是运维开发人员的必备工作，这些工具参数很多，这里介绍常用选项，更多详细可参考帮助文件。

在mysql工具集中，管理员使用最频繁的就是mysql命令了，它是连接数据库的客户端工具，类似oracle中的sqlplus，通过它可以进入mysql控制台界面。在大部分情况下，使用简单，命令语法如下：

常用选项：选项一般有两种表达方式，一种是"-"+选项单词缩写和选项值；另一种是“--”+选项的完整单词“=”选项实际值。例如我们连接数据库的两种命令如下：

myisampack是一个表压缩工具，它对MyISAM存储引擎表能进行高度压缩，可以很大的节省磁盘空间，但是压缩后的表只能读，不能写，不能进行DML *** 作，所以它的使用场景一般是归档 历史 数据。命令如下：

当对一个压缩表进行增加 *** 作时会报一个错误：ERROR 1036 Table is read only,但时对查询和统计时可以正常 *** 作的。

mysqladmin是一个对数据库进行管理 *** 作的客户端工具，可用来检查服务器是否可用、显示数据库版本号和状态，还可以直接新增一个数据库，也可对数据库进行关闭，功能和mysql类似，它的参数和mysql差异不大，命令如下：

它还可以修改root密码，命令如下

MySQL自带的mysqlbinlog工具的作用是解析二进制binlog的日志内容，把二进制数据还原成mysql可以执行的SQL语句。我有篇文章专门介绍该工具的使用，请具体参考：

传送门：mysql运维管理（七）：使用Mysqlbinlog工具恢复增量数据

mysqlcheck工具可以用来检查和修复MyISAM存储引擎的表,还能做优化的工作，例如check、repair、analyze、optimize等等功能。具体命令如下：

注意，如果是innodb引擎的表，不能用上述优化工具。

mysqldump工具用来逻辑备份数据库，或者数据迁移。该工具是最常用的备份工具。

我有篇文章专门介绍该工具的使用，请具体参考：

传送门：mysql运维管理（五）：掌握MySQLdump逻辑备份工具使用

它是数据导入工具，专门用来处理mysqldump 加-T选项后导出的文本文件，基本用法很简单，命令如下：

客户端对象查找工具，用来查找数据库，数据库的表，表中列或者索引，具体使用命令如下:

不加任何选项，默认显示所有数据库。

常用参数：

--count ,用来显示数据库和表的统计信息，不指定数据库的话，显示所有库信息

-k或者--keys，用来显示指定表中所有索引，例如查看employees库中employees表的索引信息，

在使用mysql使用过程中，会经常出现错误，错误信息都会带有一个编码，具体编码代表什么意思，就需要perror来查看。用法很简单：

举个例子，我们故意写错一个查询语句，例如：

现在有一个编码1054，我们可以用perror查看下

结果跟用工具显示的内容差不多，当然第三方工具也会显示错误信息。

本章做了一个常用工具的使用汇总，并举例说明了基本用法，熟练使用是每个运维人员必修内容，当然还有很多参数没有一一列举，可以参考相关帮助文档。

云运维涉及的方面比较广，基础知识仍然是必不可少：Linux基础，基本linux命令的使用，Shell脚本编程，Linux *** 作系统知识（Ubuntu，CentOS系统等）。

了解完基础知识后，可以给自己确定下方向：

1、大数据方向： 涉及Hadoop（hdfs，yarn等），spark，hbase，hive，storm等知识

2、虚拟化技术：openstack，kvm，nova，docker，vmware，xen等

3、应用：mysql，redis，memcached，sqlserver

4、对目前的云提供商的业务的了解：阿里云，腾讯云，京东云，金山云，AWS等

5、脚本开发（DevOps必备）：python，ruby

6、比较常用的运维工具：jenkins，chef，puppet，ansible等

---