MySQL常见故障汇总(一)

MySQL常见故障汇总(一)

文章目录

  • MySQL常见故障汇总(一)
    • 1.案例概述
    • 2.数据库逻辑架构图
    • 3.实验环境
    • 4.单库常见故障分析
      • 4.1故障现象1
      • 4.2故障现象2
      • 4.3故障现象3
      • 4.4故障现象4
      • 4.5故障现象5
      • 4.6故障现象6
      • 4.7故障现象7
      • 4.8故障现象8
    • 5.MySQL主从故障排查
      • 5.1故障现象1
      • 5.2故障现象2
      • 5.3故障现象3

1.案例概述

  • MySQL 是目前企业最常见的数据库之一,占用绝大部分市场份额。在日常维护管理的过程中相信大家肯定会遇到很多常见的故障,为了提高故障处理的及时性,本章案例将常见故 障进行汇总,加强学习经验。另外数据库的默认的配置无法满足高性能网站架构的需求,从 工作经验上总结 MySQL 数据库应该如何优化。

2.数据库逻辑架构图

MySQL常见故障汇总(一)_第1张图片

  • 最上层是一些客户端和连接服务,包含本地 sock 通信和大多数基于客户端/ 服务器端工具实现的类似于 tcp/ip 的通信。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念,为通过认证安全接入的客户端提供线程。 同样在该层上可以实现基于 SSL 的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
  • 第二层架构主要完成大多少的核心服务功能,如 SQL 接口,并完成缓存的查询,SQL 的分析和优化及部分内置函数的执行。所有跨存储引擎的功能也在这一层实现,如过程、函数 等。在该层,服务器会解析查询并创建相应的内部解析树,并对其完成相应的优化如确定查 询表的顺序,是否利用索引等,最后生成相应的执行操作。如果是 select 语句,服务器还会查询内部的缓存。如果缓存空间足够大,这样在解决大量读操作的环境中能够很好的提升 系统的性能。
  • 存储引擎层,存储引擎真正的负责了 MySQL 中数据的存储和提取,服务器通过 API 与存储引擎进行通信。不同的存储引擎具有的功能不同,这样我们可以根据自己的实际需要进行 选取。
  • 数据存储层,主要是将数据存储在运行于裸设备的文件系统之上,并完成与存储引擎的 交互。

3.实验环境

centos7(MySQL5.6),IP地址:192.168.73.10

centos7(MySQL5.6),IP地址:192.168.73.11

4.单库常见故障分析

4.1故障现象1

ERROR	2002	(HY000):	Can't	connect	to	local	MySQL	server	through	socket '/data/mysql/mysql.sock' (2)
  • 问题分析:
    • 以上这种情况一般都是数据库未启动或者数据库端口被防火墙拦截导致。
  • 解决方法:
    • 启动数据库或者防火墙开放数据库监听端口。

4.2故障现象2

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
  • 问题分析
    • 密码不正确或者没有权限访问。
  • 解决办法
1)修改 my.cnf 主配置文件,在[mysqld]下添加 skip-grant-tables,重启数据库。最后修改密码命令如下:
mysql> use mysql;
mysql> update user set password=password("123456") where user="root";
再删除刚刚添加的 skip-grant-tables 参数,再重启数据库,使用新密码即可登录。
2)重新授权,命令如下:
mysql> grant all on *.* to 'root'@'mysql-server' identified by '123456';

4.3故障现象3

  • 在使用远程连接数据库时偶尔会发生远程连接数据库很慢的问题。
  • 问题分析:
    • 如果 MySQL 主机查询 DNS 很慢或是有很多客户端主机时会导致连接很慢,由于开发机器是不能够连接外网的,所以 DNS 解析是不可能完成的,从而也就明白了为什么连接那么慢了。
  • 解决办法:
    • 修改 my.cnf 主配置文件,在[mysqld]下添加 skip-name-resolve,重启数据库可以解决。注意在以后授权里面不能再使用主机名授权。

4.4故障现象4

