MySQL——运维篇

发布时间:2023年12月26日

三、运维篇🚩

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部分没有进行实操,笔记较略,实操之后会来补充
在这里插入图片描述

文章来源:https://blog.csdn.net/qq_44689664/article/details/135227890
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。