概述
MySQL运维知识可划分为六个模块：
- 体系结构
- 备份恢复
- 数据复制
- 集群架构
- 性能优化
- 状态监控
体系结构概述
MySQL的体系结构可以分为两层，MySQL Server层和存储引擎层。在MySQL Server层中又包括连接层和SQL层。应用程序通过接口（如ODBC、JDBC）来连接MySQL。最先连接处理的是连接层，连接层包括通信协议、线程处理、用户名密码认证三个部分。
通信协议负责检测客户端版本是否兼容MySQL服务端。
线程处理是指每一个连接请求都会分配一个对应的线程，相当于一条SQL就对应一个线程，一个线程就对应一个逻辑CPU，并会在多个逻辑CPU之间进行切换。
用户名密码认证验证创建的账号和密码，以及Host主机授权是否可以连接到MySQL服务器。
主要的存储引擎介绍
InnoDB
特点：支持事务、行锁，支持MVCC多版本并发控制，并发性高。
应用场景：应用于OLTP业务系统。
MyISAM
特点：不支持事务、表锁，MySQL8.0之后废弃了，并发很低，资源利用率也很低。
应用场景：应用于OLAP业务系统，建议在生产环境尽量少使用 MyISAM 存储引擎。
Memory
特点：表中的数据都在内存中存放，不落地。支持Hash和Btree索引，数据安全性不高，读取速度快。
应用场景：应用于对数据安全性要求不高的环境下。
TokuDB
特点：归 Percona 公司所有。支持事务，支持压缩功能，高速写入功能（比 InnoDB 快 9 倍），在线Online DDL，不产生索引碎片。
应用场景：应用于海量数据的存储场景下。
MariaDB columnstore
特点：列式存储引擎，高压缩功能。
应用场景：数据仓库，OLAP业务系统。
Blackhole
特点：并不存储数据，数据写入时只写 binlog
应用场景：blackhole常用来做binlog转储或测试。
MySQL 备份恢复
数据库备份恢复按运行状态可分为：冷备和热备。热备，又分为逻辑备份和裸文件备份。
- 冷备：必须在数据库关闭的状态下进行备份，能够更好的保证数据库的完整性。
- 热备：能够在数据库处于正常运行的情况下备份，能够更高的保证服务的可用性。
- 逻辑备份：根据SQL，对数据库的逻辑组件（数据库、表、数据对象）进行备份；备份工具有mysqldump、select…into outfile、mydumper.
- 裸文件备份：对数据库操作系统的物理文件（数据文件、日志文件）等的备份；备份工具有xtrabackup.
后续备份，又有：
完全备份：将数据进行完整的备份，包含完整的库、表、索引、视图等，需要花费更长的时间
差异备份：备份自上次完全备份到现在发生改变的数据库内容，备份的文件比完整备份的文件小，备份的速度更快；
增量备份：备份至上次完全备份或增量备份后被修改的数据库内容；
MySQL数据复制
一、半同步复制
MySQL5.5版本之后引入了半同步复制功能，主从服务器必须同时安装半同步复制插件，才能开启该复制功能。
在该功能下，确保从库接受完主库传递过来的 binlog 内容已经写入到自己的 relay log 里面了，才会通知主库上面的等待进程，该操作完毕。
如果等待超时，超过 rpl_semi_sync_master_timeout 参数设置的时间，则关闭半同步复制，并自动转换为异步复制模式，直到至少有一台从库通知主库已经接受到 binlog信息了为止。
二、多源复制
所谓多源复制，就是把多台主库的数据同步到一台从库服务器上，从库会创建通往每个主库的管道。
在MySQL5.7之前的版本中，只要实现一主一从、一主多从或多主多从的复制架构，如果想要实现多主一从的复制，只能使用 MariaDB。MySQL5.7版本已经可以实现多主一从的复制。
多源复制的优势：
（1）可以集中备份，在从库上备份，不会影响线上的数据库正常运行。
（2）节约了购买从库服务器的成本，只需要一个服务器即可。
（3）数据都汇总在一起，方便后期做数据统计。
三、GTID复制
GTID又叫全局事务ID（Global Transaction ID ），是一个已提交事务的编号，并且是一个全局唯一的编号。 MySQL5.6版本之后在主从复制类型上新增了GTID复制。GTID是由 server_uuid 和事务 id 组成的，即 GTID = server_uuid:transaction_id。server_uuid是在数据库启动过程中自动生成的，每台机器的server_uuid不一样。uuid存放在数据目录的 auto.cnf 文件下。而 transaction_id 就是事务提交时由系统顺序分配的一个不会重复的序列号。
GTID存在的价值：
（1）GTID使用master_auto_position=1代替了基于binlog和position号的主从复制搭建方式，更便于主从复制的搭建。
（2）GTID可以知道事务在最开始是在哪个实例上提交的。
（3）GTID方便实现主从之间的 failover，再也不用不断地去找 position 和 binlog 了。
GTID复制限制条件：
（1）不能使用 CREATE TABLE table_name SELECT * FROM table_name。
（2）在一个事务中既包含事务表的操作又包含非事务表。
（3）不支持 CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE 语句操作。
（4）使用 GTID 复制从库跳过错误时，不支持执行该 sql_slave_skip_counter 参数的语法。
复制的一致性校验
背景：
在工作中接触和处理的最多问题就是MySQL的主从同步了，有时发生主库宕机，我们就面临着主从切换的问题，要把从库提升为主库。但主从库之间的数据一致性不能保证，所以就会利用 percona-toolkit 工具集中的 pt-table-checksum 工具来检查主从数据的一致性，然后再通过 pt-table-sync工具来修复不一致的数据信息。
pt-table-checksum工具介绍：
该工具的原理就是针对某张表中的所有字段，进行 hash 函数运算，在主库上运算后，把得到的值记录为master_crc、master_cnt。在从库上运算后，把得到的值记录为 this_crc、this_cnt。
最后，通过比较从库 this 的值和主库 master 的值来判断主从之间的数据一致性。
MySQL集群架构
MySQL的集群架构有：MHA、MM、PXC、Proxy、MGR……
一、MHA
MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案，它由日本 DeNA 公司的 youshimaton（现就职于 Facebook 公司）开发，是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。
MHA的目的在于维持MySQL Replication 中master库的高可用性，其最大特点是可以修复多个slave之间的差异日志，最终使所有slave保持数据一致，然后从中选择一个充当新的master，并将其他slave指向它。
当master出现故障时，可以通过对比slave之间 I/O thread 读取主库 binlog的position号，选取最接近的slave作为备选主库。其他的从库可以通过与备选主库对比生成差异的中继日志。在备选主库上应用从原来master保存的binlog，同时将备选主库提升为master。最后在其他slave上应用相应的差异中继日志，并从新的master开始复制。
MHA优缺点：
优点
（1）故障切换时，可以自行判断哪个从库与主库的数据最接近，然后切换到上面，可以减少数据的丢失，保证数据的一致性。
（2）支持binlog server，可提高binlog的传送效率，进一步减少数据丢失的风险。
（3）结合MySQL5.7的增强半同步功能，确保故障切换时数据不丢失。
缺点
（1）自动切换的脚本比较简单，而且比较老旧，后期需要逐步完善。
（2）搭建MHA架构，需要开启Linux系统互信协议，所以对于系统安全性来说是个不小的考验。
二、MM+keepalived
Keepalived 是基于VRRP协议的，Keepalived利用VRRP协议可以去实现MySQL高可用集群方案，避免单点故障。
两台互为主备的MySQL服务器运行Keepalived，master会向backup节点发送广播信号，当backup节点接收不到master发送的VRRP包时，会认为master宕机，这时会根据VRRP的优先级来选举出一个backup来充当master，则这个master就会持有vip（vip是对外应用连接的IP地址），从而保证了线上现有业务的正常运行，高可用性完美地展现出来。
注：在云平台环境下，此架构不能搭建。因为VRRP协议会被禁用。
三、PXC
PXC是基于Galera协议集成了Galera插件的MySQL高可用集群架构。具有高可用性，方便扩展，并且可以实现多个MySQL节点间的数据同步复制与读写，可保障数据库的服务高可用及数据强一致性。
基于Galera的高可用方案主要有MaridDB Galera Cluster和Percona XtraDB Cluster，简称PXC。目前PXC架构在生产环境中用得更多且更成熟一些。
PXC属于一套近乎完美的MySQL高可用集群解决方案，相比那些比较传统的基于主从复制模式的集群架构，如MHA、MM。该集群最突出的特点就是解决了诟病已久的数据复制延迟问题，基本上可以达到实时同步。而且节点间相互关系是对等的。本身该架构也是一种多主架构。
PXC架构优缺点
优点：
- 实现MySQL数据库集群架构的高可用性和数据的强一致性。
- 完成了真正的多节点读写的集群方案。
- 改善了传统意义上的主从复制延迟的问题，基本上达到了实时同步。
- 新加入的节点可以自动部署，无须提供手动备份，维护起来很方便。
- 由于是多节点写入，所以数据库故障切换很容易。
缺点：
- 新加入的节点开销大，需要复制完整的数据。采用SST传输开销大。
- 任何更新事务都需要全局验证通过，才会在每个节点库上执行。集群性能受限于性能最差的节点，也就是经常说的短板效应。
- 因为需要保证数据的一致性，所以在多节点并发写时，锁冲突问题比较严重。
- 存在写扩大问题，所有的节点上都会发生写操作。
- 只支持InnoDB存储引擎表。
- 没有表级别的锁定，执行DDL语句操作会把整个集群锁住，而且也“kill”不了（注：建议使用OSC操作）。
- 所有的表必须含有主键，不然操作数据时会报错。
四、Proxy
ProxySQL是MySQL的一款中间件产品，是灵活强大的MySQL代理层。可以实现读写分离，支持Query路由功能，支持动态指定某个SQL进行cache，支持动态加载配置、故障切换和一些SQL的过滤功能。同类产品有DBproxy、MyCAT、OneProxy等，综合考量，ProxySQL性能更好。
MySQL优化
MySQL的性能由多方面因素决定，优化也要从整体来优化：
- 程序设计：数据库、表设计，SQL语句的正确书写。
- Linux操作系统：IO调度，Linux内核参数。
- MySQL数据库：配置参数，数据库架构
- 硬件设备：服务器CPU、内存、IO、BIOS、RAID级别。
监控
利用市面上的数据库监控系统，对数据库进行全面监控，查看各种实时性能指标，并且对监控数据进行统计分析。在数据库出现故障或者潜在性能问题时，根据用户设置及时将数据库的异常进行报警，通知相应数据库管理员进行处理和优化，及时发现性能和瓶颈，避免由数据库潜在问题造成直接经济损失。
2020年8月19日 完结
该笔记参考：51CTO学院—>《MySQL晋级之路》张甦