云原生俱乐部-mysql知识点归纳（3）

我发现mysql的内容还是挺好写的，因为我回去看ppt的时候，我居然找不到哪句话是重点，或者说每句话都是重点。因此写mysql系列全靠个人的理解和总结，既然是自己规划内容，那我就删了很多内容，也就是没全讲。

ppt中的mysql的知识体系结构还是很完善，但是有写内容只提了一点，浅尝辄止，所以理解也不深刻。但是也没有太多时间让我们去深入mysql了，理解框架是最重要的，至于细节内容就先放一放，不然mysql的全部内容够学好一阵子了。

这篇文件主要讲一讲维护系统稳定性、优化查询性能、选择备份策略和管理mysql复制拓扑这四部分内容。其实主要是让我自己再梳理一遍知识点，害，才学没几天我都要忘完了。第一次学印象也不深刻，况且每天都要新学大量的知识。

维护系统稳定性

我们可以定义系统基线来衡量系统的稳定性，通过测量系统的指来和系统基线进行比较，来判断系统是否正常。如sql语句的执行时间，如果超过了多少秒可以视为不正常。因此基线的确定，以及系统值（如cpu、内存使用）的收集在维护稳定性中起着重要作用。

[1]优化性能

对于性能来讲，需要使用具体化参数来表示，比如CPU利用率，内存使用情况，磁盘占用情况等。还有服务吞吐量，响应时间等最重要的参数用来衡量系统性能，我们可以使用MySQL企业监视器来监控mysql服务运行情况。

如何系统优化性能呢？这是一个课题，比如做负载均衡，做代理，资源冗余等，这些都是系统架构层面的。容量规划，硬件冗余等都需要架构师来考虑，分析可能需要使用的必要资源，并能够做好规划。

不过以上资源也不是说越多越好，太多的资源则会造成浪费，比如交换分区不是越大越好，内存也不是越大越好（超出寻址能力）。但是有个关键的是数据库永远要做备份，并且做集群避免单点故障（这能够保证系统不稳定出现故障的时候，有能力回退）。

[2]故障排查

如果系统不稳定了，我们该怎么做？一般可以从检查硬件，测试软件这两方面开始，如果没有发现问题的话，那需要考虑软硬件之间的兼容性，当然也有可能是两个表面不相干的但又存在内在联系的组件导致的问题。

一般来说我们先通过观察收集的系统值来判断是哪里出现了问题，然后再定位问题的根源，可以通过查询错误信息或者相关日志。之后再根据问题调整系统的状态，如果没办法解决问题，那么只好通过上面提到的备份的数据库进行回退还原了。

[3]RAID技术

通过冗余硬件可以应对其他硬件损坏的风险，RAID（Redundant Array of Independent Disks，独立磁盘冗余阵列）是一种将多个物理磁盘组合成逻辑单元的数据存储技术。

RAID 镜像允许损坏任意一块磁盘，但是容量利用率只有50%。RAID 条带化（并行读写）则是加快读写速度，n块磁盘相当于n倍的速度，但是没有冗余，任意磁盘损坏则所有的磁盘都损坏。一般来说使用RAID10，即条带化+镜像，至少需要四块硬盘。

[4]优化查询性能

创建合适的索引可以提高服务器性能，同时优化查询语句可以大大减少查询时间。优化器（sql层）会重构语句以执行某些优化操作，我们可以使用EXPLAIN查看优化器对索引的选择，SHOW WARNINGS命令将显示EXPLAIN生成的注释级警告，其中包含重构后语句的伪SQL版本。

选择备份策略

备份用于将系统恢复到出故障之前的状态，并且备份可以用于模拟生产环境用于分析。这章主要讲如何区分不同类型的备份，以及不同备份的优缺点以及适用场景。

[1]三种备份方式

