三、运维篇🚩
1. 日志🍻
1.1 错误日志
错误日志记录了当mysql启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。——数据库无法正常使用时，使用该日志
# 可以查看错误日志存放的位置
show variables like '%log_error%';
Linux中使用：tail -f 文件名——>查看错误日志追加的内容
-f 实时刷新尾部的内容
1.2 二进制日志
二进制日志（binary log， BINLOG）记录了所有的DDL和DML语句，但不包括数据查询（记录数据库、表、表中数据的变更）
作用：
- 灾难时的数据恢复
- MySQL的主从复制
# 查看binlog的位置
show variables like '%log_bin%';
/*
日志格式
1. STATEMENT：记录的是SQL语句，对数据修改的SQL都会记录在日志文件中
2. ROW：记录的是每一行的数据变更（默认）
3. MIXED：上面两种格式的混合，默认采用STATEMENT，某些特殊情况下会自动切换成ROW进行记录
*/
# 查看
show variables like '%binlog_format%';
# 删除
reset master # 删除全部binlog日志，删除之后编号从binlog.000001重新开始
purge master logs to "binlog.******" # 删除******编号之前的所有日志
purge master logs before '日期' # 删除这个日期之前产生的所有日志
# 在配置文件中设置过期时间，设置了之后，二进制日志过期就会自动删除
show variables like '%binlog_expire_logs_seconds%'； # 默认30天
1.3 查询日志
记录客户端的是所有操作语句，默认是未开启的
如果想要开启，要进行配置
# 查看
show variables like '%general%';
/*
general_log,OFF
general_log_file,/var/lib/mysql/VM-4-13-ubuntu.log
*/
1.4 慢查询日志
记录所有执行时间超过long_query_time设置值并且扫描记录数不小于min_examined_row_limit的所有的SQL语句的日志，默认是未开启的。
# 开启慢查询日志
slow_query_log = 1
# 执行时间参数，默认是10秒，最小是0，精度可以到微秒
long_query_time = 2
# 默认情况下，不会记录管理语句，也不会记录不使用索引进行查找的查询
# 开启记录执行较慢的管理语句
log_slow_admin_statements = 1;
# 开启记录执行较慢的未使用索引的语句
log_queries_not_using_indexes = 1;
2. 主从复制🍷
2.1 概述
涉及主库（Master）和从库（Slave），主数据库的DDL和DML操作通过二进制日志传到从数据库（可以是多个），然后在从库上对这些日志重新执行（重做），从而使得从库和主库的数据保持同步。
注： MySQL支持一台主库同时向多台从库进行复制，从库同时也可以作为其他从服务器的主库，实现链状复制
优点：
- 主库出现问题，可以快速切换到从库提供服务——>避免崩溃
- 实现读写分离，降低主库的访问压力——>分工合作
- 可以在从库上执行备份，以避免备份期间影响主库服务——>备份恢复
2.2 原理
2.3 搭建
1）主从复制的服务器环境
- 关闭防火墙/指定端口
- 检查mysql的运行状态
2）主库配置
①修改配置文件
②重启mysql
③登录mysql，创建远程连接的账号，并授予主从复制的权限
CREATE USER 'username'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'username'@'%';
④找到要从哪里开始复制——二进制文件的坐标
show master status;
/*
file：从哪个日志文件开始推送日志文件
position：从哪个位置开始推送日志
binlog_ignore_db：指定不需要同步的数据库
*/
3）从库配置
①修改配置文件
②重启数据库
③设置主库的相关配置——让机器之间能够互相联系起来
④开启同步操作
# 8.0.22之后
start replic;
# 8.0.22之前
start slave;
⑤查看主从复制的状态
show replic status;
# IO running
# SQL running
3. 分库分表🍸
3.1 介绍
问题： 应用系统的数据量成指数式增长，如果采用单数据库进行数据存储，会存在性能瓶瓶
- IO瓶颈：数据量大，缓存不足，产生大量磁盘IO，效率较低。请求数据太多，带宽不够，网络IO瓶颈
- CPU瓶颈：排序、分组、连接查询、聚合统计等SQL会耗费大量的CPU资源，请求数太多，CPU瓶颈
将单数据库的数据分散到多态数据库服务器中，实现负载均衡
这么复杂，应用程序咋操作嘞？
- shardingJDBC：基于AOP原理（面向切片编程），在应用程序中对本地执行的SQL进行拦截，解析、改写、路由处理。需要自行编码配置实现，只支持JAVA语言，性能较高
- Mycat：数据库分库分表的中间件（应用程序无感知的），不用调整代码就可以实现分库分表，支持多种语言，性能不及前者
3.2 Mycat概述
概念： 数据库中间件，可以像使用mysql一样来使用mycat（伪装协议），对开发人员来说根本感觉不到mycat的存在
优势：
- 性能可靠稳定
- 强大的技术团队
- 体系完善
- 社区活跃
学完docker再回来实操吧
3.3 Mycat入门
3.4 Mycat配置
1）schema.xml：涵盖MyCat的逻辑库、逻辑表、分片规则、分片节点及数据源配置
主要包含以下三组标签
- schema标签：逻辑库、逻辑表
- datanode标签：数据节点
- datahost标签：接待你主机以及数据源的相关信息
2）rule.xml：定义了所有拆分表的规则，在使用过程中可以灵活使用分片算法，或者对同一个分片算法使用不同的参数，这一配置文件使分片过程可配置化
主要包含以下两组标签
- tableRule：根据哪个字段进行分片，当前分片规则指定的分片算法，是个引用
- Function：具体的算法的实现方法
3）server.xml：配置文件包含了MyCat的系统配置信息
主要包含两个标签
- system：对应系统配置项及其含义，环境选项
- user：能被哪些用户访问（用户及其权限0000-增改查删）
3.5 Mycat分片
3.6 Mycat管理及监控
可视化——Mycat-web/eye+zookeeper
4. 读写分离🍹
4.1 介绍
把对数据库的读和写操作分开，以应对不同的数据库服务器。主数据库是提供写操作，从数据库是提供读操作——>减轻单台数据库的压力
客户端直接实现会很繁琐，可以使用Mycat中间件
writeHost
readHost
4.2 一主一从
4.3 一主一从读写分离
4.4 双主双从
高可用
4.5 双主双从读写分离
总结
Mycat部分没有进行实操，笔记较略，实操之后会来补充
