MySQL之数据库维护

1 数据库维护

数据库维护是运维工程师或者DBA主要工作,包括性能监控、性能分析、性能调优、数据库备份和恢复等。

1.1 数据库文件

MySQL的每个数据库都对应存放在一个与数据库同名的文件夹中,MySQL数据库文件包括MySQL所建数据库文件和MySQL所用存储引擎创建的数据库文件。

1.1.1 MySQL创建并管理的数据库文件

.frm文件:存储数据表的框架结构,文件名与表名相同,每个表对应一个同名frm文件,与操作系统和存储引擎无关,即不管MySQL运行在何种操作系统上,使用何种存储引擎,都有这个文件。
除了必有的.frm文件,根据MySQL所使用的存储引擎的不同(MySQL常用的两个存储引擎是MyISAM和InnoDB),存储引擎会创建各自不同的数据库文件

MyISAM数据库表文件:

  • .MYD文件:即MY Data,表数据文件
  • .MYI文件:即MY Index,索引文件
  • .log文件:日志文件

InnoDB采用表空间(tablespace)来管理数据,存储表数据和索引,InnoDB数据库文件(即InnoDB文件集,ib-file set):

  • ibdata1、ibdata2等:系统表空间文件,存储InnoDB系统信息和用户数据库表数据和索引,所有表共用
  • .ibd文件:单表表空间文件,每个表使用一个表空间文件(file per table),存放用户数据库表数据和索引
  • 日志文件: ib_logfile1、ib_logfile2

1.1.2 MySQL数据库存放位置

MySQL如果使用MyISAM存储引擎,数据库文件类型就包括.frm、.MYD、.MYI,默认存放位置是C:\Documentsand Settings\All Users\Application Data\MySQL\MySQL Server 5.1\data

MySQL如果使用InnoDB存储引擎,数据库文件类型就包括.frm、ibdata1、.ibd.frm.ibd文件默认存放位置是MySQL安装目录下的data文件夹

1.2 性能状态关键指标QPS和TPS

QPSQueries Per Second:每秒查询数,一台数据库每秒能够处理的查询次数
TPSTransactions Per Second:每秒处理事务数
通过show status查看运行状态,会有300多条状态信息记录,其中有几个值帮可以我们计算出QPS和TPS,如下:

  • Uptime:服务器已经运行的实际,单位秒
  • Questions:已经发送给数据库查询数
  • Com_select:查询次数,实际操作数据库的
  • Com_insert:插入次数
  • Com_delete:删除次数
  • Com_update:更新次数
  • Com_commit:事务次数
  • Com_rollback:回滚次数

那么,计算方法来了,基于Questions计算出QPS

mysql> show global status like 'Questions';
mysql> show global status like 'Uptime';
QPS = Questions / Uptime

基于Com_commitCom_rollback计算出TPS:

mysql> show global status like 'Com_commit';
mysql> show global status like 'Com_rollback';
mysql> show global status like 'Uptime';
TPS = (Com_commit + Com_rollback) / Uptime

另一计算方式:基于Com_select、Com_insert、Com_delete、Com_update计算出QPS

mysql> show global status where Variable_name in('com_select','com_insert','com_delete','com_update');

等待1秒再执行,获取间隔差值,第二次每个变量值减去第一次对应的变量值,就是QPS

TPS计算方法:

mysql> show global status where Variable_name in('com_insert','com_delete','com_update');

计算TPS,就不算查询操作了,计算出插入、删除、更新四个值即可。
经网友对这两个计算方式的测试得出,当数据库中myisam表比较多时,使用Questions计算比较准确。当数据库中innodb表比较多时,则以Com_*计算比较准确。

1.3 开启慢查询日志

MySQL开启慢查询日志,分析出哪条SQL语句比较慢,使用set设置变量,重启服务失效,可以在my.cnf添加参数永久生效。

mysql> set global slow-query-log=on  #开启慢查询功能
mysql> set global slow_query_log_file='/var/log/mysql/mysql-slow.log';  #指定慢查询日志文件位置
mysql> set global log_queries_not_using_indexes=on;   #记录没有使用索引的查询
mysql> set global long_query_time=1;   #只记录处理时间1s以上的慢查询

分析慢查询日志,可以使用MySQL自带的mysqldumpslow工具,分析的日志较为简单。

