MySQL Innodb 神秘消失

问题描述:

早晨接到 Zabbix 报警,提示 Host: 10.10.1.2, MySQL 主从同步失败。

登录服务器查看具体情况。

shell > mysql

mysql> show slave status\G

Slave I/O thread : YES
Slave SQL thread : NO

Slave SQL: Error ‘Unknown storage engine ‘InnoDB‘‘ on query. Default database: ‘baeng_tv‘. 

Query: ‘UPDATE std_tv_card SET uid=‘135601920029371878‘, devicetoken=‘60000AM1500D16972129_569C‘ WHERE id=‘220888‘‘, Error_code: 1286

Slave: Unknown storage engine ‘InnoDB‘ Error_code: 1286

# 这是 show slave status\G 看到的一些状态信息,说不支持 InnoDB 引擎。这不开玩笑呢么,又不是第一次跑。

shell > vim /data/mysql_data/hostname.err

Version: ‘5.5.28-log‘  socket: ‘/tmp/mysql.sock‘  port: 3306  Source distribution
160930 07:20:36 mysqld_safe Number of processes running now: 0
160930 07:20:36 mysqld_safe mysqld restarted

160930  7:20:37 InnoDB: The InnoDB memory heap is disabled
160930  7:20:37 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160930  7:20:37 InnoDB: Compressed tables use zlib 1.2.3
160930  7:20:38 InnoDB: Initializing buffer pool, size = 1.0G
InnoDB: mmap(1098907648 bytes) failed; errno 12
160930  7:20:38 InnoDB: Completed initialization of buffer pool

160930  7:20:38 InnoDB: Fatal error: cannot allocate memory for the buffer pool
160930  7:20:38 [ERROR] Plugin ‘InnoDB‘ init function returned error.
160930  7:20:38 [ERROR] Plugin ‘InnoDB‘ registration as a STORAGE ENGINE failed.

160930  7:20:38 [Note] Server hostname (bind-address): ‘0.0.0.0‘; port: 3306
160930  7:20:38 [Note]   - ‘0.0.0.0‘ resolves to ‘0.0.0.0‘;
160930  7:20:38 [Note] Server socket created on IP: ‘0.0.0.0‘.

160930  7:20:38 [Note] Slave SQL thread initialized, starting replication in log ‘mysql-bin.003702‘ at position 287099739, relay log ‘./hostname-relay-bin.010674‘ position: 2597075
160930  7:20:38 [Note] Slave I/O thread: connected to master ‘[email protected]:3306‘,replication started in log ‘mysql-bin.003702‘ at position 287261852
160930  7:20:39 [Note] Event Scheduler: Loaded 0 events
160930  7:20:39 [Note] /usr/local/mysql-5.5/bin/mysqld: ready for connections.
Version: ‘5.5.28-log‘  socket: ‘/tmp/mysql.sock‘  port: 3306  Source distribution

160930  7:23:04 [ERROR] Slave SQL: Error ‘Unknown storage engine ‘InnoDB‘‘ on query. Default database: ‘baeng_tv‘. Query: ‘UPDATE std_tv_card SET uid=‘135601920029371878‘, devicetoken=‘60000AM1500D16972129_569C‘ WHERE id=‘220888‘‘, Error_code: 1286
160930  7:23:04 [Warning] Slave: Unknown storage engine ‘InnoDB‘ Error_code: 1286
160930  7:23:04 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log ‘mysql-bin.003702‘ position 288077147

# mysql.err

InnoDB: Initializing buffer pool, size = 1.0G

# 初始化缓存池,大小为 1G

InnoDB: Fatal error: cannot allocate memory for the buffer pool

# 无法为 InnoDB 缓存池分配内存

Plugin ‘InnoDB‘ init function returned error.

# InnoDB 插件 init 函数返回错误

Plugin ‘InnoDB‘ registration as a STORAGE ENGINE failed.

# InnoDB 插件存储引擎注册失败

# 接着就是初始化 Slave SQL thread 启动同步,I/O 线程连接 master。
# 最后提示,Slave SQL 错误,未知的存储引擎,查询语句 ‘UPDATE 失败‘。

解决方法:

shell > free -m

# 当时空闲内存只有 936M,而初始化的缓存池为 1G。

# 看到这里,应该知道故障是由系统内存不足造成的,该机器内存为 24G。上面就跑了一个 MySQL Slave 跟一些任务计划。

# 说到任务计划,这是一些查询数据,然后写入 ElasticSearch 生成索引的一些 PHP 脚本。

shell > ps aux | grep php | wc -l
2000

# 好家伙!!!

# 任务计划是每 5、10、15 分,分别执行不同的 PHP 脚本。执行完、下次循环。
# 也就是如果没有执行完,等到下一个时间点就会重新启动一个 PHP 脚本... 所以占用了大量系统内存。

shell > ps aux | grep -v grep | grep php | awk ‘{print $2}‘ | xargs -i kill {}

# 先将这些阻塞的进程全部杀死

shell > free -m
             total       used       free     shared    buffers     cached
Mem:         24020       4933      19086          0        140       2880
-/+ buffers/cache:       1912      22107
Swap:         8191          9       8182

# 内存释放了

shell > /etc/init.d/mysql.server restart

shell > mysql

mysql> show slave status\G

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

        Seconds_Behind_Master: 1340

# 主从同步正常,延迟就让它自己补上吧,过一会就好了。

# 故障消除
# 接下来让故障不再出现

shell > vim script/yiic_index.sh
#!/bin/bash

logfile=‘/root/script/logs/yiic.log‘
filepath=‘/data/git-webroot/yiic index‘

