服务器重启导致无法启动MySQL

今天服务器受到DDOS攻击，笔者脑残重启了一下服务器。结果造成MySQL服务器无法启动

mysql日志见下图。

160803 17:43:47 mysqld_safe Starting mysqld daemon with databases from /application/mysql/data160803 17:43:47 [Note] /application/mysql/bin/mysqld (mysqld 5.5.49) starting as process 1975 ...160803 17:43:47 [Warning] Using unique option prefix innodb_purge_thread instead of innodb-purge-threads is deprecated and will be removed in a future release. Please use the full name instead.160803 17:43:47 [Note] Plugin 'FEDERATED' is disabled.160803 17:43:47 InnoDB: The InnoDB memory heap is disabled160803 17:43:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins160803 17:43:47 InnoDB: Compressed tables use zlib 1.2.3160803 17:43:47 InnoDB: Using Linux native AIO160803 17:43:47 InnoDB: Initializing buffer pool, size = 64.0M160803 17:43:47 InnoDB: Completed initialization of buffer poolInnoDB: Error: auto-extending data file ./ibdata1 is of a different sizeInnoDB: 7296 pages (rounded down to MB) than specified in the .cnf file:InnoDB: initial 8192 pages, max 0 (relevant if non-zero) pages!160803 17:43:47 InnoDB: Could not open or create data files.160803 17:43:47 InnoDB: If you tried to add new data files, and it failed here,160803 17:43:47 InnoDB: you should now edit innodb_data_file_path in my.cnf back160803 17:43:47 InnoDB: to what it was, and remove the new ibdata files InnoDB created160803 17:43:47 InnoDB: in this failed attempt. InnoDB only wrote those files full of160803 17:43:47 InnoDB: zeros, but did not yet use them in any way. But be careful: do not160803 17:43:47 InnoDB: remove old data files which contain your precious data!160803 17:43:47 [ERROR] Plugin 'InnoDB' init function returned error.160803 17:43:47 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.160803 17:43:47 [ERROR] Unknown/unsupported storage engine: InnoDB160803 17:43:47 [ERROR] Aborting

160803 17:43:47 [Note] /application/mysql/bin/mysqld: Shutdown complete

160803 17:43:47 mysqld_safe mysqld from pid file /application/mysql/data/www.pid ended

实际图片：

曾试过手动启动

启动命令为：mysqld_safe–defaults-file=/data/3306/my.cnf &

停止命令为：mysqladmin -u root -poldboy123 -S /data/3306/mysql.sockshutdown

但是发现一直提示没有pid，百度了一下有一篇文章说需要删除ib_logfile0和ib_logfile1两个文件

就可以启动，对这两个文件进行了一下科普，如下：

文章

mysql的innodb中事务日志ib_logfile
事务日志或称redo日志，在mysql中默认以ib_logfile0,ib_logfile1名称存在,可以手工修改参数，调节
开启几组日志来服务于当前mysql数据库,mysql采用顺序，循环写方式，每开启一个事务时，
会把一些相关信息记录事务日志中(记录对数据文件数据修改的物理位置或叫做偏移量);
作用:在系统崩溃重启时，作事务重做；在系统正常时，每次checkpoint时间点，会将之前写入事务
应用到数据文件中。
引入一个问题：在m/s环境中,innodb写完ib_logfile后,服务异常关闭，会不会主库能用ib_logfile恢复数据，而
binlog没写导致从库同步时少少这个事务？从而导致主从不一致;
redo日志写入方式：
1.ib_logfile写入当前事务更新数据，并标上事务准备trx_prepare
2.写入bin-log
3.ib_logfile当前事务提交提交trx_commit
恢复方式:
如果ib_logfile已经写入事务准备,那么在恢复过程中，会依据bin-log中该事务是否存在恢复数据。
假设:
1）结束后异常,因没有写入bin-log，从库不会同步这个事务，主库上，重启时，在恢复日志中这个
事务没有commit，即rollback这个事务.
2）结束后异常，这会bin-log已经写入，从库会同步这个事务。主库依据恢复日志和bin-log，也正常恢复此事务
综上描述:bin-log写入完成，主从会正常完成事务；bin-log没有写入，主从库rollback事务;不会出现主从库不一致问题.
相关参数（全局&静态）:
innodb_log_buffer_size
innodb_log_file_size
innodb_log_files_in_group
innodb_log_group_home_dir
innodb_flush_log_at_trx_commit
innodb_log_buffer_size:事务日志缓存区,可设置1M~8M,默认8M,延迟事务日志写入磁盘,
把事务日志缓存区想象形如”漏斗”状,会不停向磁盘记录缓存的日志记录,而何时写入通过参数
innodb_flush_log_at_trx_commit控制,稍后解释,启用大的事务日志缓存,可以将完整运行大事
务日志，暂时存放在事务缓存区中,不必(事务提交前)写入磁盘保存,同时也起到节约磁盘空间占用;
innodb_log_file_size:控制事务日志ib_logfile的大小,范围5MB~4G；所有事务日志ib_logfile0+
ib_logfile1+..累加大小不能超过4G，事务日志大，checkpoint会少,节省磁盘IO，但是大的事务日
志意味着数据库crash时，恢复起来较慢.
引入问题:修改该参数大小，导致ib_logfile文件的大小和之前存在的文件大小不匹配
解决方式：在干净关闭数据库情况下，删除ib_logfile，而后重启数据库，会自行创建该文件;
innodb_log_files_in_group:DB中设置几组事务日志，默认是2；
innodb_log_group_home_dir:事务日志存放目录，不设置，ib_logfile0…存在在数据文件目录下
innodb_flush_log_at_trx_commit：控制事务日志何时写盘和刷盘，安全递增：0,2,1
事务缓存区:log_buffer;
0:每秒一次事务缓存区刷新到文件系统，同时文件系统到磁盘同步，但是事务提交时，不会触发log_buffer到文件系统同步；
2:每次事务提交时,会把事务缓存区日志刷新到文件系统中去，且每秒文件系统到磁盘同步;
1:每次事务提交时刷新到磁盘，最安全;
适用环境:
0:磁盘IO能力有限,安全方便较差,无复制或复制延迟可以接受，如日志性业务，mysql损坏丢失1s事务数据;
2:数据安全性有要求，可以丢失一点事务日志，复制延迟也可以接受，OS损坏时才可能丢失数据;
1:数据安全性要求非常高，且磁盘IO能力足够支持业务，如充值消费，敏感业务;