Can't open file: 'xxx_forums.MYI'. (errno: 145)
  • 问题分析

    • 1) 服务器非正常关机,数据库所在空间已满,或一些其它未知的原因,对数据库表造成了损坏。

    • 2) 可能是操作系统下直接将数据库文件拷贝移动会因为文件的属组问题而产生这个错

      误。

  • 解决办法:

    • 可以使用下面的两种方式修复数据表:(第一种方法仅适合独立主机用户)

    • 1 ) 使用 myisamchk , MySQL 自带了专门用户数据表检查和修复的工具 — — myisamchk 。一般情况下只有在这个下面才能运行 myisamchk 命令。常用的修复命令为: myisamchk -r 数据文件目录/数据表名.MYI;

    • 2)通过 phpMyAdmin 修复, phpMyAdmin 带有修复数据表的功能,进入到某一个表中后,点击“操作”,在下方的“表维护”中点击“修复表”即可。

      注意:以上两种修复方式在执行前一定要备份数据库。修改文件的属组(仅适合独立主机用户):

      复制数据库文件的过程中没有将数据库文件设置为 MySQL 运行的帐号可读写(一般适用于 Linux 和 FreeBSD 用户)。

4.5故障现象5

ERROR 1129 (HY000): Host 'xxx.xxx.xxx.xxx' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'
  • 问题分析
    • 由于 mysql 数据库的参数:max_connect_errors(系统默认 10) mysqld 已经得到了大量(max_connect_errors)的主机’hostname’的在中途被中断了的连接请求累计超过 10 次, 就再也无法连接上 mysqld 服务,同一个 ip 在短时间内产生太多中断的数据库连接而导致的阻塞(超过 mysql 数据库 max_connection_errors 的最大值)。
  • 解决办法
1)使用 mysqladmin flush-hosts 命令清除缓存,命令执行方法如下:
mysqladmin -uroot -p -h 192.168.241.48 flush-hosts Enter password:
2)修改 mysql 配置文件,在[mysqld]下面添加 max_connect_errors=1000,然后重启MySQL。

4.6故障现象6

客户端报 Too many connections
  • 问题分析
    • 连接数超出 Mysql 的最大连接限制。
  • 解决办法
1)在 my.cnf 配置文件里面增加连接数,然后重启 MySQL 服务。
max_connections = 10000
2)临时修改最大连接数,重启后不生效。需要在 my.cnf 里面修改配置文件,下次重启生效。
set GLOBAL max_connections=10000;

4.7故障现象7

Warning: World-writable config file '/etc/my.cnf' is ignored ERROR! MySQL is running but PID file could not be found
  • 问题分析
    • mysql的配置文件/etc/my.cnf权限不对
  • 解决办法
chmod 644 /et/my.cnf

4.8故障现象8

InnoDB: Error: page 14178 log sequence number 29455369832
InnoDB: is in the future! Current system log sequence number 29455369832
  • 问题分析
    • InnoDB数据文件损坏
  • 解决办法
修改 my.cnf 配置文件,在[mysqld]下添加 innodb_force_recovery=4, 启动数据库后备份数据文件,然后去掉该参数,利用备份文件恢复数据。

5.MySQL主从故障排查

5.1故障现象1

从库的 Slave_IO_Running 为 NO
The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).
  • 问题分析
    • 主库和从库的 server-id 值一样
  • 解决办法
    • 修改从库的 server-id 的值,修改为和主库不一样,比主库低。修改完后重启,再同步即可

5.2故障现象2

从库的 Slave_IO_Running 为 NO
  • 问题分析
  • 造成从库线程为 NO 的原因会有很多,主要原因是主键冲突或者主库删除或更新数据, 从库找不到记录,数据被修改导致。通常状态码报错有 1007、1032、1062、1452 等。
  • 解决方法
解决方法一:
mysql> stop slave;
mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
mysql> start slave;
解决方法二:
设置用户权限,设置从库只读权限
set global read_only=true;

5.3故障现象3

Error initializing relay log position: I/O error reading the header from the binary log
  • 分析问题
    • 从库的中继日志 relay-bin 损坏.
  • 解决办法
手工修复,重新找到同步的 binlog 和 pos 点,然后重新同步即可。
mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.xxx',MASTER_LOG_POS=xxx;

你可能感兴趣的:(面试干货,mysql)