Mysql管理

记录了客户端从会话连接开始，执行过的所有SQL语句信息；

默认日志功能处于关闭，建议在需要做调试工作时（功能测试、语句审计）可以打开；

记录了数据库服务启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息；

默认处于激活状态

记录了所有的DDL语句和DML语句，但是不包括数据库查询语句；
语句以事件的形式保存，描述了数据的更改过程，此日志对于灾难时的数据恢复起着极其重要的作用。

默认处于激活状态

GTID

记录了所有执行时间超过参数long_query_time设置值
并且扫描记录数小于min_examined_row_limit的所有SQL语句的日志

默认处于关闭状态，实际使用当中应当开启。

• 可以在任意时间节点在不停机不停止业务时，然后利用专业的mysqldump(MDP)逻辑备份工具进行数据备份；
• 可以在任意时间节点在不停机不停止业务时，然后利用二进制日志binlog文件实现逻辑备份数据操作；
• 可以在任意时间节点在不停机不停止业务时，然后利用主从数据库架构实现备份数据信息；
  

当企业数据库服务产生的需要备份的数据量在50G以内，可以选择逻辑备份（mysqldump）
当企业数据库服务产生的需要备份的数据量在50G以上，可以选择物理备份（xtrabackup）；

冷备份其实就是停掉数据库服务，cp数据文件的方法；这种方法对MyISAM和InnoDB存储引擎都合适，但是一般很少使用；

MyISAM

InnoDB

启动克隆操作的MySQL数据库服务器实例中的数据，将会克隆到同服务器或同节点上的一个目录里；

本地克隆步骤

1. 加载克隆插件信息
2. 创建克隆专用用户
3. 进行本地克隆操作
4. 观测本地克隆状态（另开窗口使用管理员用户查看）
5. 实现克隆日志观测
6. 启动运行克隆实例

默认情况下，远程克隆操作会删除接受者（recipient）数据目录中的数据，并将其替换为捐赠者（donor）的克隆数据；
主要用于实现数据远程的快速热迁移操作，在迁移过程中，除了DDL操作情况，其他操作都不会出现阻塞情况；
还可以利用远程克隆技术，实现快速构建数据库的主从架构环境，实现主从数据信息快速复制同步；

步骤

在进行数据库克隆操作时，会经历几个重要的过程或步骤：
01 Page copy：
02 Redo copy：
03 Done：

对于不同版本的MySQL数据库实例之间，是不能进行克隆操作的。对于捐赠者和接受者必须是确切相同数据库服务版本；

整个克隆过程都会以事件信息记录，可以很清晰的看到克隆的流程，如果克隆过程中断，也会以追加方式进行继续克隆；

MySQL复制的优点主要包含以下3个方面：

1. 如果主库出现问题，可以快速切换到从库提供服务；
2. 可以在从库上执行查询操作，降低主库的访问压力；
3. 可以在从库上执行备份操作，以避免备份期间影响主库的服务；

主从复制的原理
1.在进行主从数据复制时，是依靠相应线程信息来完成数据复制同步操作的；

• 主库涉及线程binlog dump thread；
• 从库涉及线程slave IO thread，slave SQL thread；
• 如果是一主多从的架构，将会看见多个binlog dump线程信息，实现对多个从库的日志信息投递；

2.在进行主从数据复制时，是依靠相应文件信息来完成数据复制过程中的数据保存的；

• 主库涉及文件binlog；
• 从库涉及文件relaylog，master.info，relay-log.info；

复制原理过程详述：

1. 在从库上执行change master to命令，将主库连接信息和binlog位置信息写入master.info文件或 slave_master_info表中；
2. 在从库上执行start slave命令，用于启动从库的IO和SQL线程功能；
3. 从库IO线程主要用于读取主库连接信息，实现和主库建立连接，从而使主库派生出binlog dump线程（自动监控binlog）；
4. 从库IO线程根据change master to命令所定义的数据位置点，获取最新的binlog日志信息
5. mysql主库在事务提交时会把数据变更为事件Events记录在二进制日志文件binlog中；
6. mysql主库上的sync_binlog参数控制binlog日志刷新到磁盘；
7. binlog dump线程会截取binlog日志并投递其日志给从库IO线程，此时主库并不关心投递日志信息的结果；
8. 此时从库IO线程接收binlog投递信息（缓存），随之会立即更新master.info文件 或 slave_master_info数据表信息；
9. 从库缓存的binlog日志数据信息会被写入到relaylog中继日志中；
10. 主库推送二进制日志文件binlog中的事件到从库的中继日志relay log，之后从库根据中继日志relay log重做数据变更操作，
11. 从库SQL线程将会读取relaylog.info文件或者slave_relay_log_info数据表中信息，获取上次数据回放同步位置点；
12. 随之继续向后回放同步数据，一旦回放同步数据完成后，再次更新relay.info或slave_relay_log_info数据表信息；
13. 在从库中回放过的relaylog日志信息，会被relay_log_purge线程定期删除处理这些日志；
14. 通过逻辑复制以此来达到主库和从库的数据一致；