mysqldumpslow -t 3 /var/log/mysql/mysql-slow.log    
#查看最慢的前三个查询

也可以使用percona公司的pt-query-digest工具,日志分析功能全面,可分析slow log、binlog、general log。

分析慢查询日志:pt-query-digest /var/log/mysql/mysql-slow.log
分析binlog日志:mysqlbinlog mysql-bin.000001 >mysql-bin.000001.sql
pt-query-digest –type=binlog mysql-bin.000001.sql
分析普通日志:pt-query-digest –type=genlog localhost.log

1.4 数据库备份

备份数据库是最基本的工作,也是最重要的,否则后果很严重,但由于数据库比较大,上百G,往往备份都很耗费时间,所以就该选择一个效率高的备份策略,对于数据量大的数据库,一般都采用增量备份。常用的备份工具有mysqldumpmysqlhotcopyxtrabackup等,mysqldump比较适用于小的数据库,因为是逻辑备份,所以备份和恢复耗时都比较长。mysqlhotcopy和xtrabackup是物理备份,备份和恢复速度快,不影响数据库服务情况下进行热拷贝,建议使用xtrabackup,支持增量备份。

1.4.1 myqldump示例

使用myqldump时,注意myqldump不是sql语句,mysqldumpmysql用于转存储数据库的实用程序

不能在MySQL可视化工具或者DOS里的mysql下直接执行。

  1. 导出整个数据库
    导出文件默认是存在mysql\bin目录下
mysqldump -u 用户名 -p 数据库名 > 导出的文件名
mysqldump -u user_name -p123456 database_name > outfile_name.sql
  1. 导出一个表
mysqldump -u 用户名 -p 数据库名 表名> 导出的文件名
mysqldump -u user_name -p database_name table_name > outfile_name.sql
  1. 导出一个数据库结构
mysqldump -u user_name -p -d -add-drop-table database_name > outfile_name.sql
-d 没有数据 –add-drop-table 在每个create语句之前增加一个drop table
  1. 带语言参数导出
mysqldump -uroot -p –default-character-set=latin1 –set-charset=gbk –skip-optdatabase_name > outfile_name.sql

1.5 数据库修复

有时候MySQL服务器突然断电、异常关闭,会导致表损坏,无法读取表数据。这时就可以用到MySQL自带的两个工具进行修复,myisamchkmysqlcheck

1.5.1 myisamchk修复

myisamchk: 只能修复myisam表,需要停止数据库
常用参数:

  • -f –force 强制修复,覆盖老的临时文件,一般不使用
  • -r –recover 恢复模式
  • -q –quik 快速恢复
  • -a –analyze 分析表
  • -o –safe-recover 老的恢复模式,如果-r无法修复,可以使用此参数试试
  • -F –fast 只检查没有正常关闭的表

快速修复weibo数据库:

cd /var/lib/mysql/weibo
myisamchk -r -q *.MYI

1.5.2 mysqlcheck修复

mysqlcheckmyisam和innodb表都可以用,不需要停止数据库,如修复单个表,可在数据库后面添加表名,以空格分割
常用参数:

  • -a –all-databases 检查所有的库
  • -r –repair 修复表
  • -c –check 检查表,默认选项
  • -a –analyze 分析表
  • -o –optimize 优化表
  • -q –quik 最快检查或修复表
  • -F –fast 只检查没有正常关闭的表

快速修复weibo数据库:

mysqlcheck -r -q -uroot -p123 weibo

1.5.3 .frm文件修复

MYSQL中建立任何一张数据表,在其数据目录对应的数据库目录下都有对应表的.frm文件.frm文件是用来保存每个数据表的元数据(meta)信息,包括表结构的定义等,.frm文件跟数据库存储引擎无关,也就是任何存储引擎的数据表都必须有.frm文件,命名方式为数据表名.frm,如user.frm.frm文件可以用来在数据库崩溃时恢复表结构。

1.5.3.1 InnoDB表结构的恢复

假定:MYSQL数据库已经崩溃,目前只有对应表的.frm文件,大家都知道,.frm文件无法通过文本编辑器查看,因为如果不恢复,基本上来说对我们没什么用。这里我们为了测试,假定该文件为test_innodb.frm

该表创建脚本如下(建表后就把该表所在数据库服务器给强行关闭,模拟崩溃场景)

mysql> create table test_innodb
    -> (A int(11) default NULL,
    -> B varchar(30) default NULL,
    -> C date default NULL) engine=innodb;
