虚拟机关机后第二天mysql起不来,回想一下我关机前和关机后的操作发现:关机前没关闭mysqld服务就直接init 0了,关机后将虚拟机内存由1G降到724M.笔者保证再也做过别的骚操作了. -- :: [Note] Plugin 'FEDERATED' is disabled. -- :: [Note] InnoDB: Using atomics to ref count buffer pool pages -- :: [Note] InnoDB: The InnoDB memory heap…
记一次 mysql 启动没反应 ,重启linux又可以启动 vim /var/log/mysqld.log 2018-02-04 13:22:49 28507 [ERROR] InnoDB: Cannot allocate memory for the buffer pool2018-02-04 13:22:49 28507 [ERROR] Plugin 'InnoDB' init function returned error.2018-02-04 13:22:49 28507 [ERROR]…
最近一次日常迭代中,业务线需要对一张大表进行联合查询,查询性能可想而知,测试过程中服务接口直接响应超时,导致服务不可用,最后临时对该表进行分区操作,暂时缓解性能问题.由于是第一次操作表分区,姑且记录一下整个操作过程. 测试表结构 12345678 CREATE TABLE `tb_partition_test` ( `user_id` bigint(20) NOT NULL , `city_id` bigint(20) NOT NULL DEFAULT '0', `record_type` sm…
背景在上一篇文章里面已经提过了. 现在面临的问题是nextcloud没有mysql数据库,用不起来了. 因为文件没丢,一种方法是启动新的mysql数据库,把文件重新提交一次. 为了程序员的面子,没有选择这么没技术含量的方法.我想通过恢复mysql数据库来解决这个问题. 恢复mysql数据库 于是,在mysql目录里面找找看,发现了一堆binlog文件.上网查了一下,binlog文件里面好像有记录mysql的操作,可以用来恢复数据库. 查看binlog:# ll -th binlog.* 先把最近…
背景: nextcloud的mysql数据库被黑,删库勒索.参考:记一次mysql数据库被勒索(上) mysql数据库恢复成功,nextcloud还是无法连接.参考:记一次mysql数据库被勒索(中) 正文: 经过一番研究,发现nextcloud在第一次数据库配置成功后,会创建一个oc_root的帐号,之后就会使用oc_root帐号来连接数据库. 而oc_root的密码,并不是在配置的时候设置的管理员root的密码,貌似是nextcloud自己生成的. 加密算法应该跟这里面的passwordsa…
记一次mysql事务未提交导致锁未释放的问题 ## 查看未提交的事务(3秒内未操作的事务) SELECT p.ID AS conn_id, P.USER AS login_user, P.HOST AS login_host, p.DB AS database_name, P.TIME AS trx_sleep_seconds, TIME_TO_SEC(TIMEDIFF(NOW(),T.trx_started)) AS trx_open_seconds, T.trx_started, T.trx…
最近开发中遇到的一个MySQL主从延迟的坑,记录并总结,避免再次犯同样的错误. 情景 一个活动信息需要审批,审批之后才能生效.因为之后活动要编辑,编辑后也可能触发审批,审批中展示的是编辑前的活动内容,考虑到字段比较多,也要保存审批活动的内容,因此设计采用了一张临时表,审批中的活动写进审批表(activity_tmp),审批通过之后才把真正的活动内容写进活动表(activity).表的简要设计如下,这里将活动内容字段合并为content展示: activity_tmp() id status //…
一.现象 在服务器上通过curl命令调用一个Java服务的查询接口,半天没有任何响应.关于该服务的基本功能如下: 1.该服务是一个后台刷新指示器的服务,即该服务会将用户需要的指示器数据提前计算好,放入redis中,当用户请求指示器数据时便从redis中获取: 2.指示器涉及到的模型数据更新时会发送消息到kafka,该服务监听kafka消息,收到消息后触发指示器刷新任务: 3.对于一些特殊的指示器,其涉及的项目和模型较多,且数据量比较大,无法通过kafka消息来触发刷新,否则一直处于刷新过程中,便…
本文列举了史上八大MySQL宕机事件原因.影响以及人们从中学到的经验,文中用地震级数来类比宕机事件的严重性和后果,排在最严重层级前两位的是由于亚马逊AWS宕机故障(相当于地震十级和九级). 一.Percona网站宕机事件 震级:3 发生时长:2011年7月11日 持续时长:数日 地点:加州Pleasanton(幸福屯) 宕机原因:Percona网站主服务器上的3块硬盘损坏,同时因为人员变更,导致未能如预期地恢复,多个网站资产因此下线数小时到数天不等,影响其软件下载及交易. 经验:备份不一定永远正…
1. [事件起因] 今天在做项目的时候,发现提供给客户端的接口时间很慢,达到了2秒多,我第一时间,抓了接口,看了运行的sql,发现就是 2个sql慢,分别占了1秒多. 一个sql是 链接了5个表同时使用了 2个 order by和 1个limit的分页 sql. 一个sql是上一个sql的count(*),即链接了5个表,当然没有limit了(取总数). 2. [着手优化] 1)[优化思路] 第一条是 做client调用 service层的数据缓存 第二条就是 优化sql本身. 这里着重讲一下…