line=`ps aux | grep -v grep | grep ‘yiic index‘ | wc -l`

if [ $line -eq 0 ]:then
  /usr/local/php/bin/php $filepath >/dev/null &
else
  echo `date "+%F %T"` $filepath >> $logfile
  exit 0
fi

# End

shell > crontab -e

*/5 * * * * /root/script/logs/yiic_index.sh

# 这样就控制住了 PHP 进程的数量。

# 但是,这样写脚本会出现僵尸进程。
# 先执行 sh 脚本,然后将 php 进程放入后台,退出 sh 脚本,这样 sh 就是 PHP 的父进程了,所以产生僵尸。
# 但这是可控的,如果 PHP 执行时间过长,下次 crond 调用 sh 时,是不执行 PHP 的。
# 生成的僵尸进程也不必担心,当 PHP 执行完毕后,僵尸自动死亡。

shell > crontab -e

*/5 * * * * timeout 2000 /usr/local/php/bin/php /data/git-webroot/yiic index >/dev/null

# 也可以这样来控制 PHP 进程执行时间,随你选咯

时间: 2024-11-03 03:24:49

MySQL Innodb 神秘消失的相关文章

MySQL InnoDB 群集–在Windows上设置InnoDB群集

InnoDB集群最需要的功能之一是Windows支持,我们现在已将其作为InnoDB Cluster 5.7.17预览版 2的一部分提供.此博客文章将向您展示如何在MS Windows 10上运行InnoDB集群.64位系统. 我们将执行以下步骤. 下载包 安装 创建一个InnoDB群集沙箱配置 引导MySQL路由器 测试配置 下一步是什么? 让我们开始吧! 下载包 首先,我们必须下载安装所需的四个组件. 来自dev.mysql.com的具有组复制功能的MySQL Server 5.7.17.

使用mysql innodb 使用5.7的json类型遇到的坑和解决办法

---------------------------------------------- #查询JSON的某个字段 select data -> '$.Host' from temp #创建虚拟列 ALTER TABLE temp ADD host varchar(128) GENERATED ALWAYS AS (json_extract(data,'$.Host')) VIRTUAL; #给虚拟列创建索引 ALTER TABLE temp ADD INDEX index_temp_hos

巧用MySQL InnoDB引擎锁机制解决死锁问题(转)

该文会通过一个实际例子中的死锁问题的解决过程,进一步解释innodb的行锁机制 最近,在项目开发过程中,碰到了数据库死锁问题,在解决问题的过程中,笔者对MySQL InnoDB引擎锁机制的理解逐步加深. 案例如下: 在使用Show innodb status检查引擎状态时,发现了死锁问题: *** (1) TRANSACTION: TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starti

优化导入数据到MariaDB、Mysql(InnoDB)的速度

关键配置:关闭binlog 环境:8G的sql文件,300多个InnoDB数据表,(用MysqlWorkbench导出的数据,用HeidiSql导入,因为正式环境是mysql,可以用MysqlWorkbench,而MariaDB用不了导出,要用HeidiSql,直接用mysqldump.source命令也可以).导出耗时6分钟,导入耗时55分钟(有待提高,跟进中) 版本:MariaDB 10 1.注释"log-bin=mysql-bin"."binlog_format=mix

MYSQL INNODB PAGE一督

MYSQL INNODB PAGE一督 MYSQL INNODB PAGE一督,布布扣,bubuko.com

mysql innodb存储引擎的聚集索引

InnoDB聚集索引 MySQL有没有支持聚集索引,取决于采用哪种存储引擎. MySQL InnoDB一定会建立聚集索引,所谓聚集,指实际数据行和相关的键值保存在一块,这也决定了一个表只能有一个聚集索引,即MySQL不会一次把数据行保存在二个地方.InnoDB通常根据主键值(primary key)进行聚集,但是当一个表没有PK怎么办?InnoDB选取聚集索引参照列的顺序是: 1.如果声明了主键(primary key),则这个列会被做为聚集索引2.如果没有声明主键,则会用一个唯一且不为空的索引

MySQL InnoDB内存压力判断以及存在的疑问

本文出处:http://www.cnblogs.com/wy123/p/7259866.html(保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他) 与其他数据一样,内存对数据库的性能有着至关重要的影响,MySQL InnoDB也一样通过内存来缓存数据,在访问数据的时候通过访问内存中缓存的数据来提高数据的访问效率.MySQL中通过show variables like 'Innodb_buffer_pool%'命令或者直接

浅谈mysql innodb缓存策略

浅谈mysql innodb缓存策略: The InnoDB Buffer Pool Innodb 持有一个存储区域叫做buffer pool是为了在内存中缓存数据和索引,知道innodb bufferpool怎么工作,和利用它读取频繁访问的数据,是mysql优化重要的方面. 理想状况下,把bufferpool的大小调整到足够大,留下足够的内存空间给其他该服务器上的进程(使其无缺页即可).bufferpool越大,innodb 月表现为内存型数据库,从硬盘上一次读取数据,之后并成了从内存中读取数

mysql innodb 性能优化

默认情况下,innodb的参数设置的非常小,在生产环境中远远不够用比如最重要的两个参数innodb_buffer_pool_size 默认是8Minnodb_flush_logs_at_trx_commit 默认设置的是1 也就是同步刷新log(可以这么理解) innodb_buffer_pool_size: 这是InnoDB最重要的设置,对InnoDB性能有决定性的影响.默认的设置只有8M,所以默认的数据库设置下面InnoDB性能很差.在只有 InnoDB存储引擎的数据库服务器上面,可以设置6