Query OK, 0 rows affected (0.05 sec)

恢复方法介绍(过程):

  1. 在新的正常工作的MYSQL环境下建立一个数据库,比如aa
  2. 在aa数据库下建立同名的数据表test_innodb,表结构随意,这里只有一个id字段,操作过程片段如下:
mysql> create table test_innodb (id bigint not null)engine=InnoDB;
Query OK, 0 rows affected (0.09 sec)

mysql> show tables;
+--------------+
| Tables_in_aa |
+--------------+
| test_innodb |
+--------------+
2 rows in set (0.00 sec)

mysql> desc test_innodb;
+-------+------------+------+-----+---------+-------+
| Field | Type       | Null | Key | Default | Extra |
+-------+------------+------+-----+---------+-------+
| id    | bigint(20) | NO   |     | NULL    |       |
+-------+------------+------+-----+---------+-------+
1 row in set (0.00 sec)
  1. 把系统崩溃后留下的test_innodb.frm文件拷贝到此处正常数据库的数据目录aa下,覆盖掉下边同名的.frm文件
  2. 重新启动MYSQL服务。
  3. 测试下是否恢复成功,进入aa数据库,用desc命令测试下:
mysql> desc test_innodb;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| A     | int(11)     | YES  |     | NULL    |       |
| B     | varchar(30) | YES  |     | NULL    |       |
| C     | date        | YES  |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+
3 rows in set (0.01 sec)

OK,发现表结构已经恢复过来了。

1.5.3.2 MyISAM表结构的恢复

MyISAM类型的表恢复相对比较简单。
同样先假定需要恢复的表的FRM文件为test_myisam.frm,表结构为

mysql> create table test_myisam
    -> (A int(11) default NULL,
    -> B varchar(30) default NULL,
    -> C date default NULL) engine=myisam;
Query OK, 0 rows affected (0.05 sec)

恢复过程如下:

  1. 直接将test_myisam.frm拷贝到正常数据库对应的数据目录下。这时测试
mysql> show tables;
+--------------+
| Tables_in_aa |
+--------------+
| test_innodb |
| test_myisam |
+--------------+
3 rows in set (0.00 sec)

mysql> desc test_myisam;
ERROR 1017 (HY000): Can't find file: 'test_myisam' (errno: 2)

发现只能通过show tables命令看见表名,但是表结构还是没有恢复,desc命令报错。

  1. 在与test_myisam.frm同一目录建立以下2个文件,文件内容可以为空:test_myisam.MYD 表数据文件和test_myisam.MYI索引文件
  2. MYSQL命令行使用MYSQL本身的数据表恢复命令repair命令恢复表,如下:
mysql> repair table test_myisam USE_FRM;
+-----------------+--------+----------+----------+
| Table           | Op     | Msg_type | Msg_text |
+-----------------+--------+----------+----------+
| aa.test_myisam | repair | status   | OK       |
+-----------------+--------+----------+----------+
1 row in set (0.00 sec)

根据结果可以知道,恢复命令执行成功,下边用desc命令测试下:

mysql> desc test_myisam;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| A     | int(11)     | YES  |     | NULL    |       |
| B     | varchar(30) | YES  |     | NULL    |       |
| C     | date        | YES  |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+
3 rows in set (0.02 sec)

果然恢复成功了。
也可以用show create table命令测试下:

mysql> show create table test_myisam;
+--------------+-----------------------------------------------------------------
----------------------------------------------------------------------+
| Table        | Create Table
                                                                      |
