MySQL——运维篇

三、运维篇🚩

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部分没有进行实操，笔记较略，实操之后会来补充