有一台预上线的服务器最近在做压力测试,也引发了一系列的相关问题,排查思路可以提供参考。
作者:孙绪宗,新浪微博 DBA 团队工程师,主要负责 MySQL、PostgreSQL 等关系型数据库运维。
近期公司网站全面版本升级,使用thinkphp5.1版本为基础,进行了二次开发,在全面更新后,网站链接暴涨增值98万,运行一周未出现什么问题,但是在下一周,忽然程序出现大面积404页面,查看日志及错误信息,发现是linux服务器tmp目录爆满,导致mysql无法写入,程序崩盘。
在安装好了MySQL之后,使用了新的配置文件后,MySQL服务器可以成功启动,但在登陆的时候出现了ERROR 2002 (HY000): Can't connect to local MySQL server through socket,即无法通过socket连接到mysql服务器,同时提供了socket文件的位置。下面是这个问题的描述与解决办法。
我们知道,在MySQL中,redo log是一个文件组,一般是3个文件,循环写入,写满的时候会做redo log层面的checkpoint,然后覆盖之前的redo log;而binlog是有归档功能的,每个binlog写满之后,都会重新开启下一个binlog开始写入,这也是为什么可以使用binlog来进行数据恢复的一个原因,就是因为它的归档功能。
在 Linux 上自建 MySQL 服务器,经常遇到各种无法启动或启动后异常的问题,本文列举一些常见问题的解决办法。
腾讯云数据库内存 100% 确实是常年以来的热点咨询问题,以下是针对此问题的介绍说明。
在「3306π」社区广州站5月22日的分享会上,万里数据库CTO娄帅给出了他建议的配置参考,我们一起来看下:
今天在线上运维过程中,遇到了一个TiDB写满操作系统磁盘的问题,最终通过查阅官方文档解决,这里记录一下。
今天早上在公司,遇到了一个系统负载的问题,问题的内容如下:某个从库上的系统负载从5月26日开始,一直处于比较高的状态,磁盘IO也比较高,这里我先截取一部分监控的曲线图:
这是去年在线上遇到了一个系统负载的问题,问题的内容如下:某个从库上的系统负载从5天前开始,一直处于比较高的状态,磁盘IO也比较高,这里我先截取一部分监控的曲线图:
相信有不少同学都看过“DBA随笔”,幕后的作者是我前同事小叶,作为小叶的导师,我教过他正事,也教过一些坏的习惯,不过写笔记这个习惯算是小叶自己开窍了,他已经坚持了很长一段时间了,这股学习劲头值得点赞,圈子就这么大,其实要深耕做点事情靠的还是兴趣和坚持。
[Code: 1290, SQL State: HY000] The MySQL server is running with the –secure-file-priv option so it cannot execute this statement 通过show variables like ‘%secure_file_priv%’; secure_file_priv参数说明
MySQL 报错 [Code: 1290, SQL State: HY000] The MySQL server is running with the –secure-file-priv option so it cannot execute this statement 通过show variables like ‘%secure_file_priv%’; secure_file_priv参数说明 这个参数用来限制数据导入和导出操作的效果,例如执行LOAD DATA、SELECT … IN
第一种迁移方案 mysqldump迁移 mysqldump导出数据库成一个sql文件(快) scp命令复制到另一台服务器(快) source命令导入数据,cpu跑满(比较耗时) 脚本迁移 命令行操作数据库进行数据的导出和导入(比较耗时) 第二种迁移方案 redis搭建一个“生产+消费”的迁移方案 在源数据服务器上跑一个多线程脚本,并行读取数据库里面的数据,并把数据写入到redis队列 目标服务器作为一个消费者,在目标服务器上也跑一个多线程脚本,远程连接redis,并行读取redis队列里面的数据,并
https://dev.mysql.com/doc/refman/5.7/en/replication.htm
exportfs命令 常用选项 -a 全部挂载或者全部卸载 -r 重新挂载 -u 卸载某一个目录 -v 显示共享目录 以下操作在服务端上 -vim /etc/exports //增加 /tmp/ 192.168.133.0/24(rw,sync,no_root_squash) exportfs -arv //不用重启nfs服务,配置文件就会生效 以下操作在客户端 mkdir /aminglinux mount -t nfs -onolock 192.168.133.130:/tmp /aminglinux
MySQL有两种来连接方式,一种是通过TCP/IP,就是用-h参数指定要连接的mysqlserverI的IP,另一种是套接字socket,在这里就是mysql.sock文件。当我们的客户端与数据库服务器(mysqlserver)在同一台机器上时,就通过该文件来连接数据库。
虽然从库可以不需要开启二进制日志功能,这里我们推荐主从库同时开启二进制日志功能,方便主从切换
将/tmp目录权限修改为777,重启mysql和cloudera-scm-server服务
参考https://blog.csdn.net/ithomer/article/details/89530790 查看某个目录的文件大小并排序(单位为MB).此处查看/var目录
1、配置文件参数my.cnf tmp_table_size=64M max_heap_table_size=64M tmpdir = /data/mysql/tmp 2、优化Tips: 如果Created_tmp_disk_tables/ Created_tmp_tables应该小于20%,如果比值较高,就需要适当调高tmp_table_size或者max_heap_table_size的值,让Mysql在内存中完成临时表的操作,减少使用硬盘对性能和响应时长的影响。 在调高tmp_table_size或者m
MySQL复制全解析 Part 2 一步步搭建基于二进制文件位置的MySQL复制
这两天在做MySQL5.7~MySQL8.0的版本升级,收集整理了MySQL8.0的几个比较便利的地方,分享出来,大家可以参考一下。
爱可生 DBLE 团队开发成员,主要负责 DBLE 需求开发,故障排查和社区问题解答。
解决问题固然重要,但是好奇心驱使我又看向了 系统错误编码 13(OS errno 13),很熟悉的一个编码。当时很快就想到了mysql的perror命令。所以,现在回顾下,也想来说说这个命令。
我有一个数据表,记录一个QQ号加好友的活跃天数、加好友次数、加好友的toUin数等信息。数据表的建表语句如下:
线上一台Linux服务器最近经常磁盘根分区满告警, 但不是普通的日志文件或数据文件过多过大,现象如下: 1)执行“df -h”查看各分区空间的使用情况 [root@XEN64 /]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 9.8G 8.7G 535M 95% / devtmpfs 7.7G 0 7.7G 0% /dev tmpfs 7.7G 0 7.7G 0% /dev/shm tmpfs 7.7G 666M 7.1G 9% /run tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup /dev/sda3 20G 3.3G 16G 18% /usr/local 可以看到根分区使用率超过了预警值, 进入根目录,查看根目录下各子目录的大小: [root@XEN64 /]# du -sm * 0 bin 180 boot 0 dev 24 etc 3 home 0 lib 0 lib64 1 lost+found 1 media 1 mnt 32 opt du: cannot access 'proc/17842/task/17842/fd/4': No such file or directory du: cannot access 'proc/17842/task/17842/fdinfo/4': No such file or directory du: cannot access 'proc/17842/fd/4': No such file or directory du: cannot access 'proc/17842/fdinfo/4': No such file or directory 0 proc 2 root 666 run 0 sbin 1 srv 0 sys 96 tmp 5856 usr 221 var 进一步检查/usr目录: [root@XEN64 /usr]# du -sm * 358 1.2-compat 164 bin 1 etc 1 games 33 include 912 lib 432 lib64 101 libexec 3269 local 1 man 46 sbin 547 share 1 src 0 tmp 对比du和df的结果,可以发现两者的已使用大小不一致, du命令得到的已用大小远小于df命令已用大小,初步猜测存已被删除文件仍然有进程在写它,导致du命令发现不了。 如果允许,最简单的处理方式是重启机器,不然用下列命令找出被删除的,但仍然可能有进程在写它的文件: pids=`ps aux|awk '{print $2}'`;for pid in $pids; do lsof -p $pid|grep del; done 见到庐山真面目: [root@XEN64 /proc]# pids=`ps aux|awk '{print $2}'`;for pid in $pids; do lsof -p $pid|grep del; done stati 28885 root 1w REG 8,1 5969132048 409096 /tmp/process_monitor-root.log (deleted) stati 28885 root 2w REG 8,1 5969132048 409096 /tmp/process_monitor-root.log (deleted) stati 28885 root 3u REG 8,4 20480039 35651587 /data/consumer/log/consumer.log.5 (deleted) consumer 29756 root 1w REG 8,1 5969132048 409
由于Linux没有回收站功能,所以线上服务器上所有要删除的文件都会先移动到系统/tmp目录下,然后定期清除/tmp目录下的数据。这个策略本身没有问题,但是通过检查发现这台服务器的系统分区中并没有单独划分/tmp分区,这样/tmp下的数据其实占用了根分区的空间。既然找到了问题,那么删除/tmp目录下一些占空间较大的数据文件即可,检查/tmp下最大的三个数据文。
今天在LAMP环境使用WordPress搭建博客,在进行数据库的相关配置时遇到了mysql.sock寻址错误的问题,错误提示:“ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)”意思是通过本地/var/lib/mysql/mysql.sock文件无法连接到MySQL服务。为了解决该问题,上网查询资料,所有回答都大同小异,最终自己总结了两种解决办法。
######################################################### # 硬盘显示被写满但是用du -sh /*查看时占用硬盘空间之和还远 #小于硬盘大小问的解决 #date:2010-06-09 #作者:老男孩---《老男孩linux就业培训中心 》 #QQ:31333741 #QQ交流群:385168604 #blog: http://oldboy.blog.51cto.com ##########################################################
找到my.cnf,添加如下内容sudo vim /usr/local/mysql/my.cnf
笔记写了不少,有时候有的朋友问我几个关键字,我就会从脑海里进行搜索,凡是写过的,搜索一下总能找到,帮助了别人,提高了自己,何乐而不为。 但是笔记写了很多,如果不加以改进,那么进步还是很小的,尤其比较怕的就是如果写出了问题的解决方案,但是这个解决方案是非主流的方式,可能有一 些潜在风险的,如果误导了读者,那就是罪过了。所以有时候想集中纠正一下。而且有时候看看以前写的文章,有时候会发现有一些分析思路可能在经历了大批量的 故障处理之后,思路可能会更开阔,这些其实也可以改进改进。 写笔记能坚持到现在
最近遇到一个MySQL数据导入时候遇到问题,先来看下问题产生的具体报错信息如下所示:
chown -R mysql.mysql /application/mysql-5.6.38/
2019年7月10日 ⋅ 浏览量: 4
前面一篇已经介绍了MySQL 备份相关的原理与方法,要是还没有来得及看的可以戳此查看『MySQL 备份恢复(一)』,那么今天就接着上一篇的内容继续谈谈备份恢复相关内容。数据备份是 DBA 非常重要的工作之一,系统意外奔溃或者硬件损坏都可能导致数据库的数据丢失,因此 MySQL DBA 应该定期备份数据,使得意外发生时尽可能的减少损失。数据备份在工作中是重中之重,安全很重要。
3.5 给MySQL挂载本地目录容器不仅仅可以挂载数据卷,也可以直接挂载到宿主机目录上。关联关系如下:
问题描述 mysql数据库有auto_increment这样一个特性,一般是用来设置Integer类型主键自增长。比如下面的代码: -- 刚创建表,该表没有AUTO_INCREMENT值 create table test( id int(11) primary key not null auto_increment, field1 varchar(40) not null default '' ) engine=InnoDB; show create table test\G; ... Creat
接下来是测试环节,首先我们使用下面的脚本创建一个aaa.txt的文本文件,里面循环写了一些文字:
在执行一个有1000万条记录的MySQL查询语句时,出现了上面的错误。百度折腾了很长时间,终于解决,特此记录。
之前遇到一个DBA,在生产库上加字段,导致数据库连接数打满。原因就是MDL锁引起。下面让我来介绍一下MDL锁及其排查和处理方式。
MySQL主从介绍 MySQL主从又叫做Replication、AB复制。简单讲就是A和B两台机器做主从后,在A上写数据,另外一台B也会跟着写数据,两者数据实时同步的 MySQL主从是基于binlog的,主上须开启binlog才能进行主从。 主从过程大致有3个步骤 1)主将更改操作记录到binlog里 2)从将主的binlog事件(sql语句)同步到从本机上并记录在relaylog里 3)从根据relaylog里面的sql语句按顺序执行 主上有一个log dump线程,用来和从的I/O线程传递b
在使用 docker 时,往往会出现磁盘空间不足,导致该问题的通常原因是因为 docker 中部署的系统输出了大量的日志内容。
[root@bogon ldap]# cat /tmp/zabbix_server.log
编辑/etc/my.cnf文件添加在[mysqld]版块下添加如下变量,添加后重启服务。
今天是《MySQL核心知识》专栏的第14章,今天为大家系统的讲讲MySQL中的数据备份与恢复,希望通过本章节的学习,小伙伴们能够举一反三,彻底掌握MySQL中的数据备份与恢复相关的知识。好了,开始今天的正题吧。
贺春旸,凡普金科DBA团队负责人,《MySQL管理之道:性能调优、高可用与监控》第一、二版作者,曾任职于中国移动飞信、安卓机锋网。致力于MariaDB、MongoDB等开源技术的研究,主要负责数据库性能调优、监控和架构设计。
线上tidb集群都是2.1.[5,7,8,17],因版本太低,面临诸多问题,比如管理难度大,热点问题,执行计划失效,性能瓶颈,其他已知/未知且无法解决的问题,现在需要升级至4.0.13版本。在调研后发现,如果原地升级将需要多次升级【2.1--> 3.0 --> 4.0】,担心原地升级遇到不可逆的故障,更担心的是解决不掉而影响业务,所以经过测试和评估,最终采用数据迁移的方式进行升级。
领取专属 10元无门槛券
手把手带您无忧上云