在数据库运维过程中,我们时常会关注数据库的链接情况,比如总共有多少链接、有多少活跃链接、有没有执行时间过长的链接等。数据库的各种异常也能通过链接情况间接反应出来,特别是数据库出现死锁或严重卡顿的时候,我们首先应该查看数据库是否有异常链接,并杀掉这些异常链接。本篇文章将主要介绍如何查看数据库链接及如何杀掉异常链接的方法。
今天是中秋节之后的第一天,虽然身体来上班了,但是脑子还在放假。今天主要是把密码管理模块的代码推了一版,然后研究了一下mysql的my.cnf文件,简单总结一下。
![图片](https://img-blog.csdnimg.cn/img_convert/c5a6e93737c3ae3842d70f259c6d044a.jpeg)
首先三个命令都是用于杀掉进程的,不过kill是杀掉单个进程,killall是杀掉所有同名进程,pkill是杀掉一类进程或者某个用户的所有进程。
问题背景:一次启动本地应用,两分钟过后自动退出,通过日志并未发现任何异常状况,莫名其妙的应用就自动被杀掉了;
由于众所周知的原因,在国内使用 maven,会等待很长的时间来下载相应的 jar 包。
最简单、最便捷部署MySQL的方法是什么?当用户需要体验MySQL的最新功能、验证集群的高可用功能、排除特定版本的故障时,需要能够快速部署一台或多台MySQL实例,这时可以利用MySQL Shell提供的AdminAPI,快速部署一套Sandbox(沙箱实例)。
监视数据库中用户的活动,并对其进行管理是MySQL的一项必要工作。本文将介绍如何监视MySQL用户活动,及限制用户使用资源的方法。
死锁排查方法 查看进程状态 show processlist; 查看行锁的状态 show status like 'InnoDB_row_lock%'; 查询是否有死锁 show engin innodb status; 查看正在锁的事务 检查字段 trx_autocommit_non_locking,如果为 0,则说明这个事务还没有提交,需要提交。 杀掉这个事务。因为很可能是人工修改数据库,没有提交。 这个时候,从小到大 kill <trx_mysql_thread_id>。 检查字段 trx_a
我们在运维MySQL的过程中,肯定多多少少遇到过Innodb row lock的问题,如果在线上遇到我们可能会看到一大片的session处于堵塞状态通常我们在show processlist中会看到如下:
是这样的pureftpd还算是个比较轻量的服务器ftp软件,还可以搭配比较灵活的认证。其中有一种用法就是搭配mysql,把用户身份存在在mysql里面方便管理。但是当我把环境搭建好之后创建了ftp用户发现连接后认证失败530。在log里面看到说pureftpd无法连接数据库,access denied ftp@localhost。
如果没有一定的攻击基础,以及扎实的开发功底,想要做好防御是不可能的,因此想要在AD类竞赛中做好防御,首先是有足够的基础,这里面的基础有很多,大概包括以下几个方面:
今天开发的一个同学问我一个MySQL的问题,说在测试数据库中执行一条Insert语句之后很久没有响应。我一看语句是一个很常规的insert into xxx values形式的语句。看起来有些不太合乎
今天下午在线上遇到了一个业务反馈mysqldump频繁失败,大概的错误日志如下:
如果还不行。 那么应该是数据库在执行数据操作失败 or 事务未提交 之后,将需要执行的sql语句锁死了。
图中红色语句 LOCK WAIT为占用系统资源的语句,我们需要杀掉这个锁,执行 kill 线程id号。上面这条记录的id为199120823069, trx_mysql_thread_id 为 738178711, 所以我们执行:kill 738178711杀掉这个MySQL语句的线程即可。 执行之后:
pt-kill 是 Percona Toolkit 中的一个工具,用于 kill MySQL 的连接。它的参数包括:
show open tables where in_use > 0 命令可以查询锁表。 in_use 为 1 表示这个表同时被两个用户使用,一个正在用,一个在锁定中。
线上服务器用的是某讯云的,欢快的完美运行着Tomcat,MySQL,MongoDB,ActiveMQ等程序。突然一则噩耗从前线传来:网站不能访问了!
#最近写了一个小程序,在购买的乞丐版腾讯云服务器上跑起来了tomcat、redis、mysql… #怪事就这样开始了… #先是redis莫名其妙被杀掉… #接下来tomcat也莫名其妙的被杀掉… #redis怎么启动不出10min,他就悄无声息的没了…很神奇,日志也没有被杀掉的记录… #查看oom killer的日志也没有…难道累了自刀了?显然不可能… #我又寻思难道是java里设置的最小空闲连接数量问题?(此时已经进入无脑的瞎蒙状态)显然怎么改依然无济于事…Orz… #凌晨了,此时超级安静的环境下,一股力量让我敲下了
同事在做项目的时候遇到一个事务死锁的问题,在做一个修改的时候提示:Lock wait timeout exceeded; try restarting transaction
有时候我们会发现系统中某个进程会突然挂掉,通过查看系统日志发现是由于 OOM机制 导致进程被杀掉。
遇到故障,我们往往想的是如何解决这个故障,而不是从故障的根本去思考出现这个故障的原因?这样的结果,只能使我们得到了鱼,失去了渔。今天,我们就来分享一个由USE DB堵塞故障引发的思考案例。 故障描述 今天一个朋友遇到数据库遇到一个严重的故障,故障环境如下: MYSQL 5.6.16 RR隔离级别 GITD关闭 表现如下: use db不能进入数据库 show table status不能查询到表信息 schema.processlist来看有大量的 Waiting for table metadata lo
下载 去https://dev.mysql.com/downloads/mysql/下载 解压 添加/bin到环境变量 在根目录创建文件my.ini [mysqld] basedir=E:\mysql-5.7.18-winx64 datadir=E:\mysql-5.7.18-winx64\data mysqld -install 输入命令mysqld --initialize net start mysql 然后,会发现不知道root的密码啊。坑爹。 要这么玩: net stop
日常工作或学习过程中,我们可能会经常用到某些SQL,建议大家多多整理记录下这些常用的SQL,这样后续用到会方便很多。笔者在工作及学习过程中也整理了下个人常用的SQL,现在分享给你!可能有些SQL你还不常用,但还是希望对你有所帮助,说不定某日有需求就可以用到。
1、在做数据库操作时,有时会因为自己的粗心或者程序设计上的缺陷导致锁表,在mysql中查看锁表和解锁的步骤如下:
mysql查看被锁住的表 查询是否锁表 show OPEN TABLES where In_use > 0; 查看所有进程 MySQL: show processlist; mariabd: show full processlist; 查询到相对应的进程===然后 kill id 杀掉指定mysql连接的进程号 kill $pid 查看正在锁的事务 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; 查看等待锁的事务 SELECT * FROM INFORMAT
在线上环境中部署脚本,可谓是常在河边走,哪有不湿鞋,所以大大小小的案例总结下来,还是会发现一些有趣的地方,这些可以作为操作时的一些参考,仅供参考而已。 第一类脚本是修复脚本,比如提供的数据修复功能,数据补丁等,这类脚本的特点是后续的数据变更很可能会依赖于之前的操作,环环相扣。所以一旦执行过程中出现问题,就需要保证这个操作可回退,否则会是雪上加霜。 image.png 第二类的脚本是彼此之间没有直接联系。哪怕是中间执行出一点问题也不会直接影响其他业务。 image.png 第三类的脚本介于两者之间,有互相的
Mysql高可用环境的搭建比较麻烦,这使很多人都不去搭建高可用环境,等到有问题时再说 最近Mysql的动作很快,新版本的发布频繁,推出很多新的好用功能及插件,其中了就包括了简化高可用环境的搭建难度 下面就体验一下新的搭建方法,的确方便了很多 整个过程包括: 基础环境的安装(mysql 5.7.15、mysql-shell、mysql-router) 部署多个实例 创建集群 部署 Mysql Router 故障测试 其中第1步的过程较长,便不在本文中介绍,有兴趣自己搭建的小伙伴可以发送消息:01,获取相关安装
引起cpu过高的sql一般集中在order by、group by、批量insert、嵌套子查询等sql语句中
使用“ps -e|grep mysql”命令,查看mysql程序的对应的pid号。
线上服务器用的是某讯云的,欢快的完美运行着Tomcat,MySQL,MongoDB,ActiveMQ等程序。突然一则噩耗从前线传来:网站不能访问了。 此项目是我负责,我以150+的手速立即打开了服务器
MySQL出现运行时间过长的SQL(慢SQL),会使线上数据库压力倍增,影响业务稳定性及可用性
最近也抽空帮一些网友解决一些问题,有些是Oracle,有些是MySQL,有时候虽然忙忙乎乎,但是解决问题之后还是很有成就感的。 今天来说一个蛮有意思的问题,听起来还很诡异。是一个网友向我咨询,看看能不能给出一些建议。当我看到日志,隐隐感觉这是一个bug的感觉。 详细的日志如下: 2017-04-13 16:25:29 40180 [Note] Server socket created on IP: '::'. 2017-04-13 16:25:29 40180 [Warning] Storin
今天回家,遇到这个莫名奇妙的错误,把谷歌和百度翻了好几页也没有解决,大多数都是复制粘贴的一个答案,说什么my.ini的错误,折腾了半天 重装、重新配置、重起 都没有起作用,顺便带一句,真是恨透
首先看下MySQL误删数据排名最前的几种是什么,然后说几点平时预防误操作导致文件/数据丢失不成熟的建议,最后再说万一发生误操作时,怎么以最快速度进行补救。
8.安装完之后修改当前目录拥有者为root用户,修改data目录拥有者为mysql
1.安装openresty # yum -y install libuuid-devel pcre-devel openssl-devel gcc-c++ wget # mkdir /openresty # cd /openresty # wget https://openresty.org/download/openresty-1.9.15.1.tar.gz # tar -zxf openresty-1.9.15.1.tar.gz # cd openresty-1.9.15.1 # ./configure
操作系统:CentOS 7 mysql下载地址:https://dev.mysql.com/downloads/mysql/ 下载版本:mysql-8.0.20-linux-glibc2.12-x86_64.tar.xz
作为一名常年CURD的程序员,一定非常熟悉这条查询语句吧。从jiuxiao_admin_log 表中查询 user_id=1000的数据。 然而我们只知道这样会返回出结果,却不知道里面的流程。相信这也是你点击进来的目的吧,让我们一起来拆解一下mysql中有哪些零件!
那大概是一个春暖花开的季节,我的内心是激动澎湃的,因为已经安排了休假计划。在这前几天,已经把一个新项目的数据库环境都部署好了,包括 自动化备份。
在MySQL中,自带了许多功能比较强大的工具,如mysql、mysqladmin、mysqldump等。 1、mysql命令 Mysql命令是用的最多的一个命令工具了,为用户提供一个命令行接口来操作管理MySQL 服务器。可以通过mysql --help来查看其详细使用方法。
在安装nginx,mysql,tomcat等等服务的时候,我们会遇到需要使用的端口莫名其妙被占用,下面介绍如何解决这类问题。
先将当前的nagios2.9备份 cd /usr/local cp -r nagios nagios2.9 cd /etc/init.d/ cp nagios nagios2.9 升级(从2.9到3.0.3) 下载nagios-3.0.3 首先大致的看一下里面的两篇文章 whatsnew.html和upgrading.html 介绍了新版的特点和升级方法 然后开始升级工作 解压缩后执行 ./configure --with-command-group=nagios make all make install 然后验证 /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg 报两个warning和一个critical 两个warning是:downtime_file 和 comment_file这两个文件已经不在使用,将他们的内容添加到state_retention_file这个文件的后面 一个critical是:434行有错误,变量不能识别 解决两个warning的方法如下: 先将nagios.cfg中comments 和downtime变量注释掉 # COMMENT FILE # This is the file that Nagios will use for storing host and service # comments. #comment_file=/usr/local/nagios/var/comments.dat # DOWNTIME FILE # This is the file that Nagios will use for storing host and service # downtime data. #downtime_file=/usr/local/nagios/var/downtime.dat 查找state_retention_file=/usr/local/nagios/var/retention.dat 然后执行 cd /usr/local/nagios/var cat comments.dat >>retention.dat cat downtime.dat >>retention.dat 解决critical的方法如下 注释掉434行的#check_result_buffer_slots=4096 这个变量已经不在使用了。 然后再验证启动nagios就没问题了 需要说明:从2.x升级到3.x还有这样一点要注意 Extended host and extended service definitions have been deprecated. They are still read and processed by Nagios, but it is recommended that you move the directives found in these definitions to your host and service definitions, respectively. 我配置的有extended service,但是里面的配置信息是nagios grapher自动生产的。况且3.x是可以读的,只是推荐写到service定义中而已。我这里并没有按照这条的建议。没对原来的配置做修改。 Nagvis启动故障的排查 更新nagios之后 启动nagvis需要的NDO组件 /usr/local/nagios/bin/ndo2db -c /usr/local/nagios/etc/ndo2db.cfg 提示Could not bind socket: Address already in use 查看/usr/local/nagios/etc/ndo2db.cfg 有这样的内容 # SOCKET TYPE # This option determines what type of socket the daemon will create # an accept connections from. # Value: # unix = Unix domain socket (default) # tcp = TCP socket socket_type=unix #socket_type=tcp socket是unix类型的(是一个sock文件),而不是tcp类型的(tcp端口) 原来是/usr/local/nagios/var/ndo.sock还存在(因为ndo是使用kill命令杀掉进程的) 所以删掉这个.sock文件即可 运行/usr/local/nagios/bin/ndo2db -c /usr/local/nagios/etc/ndo2db.cfg 启
phpmyadmin 上的高级配置不要点,否则会炸,解决办法,删除所有新建的表,然后重装PHPmyadmin即可。
登陆到MySQL的提示符下,数据show processlist这个命令,可以得到所以连接到这个服务器上的MySQL连接:mysql> show processlist; +———+——+———————+———+———+——+——-+——————-+ | Id | User | Host | db | Command | Time | State | Info | +———+——+———————+———+———+——+——-+——————-+ | 1180421 | ur | 202.103.96.68:49754 | test1 | Sleep | 1 | | NULL | | 1180427 | ur | 202.103.96.68:55079 | test2 | Sleep | 1 | | NULL | | 1180429 | ur | 202.103.96.68:55187 | testdba | Sleep | 0 | | NULL | | 1180431 | ur | 202.103.96.68:55704 | testdba | Sleep | 0 | | NULL | | 1180437 | ur | 202.103.96.68:32825 | test1 | Sleep | 1 | | NULL | | 1180469 | ur | 202.103.96.68:58073 | testdba | Sleep | 0 | | NULL | | 1180472 | ur | 83.136.93.131:47613 | test2 | Sleep | 8 | | NULL | | 1180475 | root | localhost | NULL | Query | 0 | NULL | show PROCESSLIST | +———+——+———————+———+———+——+——-+——————-+ 8 rows in set (0.00 sec)
导读:DBA的大部分工作都是围绕着对数据库的维护而展开的,常规的日常维护更是占了绝大多数。本节将围绕日常维护中最常见的三个案例展开讲解,与大家分享排查此类问题的思路。
死锁是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等的进程称为死锁进程。
领取专属 10元无门槛券
手把手带您无忧上云