概述

过程跟主从复制一样，多了一条命令：change master to master_delay=300;

概述

概述

准备两个主机设备（可以利用两个实例）
在主库上创建复制用户
进行主库全备操作/从库进行全备操作
从库上定义连接主库的配置信息
进行主从关联检查测试

概念

原理机制

构建过程

概念

概念

概念

作用

单主模式

多主模式

应用限制说明

读写分离

概念

概念

1. 构建GTID主从关系
2. 创建程序命令软链接
3. 配置各节点互信
4. 安装软件程序
5. 在db01主库中创建mha需要的用户
6. Manager配置文件准备(db03)
7. MHA状态检查（db03）
8. 开启MHA-manager
9. 查看MHA状态

① 如何在高可用架构中，当主库宕机异常后，使之及时的发现主库服务程序产生了运行异常？
      解决此痛点问题，需要实现高可用的监控需求；
    ② 如何在高可用架构中，当主库宕机异常后，可以找到可以替代主库的服务器主机进行切换？ 
      解决此痛点问题，需要实现高可用的选主功能；（并且选择数据量越接近主库的从库成为新主）
    ③ 如何在高可用架构中，当主库宕机异常后，新的主库接管后可以保证与原有主库数据一致   
      解决此痛点问题，需要实现高可用的数据补偿；
    ④ 如何在高可用架构中，当主库宕机异常后，将应用程序的读写请求对接切换到新的主库上？ 
      解决此痛点问题，需要实现高可用的应用透明；（VIP技术） 
    ⑤ 如何在高可用架构中，当主库宕机异常后，能够及时向管理员发起告知提醒使之进行修复？(MHA切换是一次性的) 
      解决此痛点问题，需要实现高可用的报警功能；
    ⑥ 如何在高可用架构中，当主库宕机异常后，当整体主库系统环境都异常时实现数据的补偿？
      解决此痛点问题，需要实现高可用的额外补偿；
    ⑦ 如何在高可用架构中，当主库宕机异常后，根据主库服务器的异常情况进行原有主库修复？   
      解决此痛点问题，需要实现高可用的自愈功能；（待开发，只有云平台RDS具有此功能）

01 MHA软件启动

02 MHA实现监控

03 MHA选主原理

04 MHA数据补偿

05 MHA业务切换（主从关系切换）

06 MHA应用透明

MHA健康检查报错，显示主数据库节点无法正常连接
MHA进行重新选主，根据数组信息选择合适的备用新主节点
MHA进行节点关闭，选择完新的主节点后会将原有主节点的VIP地址消除
MHA进行节点切换，在新的主节点上进行非同步数据信息的补偿
MHA进行主从重构，将从库连接到新的主库上
MHA切换完毕过程，架构故障转移切换完毕后做清理阶段，并进行最终汇报

概念

proxySQL

负责管理数据库的基础数据（不会对表的内容修改），比如增删库、增删表、增删索引、增删用户等；

CREATE（创建）、ALTER（修改）、DROP（删除）等；

主要用来定义访问权限和安全级别

GRANT（用户授权）、REVOKE（权限回收）、COMMIT（提交）、ROLLBACK（回滚）

主要针对数据库里的表里的数据进行操作，用来定义数据库记录（数据）

SELECT（查）、INSERT（增）、DELETE（删）、UPDATE（改）

主要用来查询记录（数据）

SELECT（查）

聚簇索引主要是：将多个簇（区-64个数据页-1M）聚集在一起就构成了所谓聚簇索引，也可以称之为主键索引；
聚簇索引作用是：用来组织存储表的数据行信息的，也可以理解为数据行信息都是按照聚簇索引结构进行存储的，即按区分配空间的；
聚簇索引的存储：聚簇是多个簇，簇是多个连续数据页(64个)，页是多个连续数据块(4个)，块是多个连续扇区(8个)；