+--------------+-----------------------------------------------------------------
----------------------------------------------------------------------+
| test_myisam | Create TABLE `test_myisam` (
  `A` int(11) DEFAULT NULL,
  `B` varchar(30) DEFAULT NULL,
  `C` date DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 |

在恢复MyISAM表结构时,提到MYD文件和MYI文件,这两个文件都专属于MyISAM存储引擎的,前者用来保存MyISAM表的数据,后者用来存放MyISAM表的索引信息。

1.6 MySQL恢复误删表而丢失的数据

相信后端研发的同学在开发过程经常会遇到产品临时修改线上数据的需求,如果手法很稳那么很庆幸可以很快完成任务,很不幸某一天突然手一抖把表里的数据修改错误或者误删了,这个时候你会发现各种问题反馈接踵而来。

1.6.1 查看是否开启binlog

保证 mysql 已经开启 binlog,查看命令:

查看binklog是否开启
show variables like '%log_bin%';

查看binlog存放日志文件目录
show variables like '%datadir%';
image.png

值为OFF,需开启,值为ON,表示已开启
如果没有开启 binlog ,也没有预先生成回滚SQL,那可能真的无法快速回滚了。对存放重要业务数据的 MySQL,强烈建议开启 binlog

1.6.2 查找日志文件

1.6.2.1 路径下查找

进入binlog文件目录,找出日志文件

image.png

1.6.2.2 命令下查找

查看下当前正在写入的 binlog 文件:

show master status;

image.png

也可以查看下当前有多少个 binlog 日志文件了:

show binary logs;
image.png

1.6.3 通过mysqlbinlog查看DML记录

1.6.3.1 在mysql服务器内

切换到mysqlbinlog目录,当线上数据出现错误的时候首先可以询问具体操作人记录时间点,这个时候可以借助mysql自带的binlog解析工具mysqlbinlog,具体位置在mysql 安装目录 **/mysql/bin/

image.png

通过 mysqlbinlog 工具命令查看数据库增删改查记录(必须切换到 mysqlbinlog 目录才有效)

例子1:查询2022-11-12 09:00:00到2022-11-13 20:00:00 数据库为 test 的操作日志,输入如下命令将数据写入到一个备用的txt文件中

 mysqlbinlog --no-defaults --database=test --start-datetime="2022-11-12 09:00:00" --stop-datetime="2022-11-13 20:00:00" /data/mysql/mysql-bin.000015    > template_coupon_tb_product_category.txt

例子2:查询2022-11-12 09:00:00到2022-11-13 20:00:00 数据库为 test 的操作日志,并输出到屏幕上

mysqlbinlog --no-defaults --database=test --start-datetime="2022-11-12 09:00:00" --stop-datetime="2022-11-13 20:00:00" /data/mysql/mysql-bin.000015   |more

例子3:查询2022-11-12 09:00:00到2022-11-13 20:00:00 数据库为 test 的操作日志,并且过滤出 只包括 template_coupon_tb_product_category 表数据的操作记录 ,输入如下命令将数据写入到一个备用的txt文件中

mysqlbinlog --no-defaults --database=test--start-datetime="2022-11-12 09:00:00" --stop-datetime="2022-11-13 20:00:00" /data/mysql/mysql-bin.000015   | grep template_coupon_tb_product_category   > template_coupon_tb_product_category.txt
image.png

1.6.3.2 用命令查看

在 SQL 控制台查看下 binlog 信息:

show binlog events in 'binlog.000002';
image.png

这样还不能看出刚才修改前的内容,下面就要使用 mysqlbinlog 工具进行分析了,首先进入到 binlog 日志的位置,我们根据时间点过滤下:

mysqlbinlog --no-defaults --base64-output=decode-rows -v --start-datetime="2022-03-13 19:00:00" --stop-datetime="2022-03-13 19:10:00" ./binlog.000002 

1.6.4 mysqlbinlog 命令

mysqlbinlog 命令的语法格式:

mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名

参数选项解释:

  • start-position=875:起始pos点
  • stop-position=954:结束pos点
  • start-datetime="2022-9-25 22:01:08":起始时间点
  • stop-datetime="2022-9-25 22:09:46":结束时间点
  • database=test:指定只恢复test数据库(一台主机上往往有多个数据库,只限本地log日志)
  • no-defaults:表示不使用配置文件中( my.cnf 里配的 [client] )的参数,可以避免有些 mysqlbinlog 没有的参数导致的失败
  • base64-output=decode-rows:解码方式,不加的话看到的是 base64 之后的
  • v 显示 sql 语句,也可以 vv 显示 sql 语句和类型
  • r:可以将结果输出到文件中
  • -u 或--user=name:连接到远程主机的用户名
  • -p 或--password[=name]:连接到远程主机的密码
  • -h 或--host=name:从远程主机上获取binlog日志
  • --read-from-remote-server:从某个MySQL服务器上读取 binlog 日志
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,590评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 86,808评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,151评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,779评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,773评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,656评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,022评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,678评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,038评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,659评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,756评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,411评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,005评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,973评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,053评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,495评论 2 343

推荐阅读更多精彩内容