大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
可以通过查看mysql进程来实现。 进入mysql命令行客户端,选择数据库后,执行show processlist命令: 多刷新几次,可以看到最后执行的SQL语句,以此判断什么查询在占用资源。
成都创新互联公司是一家专注于成都网站建设、成都做网站与策划设计,宁海网站建设哪家好?成都创新互联公司做网站,专注于网站建设10余年,网设计领域的专业建站公司;建站业务涵盖:宁海等地区。宁海做网站价格咨询:18980820575
一、磁盘满了之后MySQL会做什么?
我们看下官方的说法:
When a disk-full condition occurs, MySQL does the following:
* It checks once every minute to see whether there is enough space to write the current row. If there is enough space,it continues as if nothing had happened.
* Every 10 minutes it writes an entry to the log file, warning about the disk-full condition.
其实MySQL本身并不会做任何操作,如官方文档说说,只会每分钟check一次是否有空闲空间,并且10分钟写一次错误日志。
但是再次期间由于磁盘满了,意味着binlog无法更新,redo log也无法更新,所有buffer
pool中的数据无法被flush上,如果不幸的服务器重启,或者实例被kill了,那必然会造成数据丢失,这几乎是一定的。所以,处理磁盘满的问题最好是先释放出来一定空间让dirty数据刷新下来。
二、磁盘满了为什么会导致操作hang住?
1、select
首先经过经验和实际测试,select操作不会由于磁盘满导致问题,也就是所有select操作都会正常运行。
2、insert
经过不通的测试发现,当磁盘满了之后,并不是第一个insert就卡住,而是会在n个之后出现卡住的情况。
通过查看error日志,发现卡住现象和刷磁盘的操作有关系。
[ERROR] /usr/local/mysql-5.1.42/libexec/mysqld: Disk is full writing './test/cj_webex.MYD'
[ERROR] /usr/local/mysql-5.1.42/libexec/mysqld: Disk is full writing './mysql-bin.000017'
为了验证推论是否正确,我们将sync_binlog设置为1,在这种情况下,insert第一条就卡住了,并且error
log中直接报错提示写binlog失败。看来卡住确实和刷磁盘有关系。
目前已知和刷磁盘有关系的参数有3个,分别是sync_binlog,innodb_flush_log_tr_commit和duoblewrite。
3、show slave status
在从库经过测试,操作会被卡住,这主要是由于执行show slave
status需要获得LOCK_active_mi锁,然后锁上mi-data_lock,但是由于磁盘满了无法将io_thread中的数据写入到relay
log中,导致io_thread持有mi-data_lock锁,这就导致了死锁。
所以,这就导致在磁盘满的情况下,执行show slave status操作会卡住。
4、show status
测试可以正常操作,但是如果先执行了show slave status操作的情况下,show
status也会被卡住。这是因为执行show status需要锁上LOCK_status,而由于status状态中包含slave
status,所以还需要锁上LOCK_active_mi。如果限制性了show slave
status,这时候由于mi-data_lock死锁问题,导致io_thread不会释放LOCK_active_mi锁。这时候就导致show
status和show slave status争抢同一把LOCK_active_mi锁,也形成了死锁。
所以,在磁盘满的情况下,如果先执行show slave status,后执行show status,连个操作都会卡住。
可以利用光盘引导启动进入PE系统后完整拷贝硬盘内的所有数据。
所有东西完整导出到移动硬盘可以通过硬盘克隆来完成。详细操作步骤如下:
1、安装并打开软件,主页面找到“克隆”栏,选择“磁盘克隆”。
2、选择源磁盘(要导出的磁盘)
3、选择目标磁盘(要导入的磁盘)
4、选择好两个磁盘,点击“开始备份”。
5、在备份详情页面显示备份进度和详细过程。
6、进度条100%后,点击“完成”就导出所有的内容到移动硬盘了。
补充说明:移动硬盘缺点:损毁基本无法恢复:除此之外同固态硬盘一样,在硬受到物理损坏时数据是无法恢复的,不过这种情况只是小概率事件,基本不会遇到。
我们在工作中时常会遇到一些客户的TPS\QPS都不太高,但磁盘占用非常大,一旦单实例空间太大,像内存、网络、CPU以及备份都将增加相应的开销。可能仅仅是由于空间不满足使得我们不得不进行扩容,下面的方法提供给大家参考。有则改之无则加勉。
1、表结构设计上
1)
字符集是否遵循了最小化原则?(能用latin的就不用gbk。能用gbk的就不用utf8)
2)
索引上是否有滥用?(根本不使用的字段建索引、不适合建索引的字段建索引、重复建索引或者不能很好的利用前缀索引等)
3)
冗余字段是否太多?(各表中不用的或者字段冗余太多)
4)
不正确的字段类型?(能用1个字节非要用几个字节,像枚举类、状态类比较常见)
5)
将较长的字段或者几个字段组合做为主键?(主键最好用mysql自增)
具体事例如下:
CREATE
TABLE
`class_meta`
(
`class_name`
varchar(128)
NOT
NULL
COMMENT
'类名',
`class_desc`
varchar(2048)
default
''
COMMENT
'类的描述',
`class_status`
char(20)
default
'test1'
COMMENT
'test1,test2',
PRIMARY
KEY
(`class_name`),
UNIQUE
KEY
`cm_cn_uk`
(`class_name`),
KEY
`cm_cd_ind`
(`class_desc`(767)),
KEY
`cm_cs_ind`
(`class_status`),
KEY
`cm_cdcn_ind`
(`class_desc`(767),`class_name`)
)
ENGINE=InnoDB
DEFAULT
CHARSET=latin1
COMMENT='meta信息';
通过上面的表结构能看到如下地方不合适
1、主键与唯一索引明显重复,索引cm_cd_ind与索引cm_cdcn_ind索引重复(这种情况经常出现,大家留意下)
2、cm_cs_ind如果两个状态分布均匀也明显不合适建索引
3、class_desc由于是描述性质的,也不合适建索引
4、最好以自增做为主键,可以减少整表的空间
5、class_status列明显可以用tinyint来存,可以省下19个字节
2、存储内容上
1)
是否将图片、视频、音乐等大数据存储在表中?(表里最好只保留路径而不是实际的文件内容)
3、数据保留上
1)是否有已过期而未删除的数据?(对于无效数据及时清理或者进行历史归档)
4、后期维护上
1)是否对经常删除的表进行维护(optimize
table)
建议:
1、在性能要求不高的case中(并发不太高),可以考虑使用压缩表。一般压缩率在30%-70%之间,收益非常可观。
2、对于删除非常频繁的表要定期进行优化,使表中碎片减少。提高查询、写入的性能。
3、在表结构设计上,一定要发扬“斤斤计较”的精神,能用1个字节表示的坚决不用2个字节。
4、尽量减少大字段的使用。
ps:经常在跟开发评审表结构的时候,时常会被笑话说DBA太抠门,一点都不大气。当数据量小的时候可能大家不觉得,但当你的数据级到T或者P的时候,哪怕多省几个字节都是非常可观的,给大家简单算笔账,如果我们将一张5亿条记录的表,字段从100个字节降到60个字节(应该很容易做到吧),那么不算上索引将节约大约18G的空间。