备份的时候有三种方式：冷备--不允许访问数据（可能会造成用户的不好体验）；温备--允许访问数据，但不允许修改数据；热备 -- 允许完全访问数据（这种情况下需要满足一定条件） 。

换一个角度来说，也可以分为基于增量的备份，基于快照的备份，基于复制的备份；或者说是逻辑备份与物理备份。注意，除了数据之外，日志也需要备份（记录着对数据的修改），可以用于协调备份数据。

[2]逻辑备份与物理备份

逻辑备份--使用mysqldump（温备）、mysqlpump（热备），这会创建一个可执行的MySQL脚本，将数据库和表转化为sql语句，在任何mysql数据库中都可以通过该脚本还原。不过存在致命缺陷，就是某些非确定性函数（如  `NOW()`、`RAND()`、`UUID()`）在主从库可能生成不同结果。

并且默认情况下​​，`mysqldump`导出的SQL文件​​不包含用户账户创建语句​​，仅包含数据库对象和数据。不过可以使用 mysqldump --all-databases --system=all > full_backup.sql导出所有系统表（包括mysql.user）。

逻辑备份除了实际的数据备份之外，还会有很多的逻辑辅助文件，所以占用的空间比实际上要备份的数据要大。物理备份可以使用tar、cp、rsync等命令直接将数据复制备份，这个备份要比逻辑备份快。

MySQL Enterprise Backup是物理备份工具，也支持热备份。LVM快照​（热备）也是一种​物理备份​方法，它通过​文件系统或存储层​对数据库的数据文件进行​​瞬间冻结​​，生成一个可恢复的时间点副本。

管理mysql复制拓扑

mysql的二进制日志文件课用于同步主从服务器的数据，MySQL二进制日志是数据库系统的"黑匣子"，完整记录了所有数据变更历史。

[1]复制拓扑结构

标准主从结构：读写分离，但是受单点故障；级联复制结构（设中间从库）：减轻主库复制压力，但延迟累计；双主复制结构：故障切换恢复快，但冲突风向高；`server_id`是管理员可控的拓扑标识，而`server_uuid`是系统维护的全局唯一标识，共同保障了复制架构的可靠性和数据一致性。

搭建mysql复制拓扑结构的过程有：规划绘制复制拓扑图--标识参与复制的所有服务器--为每个服务器设置唯一ID--配置每个主服务器--配置从属服务器（连接主服务器）--初始化并启动。注意如果主服务器有数据，需要让从服务器先从备份数据中同步再连接（保证一致性和完整性）。

[2]复制模式

主从mysql服务器之间有同步复制、异步复制（牺牲安全换性能）和半同步复制三种方式。半同步复制就是在一定时间内等待一个从属服务器的回应，然后如果在规定时间内没有接收到任何回应，则更改为异步模式。

除了在最开始提到的二进制日志复制数据之外，还有GTID（全局事务标识）复制模式，从机重启后会动定位并补做缺失的事务​，无需手动指定二进制日志的位置，这是 GTID 相比传统复制的核心优势。并且支持事务溯源，即精确追踪事务来源，便于审计和排错。

[3]mysql复制线程

二进制日志转储线程，读取二进制日志事件并发送到从服务器的IO_THREAD，从服务器的IO_THREAD接受来自主服务器的二进制日志事件（由主服务器转储线程给的），然后发送到从服务器的中继日志。

中继日志用来转储主服务器的二进制日志，并应用到本地的数据库。SQL线程--SQL_THREAD：单线程的话直接接手中继日志，多线程的话则在工作者线程中分配中继日志。

start slave 和stop slave会关闭和打开IO_THREAD和SQL_THREAD。IO线程有connecting、running、waiting等状态，可以通过show slave status来查看。

GTID模式同样使用以上三个线程，区别在于binlog转储线程还会发送GTID，然后IO线程更新中继日志和gtid_executed，同样由SQL线程写入数据库。并且使用GTID无需指定二进制日志文件位置，能够精确断点续传。