构建方式

辅助索引主要是：主要用于辅助聚簇索引查询的索引，一般按照业务查找条件，建立合理的索引信息，也可以称之为一般索引；
辅助索引作用是：主要是将需要查询的列信息可以和聚合索引信息建立有效的关联，从而使数据查询过程更高效，节省IO和CPU消耗
辅助索引的存储：调取需要建立的辅助索引列信息，并加上相应主键列的所有信息，存储在特定的数据页中；

构建方式

执行计划就是最优的一种执行SQL语句的方案，表示相应SQL语句是如何完成的数据查询与过滤，以及获取；

可以利用命令进行获取执行计划信息：explain/desc
desc select * from oldboy.t100w where k2='VWlm';

1. ALL - ok 表示全表扫描方式，没用利用索引扫描类型；
2. index 表示全索引扫描方式，需要将索引树全部遍历，才能获取查询的信息（主键index=全表扫描）
3. range 表示范围索引方式，按照索引的区域范围扫描数据，获取查询的数据信息；
4. ref 表示辅助索引等值（常量）查询，精准定义辅助索引的查询条件
5. eq_ref 表示多表连接查询时，被驱动表的连接条件是主键或者唯一键时，获取的数据信息过程；
6. const/system 表示主键或者唯一键等值（常量）查询，精准定义索引的查询条件

在执行计划列中，key_len主要用来判断联合索引覆盖长度（字节），当覆盖长度越长，就表示匹配度更高，回表查询的次数越少；
到底联合索引被覆盖了多少，是可以通过key_len计算出来；

联合索引可以优化表中多列信息的查询，当需要多列信息查询时最好应用联合索引，不要应用多个单列索引；
在进行联合索引应用设置时，也是需要满足一定规范要求的，即使建立的联合索引，可能某些情况下，联合索引也不能大部分被使用；
因此，建立了联合索引，肯定是希望联合索引走的越多越好，但也有可能联合索引建立存在问题，也会导致查询效率较低；

联合索引建立异常分析思路

联合索引应用要遵循最左原则

Extar列表示额外的情况或额外的信息说明，其中重点需要关注点信息为：filesort 表示涉及到额外排序操作，将严重浪费CPU资源；

哪些查询语句情况涉及到排序操作：

情况一：查询语句中含有 order by ，表示触发式的排序；
情况二：查询语句中含有 group by，表示隐藏式的排序；
情况三：查询语句中含有 DISTINCT，表示会先进行排序后再取消重复；

建立索引原则规范（DBA运维规范）

索引应用失效情况（开发工作规范

查询结果规范要求

索引失效情况处理

数据库服务索引功能特性

数据库服务自主优化能力

InnoBD支持：事务、mvcc、聚簇索引、外键、缓冲区、AHI、DW；MyISAM均不支持

InnoDB支持：行级锁，MyISAM只支持表级锁

InnoDB支持：数据热备，可以保证业务正常运行，对业务影响低，MyISAM只支持温备份，需要锁表备份；

InnoDB支持：支持CR自动故障恢复，宕机自动恢复，数据安全和一致性可以得到保证；MyISAM不支持，宕机可能丢失当前数据

1. 8.0版本默认都是innoDB
   
   

共享(系统)表空间

独立表空间

undo表空间

temp表空间

redo事务日志

缓存服务主从复制原理
- Redis缓存的服务主从复制功能又称为主副本集(Master-Replicaset)，具体实现原理如下:
- 副本库通过slaveof192.168.30.1016379命令，连接到主库缓存服务，并发送SYNC给主库:
- 主库收到SYNC数据后，会立即触发BGSAVE，在后台保存RDB信息，并发送给副本库:
- 副本库接收后会应用RDB快照信息;
- ·主库会陆续将中间产生的新操作数据，保存并发送给副本库，至此主复制集就正常工作了
- 后面应用过程中，主库只要发生新的操作，都会以命令传输的形式自动发送给副本库;
- 所有复制相关的信息，从info信息中都可以查到，即使重启任何节点，它的主从关系依然都在;
- 如果发生主从关系断开时，从库数据没有任何损坏，在下一次重连之后，从库发送PSYNC给主库:
- 主库只会将从库缺失部分的数据同步给从库应用，达到快速恢复主从的目的;