一、Mysql单例数据库架构
1、Mysql体系介绍
- 网络连接层：提供与Mysql服务器建立连接的支持
- 核心服务层：主要包含系统管理和控制工具、连接池、SQL接口、解析器、查询优化器和缓存六个部分
- 存储引擎：负责Mysql中数据的存储与提取，与底层系统文件进行交互
- 文件系统：负责将数据库的数据和日志存储在文件系统之上，并完成与存储引擎的交互，是文件的物理存储层
2、SQL运行过程
3、InnoDB内存和存储结构
优势：擅长处理事务，具有自动崩溃恢复的特性
内存结构：内存结构主要包括Buffer pool、Change Buffer、Adaptive Hash Index和Log Buffer四大组件
* 内存Page：Free Page、Clean Page(真正的缓存)、Dirty Page
* 链表管理：Free List、Flush List、LRU List
存储结构：InnoDB磁盘主要包含Tablespaces、InnoDB Data Dictionary、Doublewrite Buffer、Redo Log和Undo Logs
(1)Buffer pool
- 缓冲池(buffer pool)是一种常见的降低磁盘访问的机制，在MySQL启动的时候，向操作系统申请的一片连续的内存空间，然后按照默认的16kb(操作系统的页4KB)划分为一个个的缓存页，此时这些缓存页是空闲的，随着程序的运行才会有磁盘上的页被缓存到Bufffer Pool中。默认配置下Buffer Pool只有128MB
- 缓冲池通常以页(page)为单位缓存数据，InnoDB会把存储的数据划分为若干个页，以页作为磁盘和内存交互的基本单位，一个页的默认大小为16KB。每个缓存页都会创建一个控制块，控制块包括缓存页的表空间、页号、缓存页地址、链表节点等
(2)Change Buffer
是一个提高INSERT、DELETE、UPDATE等写时效率的写缓存。应用在非唯一普通索引页(唯一索引必须进行唯一性检查，需要读取磁盘)、不在缓冲池中(在缓存池中则直接修改缓存池中的页)、对页进行了写操作，并不会立刻将磁盘页加载到缓冲池，而仅仅记录缓冲变更(Buffer Change)，等未来数据被读取时，再将数据合并恢复到缓冲池的技术。写缓冲的目的是降低写操作的磁盘IO，提升数据库性能。
(3)Binlog
用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中，由Server层进行记录。使用场景分别是主从复制和数据恢复。日志格式包含三种
STATMENT：基于sql语句的复制，每一条会修改数据的sql语句会记录到binlog中(缺点：更新时使用sysdate)
ROW：基于行的复制，记录哪条数据被修改的信息
MIXED：基于STATMENT和ROW两种模式的混合复制
(4)Redo log
用于解决数据库事务提交还未刷入磁盘，服务器down机导致的数据丢失问题。记录事务对数据页做了哪些修改，不去直接刷新磁盘。包括两个部分，一个是内存中的日志缓冲(redo log buffer)，另一个是磁盘上的日志文件(redo log file)。mysql每执行一条DML语句，先将记录写入redo log buffer，后续某个时间点再一次性将多个操作记录写到redo log file。这种先写日志，再写磁盘的技术就是WAL(Write-Ahead Logging)技术。
因为redo log是InnoDB特有的，且日志上的记录落盘后会被覆盖掉。因此需要binlog和redo log二者同时记录，才能保证当数据库发生宕机重启时，数据不会丢失。
(5)Undo log
实现MVCC和事务回滚，undo日志版本链是指一行数据被多个事务依次修改过后，在每个事务修改完后，Mysql会保留修改前的数据undo回滚日志，并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链。
(6)Free List(空闲链表)
为了标记哪些页是空闲页，将空闲缓存页的控制块作为链表的节点，串起来形式Free链表。当需要从磁盘中加载一个页到Buffer Pool中时，就从Free链表中取出一个空闲的缓存页，并且把该缓存页对应的控制块的信息填上，然后把该缓存页对应的控制块从Free链表中移除
(7)Flush List
更新数据时，不需要每次写入磁盘，而是将Buffer Pool对应的缓存页标记为脏页，然后再由后台线程将脏页写入到磁盘。为了知道哪些缓存页是脏的，于是有了Flush链表，与Free链表类似，区别在于Flush链表的元素都是脏页.
InnoDB更新操作采用的是Write Ahead Log策略，即先写日志，再写入磁盘，通过redo log日志让MySQL拥有了崩溃恢复能力。
(8)LRU List
- 缓冲池的常见管理算法是LRU，memcache，OS，InnoDB都使用了这种算法
- InnoDB对普通LRU进行了优化
- 将缓冲池分为老生代和新生代，入缓冲池的页，优先进入老生代，页被访问，才进入新生代，以解决预读失效的问题
- 页被访问，且在老生代停留时间超过配置阈值的，才进入新生代，以解决批量数据访问，大量热数据淘汰的问题
4、TableSpace
Segment：数据段、索引段、回滚段
Extent：一个段包含多个区、一个区包含64个页
Page：一个页包含多条记录
Row：用户写入的实际数据5、Page
- File Header：主要包含FIL_PAGE_PREV、FIL_PAGE_NEXT一页指针和下一页指针(页在磁盘上的偏移量)
- Page Header：标记记录位置和UserRecords统计
- Infimum&Supremum Records：描述是最小的记录和最大记录的开区间
- Free Space：UserRecords和Free、不够申请新的页
- Page Directoy：每写入一定数量Records作为一个Slot，在定位到Page后根据slot提升查找性能
- File Trailer：低4位Checksum、高4位和File Header的LSN一致
6、InnoDB线程模型
- IO Thread：大量AIO读写处理，提高数据库性能(Read Thread、Write Thread、Log Thread、Insert Buffer Thread)
- Purge Thread：事务提交后，其使用的Undo日志将不再需要，因此需要Purge Thread回收Undo日志
- Page Cleaner Thread：将脏数据刷新到磁盘，脏数据刷盘后相应的Redo Log也就可以覆盖，即可以同步数据，又能达到Redo Log循环使用的目的，会调用Write Thread线程处理
- Master Thread：负责调度其他各线程，优先级最高，作用是将缓冲池中的数据异步刷新到磁盘，保证数据一致性。包含：脏页的刷新、Undo页回收、Redo日志刷新、合并写缓冲等
7、备份机制
- 传统备份
- MySQLDump逻辑全备+逻辑Binlog日志
- XtraBackup物理全备(Copy文件+Redo增量)+逻辑Binlog日志
- 快照备份
- 基于ECS云盘快照+逻辑Binlog日志
二、Mysql数据复制
1、Mysql数据复制原理
- Binlog：主备复制基于Binlog日志
- Dump Thread：为每个Slave的I/O Thread启动一个Dump线程，用于向其发送Binary Log Events
- I/O Thread：向Master请求二进制日志事件，并保存于中继日志中
- SQL Thread：从中继日志中读取日志事件，在本地完成重放
2、Mysql复制架构
3、Mysql复制模式
三、Mysql高可用及进阶
1、Mysql高可用原理
2、Keepalived架构
- 背景：业界传统高可用方案
- Core：keepalived的核心，负责主进程的启动和维护，全局配置文件的加载解析
- Check：负责HealthChecker，包括了各种健康检查方式，以及对应的配置的解析包括LVS的配置解析；可基于脚本检查对IPVS后端服务器健康状况进行检查
- VRRP：VRRP进行通信，通过竞选机制确定主备，主优先级高于备，主会一直发送VRRP广播包，告诉备它还活着，此时备不会抢占主，当主不可用时(即备监听不到主发送的广播包)，备会启动相关服务接管资源，保证业务连续性。但无法进行第三方仲裁、会出现脑裂情况
3、MHA架构
- MHA背景：业界方案
- MHA组成：包括Manager节点和Node节点，管理节点一般独占机器，Node节点一般和每台MySQL Server在一起
- MHA工作原理：Node节点通过解析各MySQL日志来进行一些操作，Manager节点将和每个Node节点通信，判断其Node上的MySQL是否正常。若发现故障，则直接把它的Slave提升为Master，其他的Slave都挂到新Master上，此过程对用户透明
4、MGR架构
- 特性：核心解决异步复制和半同步复制数据一致性问题，可保证实物不丢失
- 多数派：基于Paxos协议，若干节点组成复制组，一个事务发起提交，必须经过半数节点以上的决议通过，才可正常提交
- 集群模式
- 多主：客户端可随机向MySQL节点写入数据
- 单主：集群选出新主节点提供写，源主和其他节点提供读
