大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
一、磁盘满了之后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,连个操作都会卡住。
如果C盘空间本身比较小,只能考虑扩大C盘分区大小,或者换个硬盘。
如果不是,检查C盘上新产生,造成磁盘变满的文件是什么文件,找出原因。
答:MySQL的FLUSH可以清理mysql数据库缓存数据 MySQL的FLUSH句法(清除或者重新加载内部缓存) FLUSH flush_option [,flush_option],如果你想要清除一些MySQL使用内部缓存,你应该使用FLUSH命令。为了执行FLUSH,你必须有reload权限。 flush_option ...
mysqldump可以导出纯sql文本,但是有些建表语句的参数名在高低版本中是不一样的,
比如说在mysql4.*中的引擎指定用type,而mysql5.5的时候就用engine,
可以先把备份的sql文件先导到5.0左右的,会有警告,但是能导成功,然后再从5.0中导出sql文件,最后迁移到5.5的
建议是在数据迁移的时候版本差距别太大,有可能会出现版本兼容问题。
在对MySQL 8.0.26 vs GreatSQL 8.0.25的对比测试过程中,有一个环节是人为制造磁盘满的场景,看看MGR是否还能正常响应请求。
在实测过程中,最后发现磁盘满的那个节点,持续时间足够久后,会因为内存消耗过大而最终被OS给OOM Kill。
这个问题我已报告BUG(#104979),下面是该过程的详细记录。
首先,直接利用dd复制空文件填满磁盘。
disk full报告过程及何时被oom killed
来看下MySQL 8.0.26遇到disk full时日志都输出哪些内容:
从disk full时刻开始,大约过了2.5小时,mysqld进程内存消耗持续上升,最终引发oom kill
在这期间某个时刻抓到的待认证事务堆积,在被oom kill前实际不止这么多:
关注mysqld进程内存消耗变化
下面是mysqld进程内存消耗变化情况
OS层oom-killer相关日志:
GreatSQL 8.0.25测试过程
作为对比,我用GreatSQL 8.0.25也做了同样的测试。
从日志详情中可以看到,当磁盘空间满了之后,GreatSQL会将那个节点主动退出集群,对整个集群的影响非常小。
此外,从集群退出后,也不会再接收认证事务了,所以也没发生内存持续暴涨最终被oom killed的情况,实际观察过程中发现内存反倒还下降了
这样对比来看,GreatSQL的可靠性还真是可以的,官方的MySQL MGR的可靠性还有待进一步加强呀。
Enjoy GreatSQL :)
可以通过查看mysql进程来实现。 进入mysql命令行客户端,选择数据库后,执行show processlist命令: 多刷新几次,可以看到最后执行的SQL语句,以此判断什么查询在占用资源。