修改innodb_log_file_size后无法启动mysql的问题

针对修改innodb_log_file_size后无法启动mysql的问题

由于今天发现mysql宕机了,影响到大家访问了。于是决定进行mysql配置文件的优化。 因为我的阿里云主机配置比较低,问了好多最后了解到徐布斯同学的服务器和我的配置一样,于是他把他的配置文件发给我了。我复制了一下优化参数发现无法启动,对此进行了一上午的研究(起的比较晚)


温馨提示:

关于mysql的配置文件可以参考以下:
老男孩:my-innodb-heavy-4G.cnf配置文件注解
徐布斯:my-innodb-heavy-4G.cnf配置文件注解
abcdocker:my-innodb-heavy-4G.cnf配置文件注解


1.对MySQL配置文件进行优化时

发现修改innodb_log_file_size后无法启动mysql的问题

  1. innodb_log_buffer_size = 4M
  2. innodb_log_file_size = 4M
  3. innodb_log_files_in_group = 3

2.发现设置这三个参数之后,无法启动MySQL

因为原来没有设置innodb

  • 启动错误
  1. [root@www /]# /etc/init.d/mysqld restart
  2. Shutting down MySQL. [ OK ]
  3. Starting MySQL.The server quit without updating PID file (/[FAILED]ion/mysql/data/mysql.pid).

提示我们没有pid.... 这就尴尬了
当时其实可以看error日志的,因为过度敏感,直接百度。解决问题!
经过一系列的找百度,发现问题


后来才知道原来要STOP服务先,然后再删除原来的文件………

删除ib_logfile0, ib_logfile1........ib_logfilen

这个问题,在另一篇文章也有介绍
服务器重启导致无法启动MySQL


  • 在此为大家解释一下:

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事务;不会出现主从库不一致问题.
相关参数(全局&静态):

  1. innodb_log_buffer_size
  2. innodb_log_file_size
  3. innodb_log_files_in_group
  4. innodb_log_group_home_dir
  5. 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能力足够支持业务,如充值消费,敏感业务;


解决问题:

  1. [root@www data]# ls
  2. bbs ib_logfile1 mysql_3306.err mysql-bin.000003 mysql-bin.000006 slow.log www.err
  3. ibdata1 ib_logfile2 mysql-bin.000001 mysql-bin.000004 mysql-bin.index test
  4. ib_logfile0 mysql mysql-bin.000002 mysql-bin.000005 performance_schema wordpress
  5. [root@www data]# mv ib_logfile* /tmp/

企业环境中,尽量不用rm命令。后果你懂的~**

检查一下,有没有移动错误

  1. [root@www data]# ls
  2. bbs mysql mysql-bin.000001 mysql-bin.000003 mysql-bin.000005 mysql-bin.index slow.log wordpress
  3. ibdata1 mysql_3306.err mysql-bin.000002 mysql-bin.000004 mysql-bin.000006 performance_schema test www.err

再次启动~~~~!!!!!

  1. [root@www data]# /etc/init.d/mysqld restart
  2. MySQL server PID file could not be found! [FAILED]
  3. Starting MySQL.

相关文章

当时修改完配置文件,发现mysql启动了,但是没有端口号

错误日志如下:

  1. 160808 15:25:52 mysqld_safe A mysqld process already exists
  2. 160808 15:27:17 [Note] /application/mysql/bin/mysqld: Normal shutdown
  3. 160808 15:27:17 [Note] Event Scheduler: Purging the queue. 0 events
  4. 160808 15:27:17 InnoDB: Starting shutdown...
  5. 160808 15:27:18 InnoDB: Shutdown completed; log sequence number 159497238
  6. 160808 15:27:18 [Note] /application/mysql/bin/mysqld: Shutdown complete
  7. 160808 15:27:18 mysqld_safe mysqld from pid file /application/mysql/data/www.pid ended
  8. 160808 15:27:29 mysqld_safe Starting mysqld daemon with databases from /application/mysql/data
  9. 160808 15:27:29 [Warning] 'THREAD_CONCURRENCY' is deprecated and will be removed in a future release.
  10. 160808 15:27:29 [Warning] options --log-slow-admin-statements, --log-queries-not-using-indexes and --log-slow-slave-statements have no effect if --log_slow_queries is not set
  11. 160808 15:27:29 [Note] /application/mysql/bin/mysqld (mysqld 5.5.49-log) starting as process 7842 ...
  12. 160808 15:27:29 [Note] Plugin 'FEDERATED' is disabled.
  13. 160808 15:27:29 InnoDB: The InnoDB memory heap is disabled
  14. 160808 15:27:29 InnoDB: Mutexes and rw_locks use GCC atomic builtins
  15. 160808 15:27:29 InnoDB: Compressed tables use zlib 1.2.3
  16. 160808 15:27:29 InnoDB: Using Linux native AIO
  17. 160808 15:27:29 InnoDB: Initializing buffer pool, size = 64.0M
  18. 160808 15:27:29 InnoDB: Completed initialization of buffer pool
  19. 160808 15:27:29 InnoDB: highest supported file format is Barracuda.
  20. 160808 15:27:29 InnoDB: Waiting for the background threads to start
  21. 160808 15:27:30 InnoDB: 5.5.49 started; log sequence number 159497238
  22. 160808 15:27:30 [Warning] 'user' entry 'root@web' ignored in --skip-name-resolve mode.
  23. 160808 15:27:30 [Warning] 'user' entry '@web' ignored in --skip-name-resolve mode.
  24. 160808 15:27:30 [Warning] 'proxies_priv' entry '@ root@web' ignored in --skip-name-resolve mode.
  25. 160808 15:27:30 [Note] Event Scheduler: Loaded 0 events
  26. 160808 15:27:30 [Note] /application/mysql/bin/mysqld: ready for connections.
  27. Version: '5.5.49-log' socket: '/tmp/mysql.sock' port: 0 MySQL Community Server (GPL)

经过发现是一个skip-networking 优化参数的原因,因为我是直接复制别人的配置,好多参数也没修改所造成的


skip-networking介绍

MySQL开启skip-name-resolve和skip-networking优化 使用skip-name-resolve增加远程连接速度
skip-name-resolve
该选项表示禁用DNS解析,属于官方一个系统上的特殊设定不管,链接的的方式是经过hosts或是IP的模式,他都会对DNS做反查,由于反查解析过慢,就会无法应付过量的查询。
单机运行MySQL使用skip-networking关闭MySQL的TCP/IP连接方式


skip-networking

开启该选项后就不能远程访问MySQL
为安全考虑希望指定的IP访问MySQL,可以在配置文件中增加bind-address=IP,前提是关闭skip-networking
bind-address=192.168.1.100 MySQL优化应该按实际情况配置。


相关文章
思想: 万事要冷静!解决问题就会感觉一身轻松~(前提事前要备份哟~)asd


  • 4
  • 12,051 views
    A+
发布日期:2016年08月08日  所属分类:MySQL
标签:
新闻联播老司机

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:4   其中:访客  3   博主  1

  1. avatar 票据宝 1
    好文章,谢谢博主好心分享
  2. avatar 工业铝型材 0
    瞎评论剁手 啊吓坏我了。。第一次来,不要吓我哦
    • avatar 新闻联播老司机
      ..... 很强势!
  3. avatar 演员网 2
    第一次来,不要吓我哦