文章地址

由于经费原因，没有做CDN，所以扛不住DDOS攻击实属正常

下图是阿里云发监控：

网站流量监控

小结：

防治DDOS的前提是必须要做好监控！

另外在受到攻击，重启服务器是没有作用的，在实际生产环境是不可以重启的。这点大家一定要冷静！

由于作者手残不小心rm -rf ib* 因为表示Innbodb表，所以导致所有数据全都被删除（已经哭晕在厕所）

跟我一起忘记rm 命令把！！！！！！！！

ibdata用来储存文件的数据
而库名的文件夹里面的那些表文件只是结构而已

对于DDOS防范可以参考下面文章：

网站DDOS攻击防护实战老男孩经验心得分享

625某电商网站数据库宕机故障解决实录

http://oldboy.blog.51cto.com/2561410/1431161

http://oldboy.blog.51cto.com/2561410/1431172

关于MySQL引擎[innodb文章]

http://www.abcdocker.com/abcdocker/77

服务器重启导致无法启动MySQL相关推荐

mysql同步出错后重启_服务器重启导致mysql同步出错
服务器重启导致mysql同步出错 151119 11:05:04 mysqld_safe Starting mysqld daemon with databases from /data/mysql ...
Docker启动异常之服务器非法重启,导致Docker启动失败
场景还原: 服务器更新安全控件, 没有关闭docker 直接重启了. 重启之后就启动不开了. 如果是如下错误 ,直接重启服务即可, 当然我也看到了一些比较好的文章解决docker 启动失败,在下, ...
宝塔服务器重启后redis启动报错pid file is exits
转自https://blog.csdn.net/qq_41895021/article/details/109483832 今天遇到了这个问题,所以转载记录一下,该问题的原因是redis非正常关闭,导 ...
关于服务器重启之后无法启动perforce服务的问题
Perforce无法启动的问题如题:在企业维护过程中,perforce服务器关闭后有时候会面临无法重启服务的问题 1.登录到Perforce服务器,进入ROOT根目录 2.找到db.user和db. ...
服务器重启后没有启动网卡
关掉LINUX服务器之后,再启动的时候没有重启网卡,解决办法: 在/etc/rc.d/rc.local里加入 ifup eth0 或者 ifconfig eth0 up
非正常关机导致无法启动MYSQL提示丢失mysql.sock的解决办法
判断一般人解决故障时没有切换到mysql用户,造成权限有问题,无法创建mysql授权表,所以也就无法创建/tmp/mysql.sock 和hostname.pid文件.因此,总结解决方法如下: (1) ...
服务器重启后，启动SAP ERP的步骤
OS是环境Linux SUSE database 是 ASE 16.0 系统ID是WEN lvdisplay mount /dev/vg0/myroot /abaptest su - we ...
mysql数据库服务器重启_重启mysql数据库服务器
Mysql错误代码大全 1016错误:文件无法打开,使用后台修复或者使用phpmyadmin进行修复. 1044错误:数据库用户权限不足,请联系空间商解决 1045错误:数据库服务器/数据库用户名/数 ...
jspstudy启动mysql失败_MySql启动数据库设置初始密码
这一小节介绍在Mac OS.Linux.Windows上启动关闭重启MySQL服务,以及部分图形化界面对服务的操控.安装完成后,可以使用 service 命令启动 mysql 服务,在Mac上serv ...

服务器重启导致无法启动MySQL

服务器重启导致无法启动MySQL相关推荐

最新文章

热门文章