MySQL在生产情况出现无法启动的问题解决

渣渣兔  论坛元老 | 2024-10-29 06:50:24 | 显示全部楼层 | 阅读模式
打印 上一主题 下一主题
楼主

主题 1590|帖子 1590|积分 4770

MySQL在生产情况出现无法启动的问题解决

1、事由

本日现服务器重启了，然后服务器启动完成之后我发现为啥后端程序没有启动，排查之后发现是MySQL没有启动连接不上数据库，错误信息如下：
  1. 2024-04-16T02:34:01.507696Z 0 [Warning] [MY-000081] [Server] option ＇max_allowed_packet＇: unsigned value 107374182400 adjusted to 1073741824.
  2. 2024-04-16T02:34:01.507749Z 0 [Warning] [MY-011070] [Server] ＇binlog_format＇ is deprecated and will be removed in a future release.
  3. 2024-04-16T02:34:01.507821Z 0 [Warning] [MY-010915] [Server] ＇NO_ZERO_DATE＇, ＇NO_ZERO_IN_DATE＇ and ＇ERROR_FOR_DIVISION_BY_ZERO＇ sql modes should be used with strict mode. They will be merged with strict mode in a future release.
  4. 2024-04-16T02:34:01.507923Z 0 [Warning] [MY-010918] [Server] ＇default_authentication_plugin＇ is deprecated and will be removed in a future release. Please use authentication_policy instead.
  5. 2024-04-16T02:34:01.507955Z 0 [System] [MY-010116] [Server] /www/server/mysql/bin/mysqld (mysqld 8.0.36) starting as process 7075
  6. 2024-04-16T02:34:01.524054Z 0 [Warning] [MY-013907] [InnoDB] Deprecated configuration parameters innodb_log_file_size and/or innodb_log_files_in_group have been used to compute innodb_redo_log_capacity=1073741824. Please use innodb_redo_log_capacity instead.
  7. 2024-04-16T02:34:01.526764Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
  8. 2024-04-16T02:34:02.677451Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
  9. 2024-04-16T02:34:02.975637Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: trx0types.h:541:m_rsegs_n ＜ 2 thread 47034609473280
  10. InnoDB: We intentionally generate a memory trap.
  11. InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
  12. InnoDB: If you get repeated assertion failures or crashes, even
  13. InnoDB: immediately after the mysqld startup, there may be
  14. InnoDB: corruption in the InnoDB tablespace. Please refer to
  15. InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
  16. InnoDB: about forcing recovery.
  17. 2024-04-16T02:34:02Z UTC - mysqld got signal 6 ;
  18. Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
  19. BuildID[sha1]=911887188a59108d0b2707ced3fa0b5872644b4f
  20. Thread pointer: 0x2ac79c0008c0
  21. Attempting backtrace. You can use the following information to find out
  22. where mysqld died. If you see no messages after this, something went
  23. terribly wrong...
  24. stack_bottom = 2ac7193089e8 thread_stack 0x100000
  25. /www/server/mysql/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x1fe320e]
  26. /www/server/mysql/bin/mysqld(print_fatal_signal(int)+0x3a3) [0x107e883]
  27. /www/server/mysql/bin/mysqld(my_server_abort()+0x5e) [0x107e98e]
  28. /www/server/mysql/bin/mysqld(my_abort()+0xa) [0x1fdd96a]
  29. /www/server/mysql/bin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x30c) [0x22259ec]
  30. /www/server/mysql/bin/mysqld(TrxUndoRsegsIterator::set_next()+0x5f1) [0x21e6dd1]
  31. /www/server/mysql/bin/mysqld() [0x21e6e5f]
  32. /www/server/mysql/bin/mysqld() [0x21e7dc8]
  33. /www/server/mysql/bin/mysqld(trx_purge(unsigned long, unsigned long, bool)+0x13d) [0x21eabdd]
  34. /www/server/mysql/bin/mysqld(srv_purge_coordinator_thread()+0xb72) [0x21c3882]
  35. /www/server/mysql/bin/mysqld(std::thread::_State_impl＜std::thread::_Invoker＜std::tuple＜Detached_thread, void (*)()＞ ＞ ＞::_M_run()+0xb4) [0x20e3374]
  36. /www/server/mysql/bin/mysqld() [0x280f0cf]
  37. /lib64/libpthread.so.0(+0x7ea5) [0x2ac6e6256ea5]
  38. /lib64/libc.so.6(clone+0x6d) [0x2ac6e7d0eb0d]
  40. Trying to get some variables.
  41. Some pointers may be invalid and cause the dump to abort.
  42. Query (0): is an invalid pointer
  43. Connection ID (thread ID): 0
  44. Status: NOT_KILLED
  46. The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
  47. information that should help you find out what is causing the crash.
复制代码
百度搜了一下之后说大概是执行的SQL有问题，然后我就想看下MySQL的BinLog日记，但是在服务器执行的时候发现：

但是我明明是有mysql的，mysql和mysqlbinlog正常来说都是在一起的，一番查找之后原因是：我用了宝塔，宝塔的mysqlbinlog日记地址是
   /www/server/mysql/bin
  这内里的
2、分析binlog日记

./mysqlbinlog --start-datetime=“2024-04-16 02:00:00” /home/mysql/mysql-bin.000007
大概看了binlog日记，发现最后几条的sql并没有问题，然后我就觉得大概率是由于服务器是突然断点重启的，但是此时正在执行sql，造成innodb数据库文件出现错误的原因
（已脱敏数据）
  1. #240416  2:00:56 server id 1  end_log_pos 651706988 CRC32 0xecb191f3         Xid = 25647715
  2. COMMIT/*!*/;
  3. # at 651706988
  4. #240416  2:00:56 server id 1  end_log_pos 651707067 CRC32 0x8d36daa2         Anonymous_GTID        last_committed=634356        sequence_number=634357        rbr_only=no        original_committed_timestamp=1713204056015478        immediate_commit_timestamp=1713204056015478        transaction_length=934
  5. # original_commit_timestamp=1713204056015478 (2024-04-16 02:00:56.015478 CST)
  6. # immediate_commit_timestamp=1713204056015478 (2024-04-16 02:00:56.015478 CST)
  7. /*!80001 SET @@session.original_commit_timestamp=1713204056015478*//*!*/;
  8. /*!80014 SET @@session.original_server_version=80036*//*!*/;
  9. /*!80014 SET @@session.immediate_server_version=80036*//*!*/;
  10. SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
  11. # at 651707067
  12. #240416  2:00:56 server id 1  end_log_pos 651707162 CRC32 0x156f48b9         Query        thread_id=2911        exec_time=0        error_code=0
  13. SET TIMESTAMP=1713204056/*!*/;
  14. BEGIN
  15. /*!*/;
  16. # at 651707162
  17. #240416  2:00:56 server id 1  end_log_pos 651707435 CRC32 0x9dd48b58         Query        thread_id=2911        exec_time=0        error_code=0
  18. SET TIMESTAMP=1713204056/*!*/;
  19. UPDATE QRTZ_TRIGGERS SET TRIGGER_STATE = 'ACQUIRED' WHERE SCHED_NAME = 'schedulerName' AND TRIGGER_NAME AND TRIGGTE = 'WAITING'
  20. /*!*/;
  21. # at 651707435
  22. #240416  2:00:56 server id 1  end_log_pos 651707891 CRC32 0x35e6afbf         Query        thread_id=2911        exec_time=0        error_code=0
  23. SET TIMESTAMP=1713204056/*!*/;
  24. INSERT INTO QRTZ_FIRED_TRIGGERS (SCHED_NAME, ENTRY_ID, TRIGGER_NAME, TRIGGER_GROUP, INSTANCE_NAME, FIRED_TIME 5)
  25. /*!*/;
  26. # at 651707891
  27. #240416  2:00:56 server id 1  end_log_pos 651707922 CRC32 0x451c13c4         Xid = 25647718
  28. COMMIT/*!*/;
  29. # at 651707922
  30. #240416  2:00:56 server id 1  end_log_pos 651708001 CRC32 0xae4efe8c         Anonymous_GTID        last_committed=634357        sequence_number=634358        rbr_only=no        original_committed_timestamp=1713204056017004        immediate_commit_timestamp=1713204056017004        transaction_length=548
  31. # original_commit_timestamp=1713204056017004 (2024-04-16 02:00:56.017004 CST)
  32. # immediate_commit_timestamp=1713204056017004 (2024-04-16 02:00:56.017004 CST)
  33. /*!80001 SET @@session.original_commit_timestamp=1713204056017004*//*!*/;
  34. /*!80014 SET @@session.original_server_version=80036*//*!*/;
  35. /*!80014 SET @@session.immediate_server_version=80036*//*!*/;
  36. SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
  37. # at 651708001
  38. #240416  2:00:56 server id 1  end_log_pos 651708118 CRC32 0x1f8b6580         Query        thread_id=2882        exec_time=0        error_code=0
  39. SET TIMESTAMP=1713204056/*!*/;
  40. BEGIN
  41. /*!*/;
  42. # at 651708118
  43. #240416  2:00:56 server id 1  end_log_pos 651708439 CRC32 0xb4b71846         Query        thread_id=2882        exec_time=0        error_code=0
  44. SET TIMESTAMP=1713204056/*!*/;
  45. UPDATE infra_job_log  SET end_time='2024-04-16 02:00:56.015004', duration=5, status=1, result='执行支付通知 0 个',  update_time='2024-04-16 02:00:56.015661',  updater=null  WHERE id=383950 AND deleted=0
  46. /*!*/;
  47. # at 651708439
  48. #240416  2:00:56 server id 1  end_log_pos 651708470 CRC32 0x93c3d766         Xid = 25647730
  49. COMMIT/*!*/;
  50. # at 651708470
  51. #240416  2:00:56 server id 1  end_log_pos 651708549 CRC32 0x75b1af91         Anonymous_GTID        last_committed=634358        sequence_number=634359        rbr_only=no        original_committed_timestamp=1713204056020270        immediate_commit_timestamp=1713204056020270        transaction_length=938
  52. # original_commit_timestamp=1713204056020270 (2024-04-16 02:00:56.020270 CST)
  53. # immediate_commit_timestamp=1713204056020270 (2024-04-16 02:00:56.020270 CST)
  54. /*!80001 SET @@session.original_commit_timestamp=1713204056020270*//*!*/;
  55. /*!80014 SET @@session.original_server_version=80036*//*!*/;
  56. /*!80014 SET @@session.immediate_server_version=80036*//*!*/;
  57. SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
  58. # at 651708549
  59. #240416  2:00:56 server id 1  end_log_pos 651708644 CRC32 0x82977794         Query        thread_id=2915        exec_time=0        error_code=0
  60. SET TIMESTAMP=1713204056/*!*/;
  61. BEGIN
  62. /*!*/;
  63. # at 651708644
  64. #240416  2:00:56 server id 1  end_log_pos 651708905 CRC32 0xa05db17c         Query        thread_id=2915        exec_time=0        error_code=0
  65. SET TIMESTAMP=1713204056/*!*/;
  66. UPDATE QRTZ_TRIGGERS SET TRIG'BLOCKED'
  67. /*!*/;
  68. # at 651708905
  69. #240416  2:00:56 server id 1  end_log_pos 651709172 CRC32 0xf8de225b         Query        thread_id=2915        exec_time=0        error_code=0
  70. SET TIMESTAMP=1713204056/*!*/;
  71. UPDATE QRTZ_TRIGGERSE = 'PAUSED_BLOCKED'
  72. /*!*/;
  73. # at 651709172
  74. #240416  2:00:56 server id 1  end_log_pos 651709377 CRC32 0xb4ef1017         Query        thread_id=2915        exec_time=0        error_code=0
  75. SET TIMESTAMP=1713204056/*!*/;
  76. DELETE FROM QRTZ_FIRED_TRIGGERS WHERE SCHED_NAME = 'schedulerName' AND
  77. /*!*/;
  78. # at 651709377
  79. #240416  2:00:56 server id 1  end_log_pos 651709408 CRC32 0xfc3cd382         Xid = 25647729
  80. COMMIT/*!*/;
  81. # at 651709408
  82. #240416  2:00:56 server id 1  end_log_pos 651709487 CRC32 0x90969279         Anonymous_GTID        last_committed=634359        sequence_number=634360        rbr_only=no        original_committed_timestamp=1713204056026583        immediate_commit_timestamp=1713204056026583        transaction_length=955
  83. # original_commit_timestamp=1713204056026583 (2024-04-16 02:00:56.026583 CST)
  84. # immediate_commit_timestamp=1713204056026583 (2024-04-16 02:00:56.026583 CST)
  85. /*!80001 SET @@session.original_commit_timestamp=1713204056026583*//*!*/;
  86. /*!80014 SET @@session.original_server_version=80036*//*!*/;
  87. /*!80014 SET @@session.immediate_server_version=80036*//*!*/;
  88. SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
  89. # at 651709487
  90. #240416  2:00:56 server id 1  end_log_pos 651709582 CRC32 0x954d1385         Query        thread_id=2882        exec_time=0        error_code=0
  91. SET TIMESTAMP=1713204056/*!*/;
  92. BEGIN
  93. /*!*/;
  94. # at 651709582
  95. #240416  2:00:56 server id 1  end_log_pos 651709855 CRC32 0x4443046e         Query        thread_id=2882        exec_time=0        error_code=0
  96. SET TIMESTAMP=1713204056/*!*/;
  97. UPDATE QRTZ_TRIGGERS SET TRIGGER_STATE = 'WAITISTATE = 'ACQUIRED'
  98. /*!*/;
  99. # at 651709855
  100. #240416  2:00:56 server id 1  end_log_pos 651710127 CRC32 0x2a9b0ef0         Query        thread_id=2882        exec_time=0        error_code=0
  101. SET TIMESTAMP=1713204056/*!*/;
  102. UPDATE QRTZ_TRIGGERS
  103. /*!*/;
  104. # at 651710127
  105. #240416  2:00:56 server id 1  end_log_pos 651710332 CRC32 0xd8fea345         Query        thread_id=2882        exec_time=0        error_code=0
  106. SET TIMESTAMP=1713204056/*!*/;
  107. DELETE FROM QRTZ_FIRED_TR
  108. /*!*/;
  109. # at 651710332
  110. #240416  2:00:56 server id 1  end_log_pos 651710363 CRC32 0xc4b82dea         Xid = 25647738
  111. COMMIT/*!*/;
  112. # at 651710363
  113. #240416  2:00:56 server id 1  end_log_pos 651710442 CRC32 0x1990f6bf         Anonymous_GTID        last_committed=634360        sequence_number=634361        rbr_only=no        original_committed_timestamp=1713204056032340        immediate_commit_timestamp=1713204056032340        transaction_length=928
  114. # original_commit_timestamp=1713204056032340 (2024-04-16 02:00:56.032340 CST)
  115. # immediate_commit_timestamp=1713204056032340 (2024-04-16 02:00:56.032340 CST)
  116. /*!80001 SET @@session.original_commit_timestamp=1713204056032340*//*!*/;
  117. /*!80014 SET @@session.original_server_version=80036*//*!*/;
  118. /*!80014 SET @@session.immediate_server_version=80036*//*!*/;
  119. SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
  120. # at 651710442
  121. #240416  2:00:56 server id 1  end_log_pos 651710537 CRC32 0x15fddec2         Query        thread_id=2882        exec_time=0        error_code=0
  122. SET TIMESTAMP=1713204056/*!*/;
  123. BEGIN
  124. /*!*/;
  125. # at 651710537
  126. #240416  2:00:56 server id 1  end_log_pos 651710807 CRC32 0x87d15abb         Query        thread_id=2882        exec_time=0        error_code=0
  127. SET TIMESTAMP=1713204056/*!*/;
  128. UPDATE QRTZ_TRIGGERS SET TRSTATE = 'WAITING'
  129. /*!*/;
  130. # at 651710807
  131. #240416  2:00:56 server id 1  end_log_pos 651711260 CRC32 0xb988e5b0         Query        thread_id=2882        exec_time=0        error_code=0
  132. SET TIMESTAMP=1713204056/*!*/;
  133. INSERT INTO
  134. /*!*/;
  135. # at 651711260
  136. #240416  2:00:56 server id 1  end_log_pos 651711291 CRC32 0x889caa0e         Xid = 25647746
  137. COMMIT/*!*/;
  138. SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
  139. DELIMITER ;
  140. # End of log file
  141. /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
  142. /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
复制代码
3、数据规复

既然原因大概就是如许，我们如今得解决数据规复的问题，既然是innodb文件的问题，那这个库我的想法就是别用了，导出原有数据库的文件，然后新建一个库，毕竟Innodb的文件我也实在不知道怎么修复，但是如今由于mysql启动不了无法导出数据，按照错误信息的提示，我们在mysql的配置文件中加入以下内容：
  1. # 强制启用恢复模式
  2. innodb_force_recovery = 1
复制代码
其中参数的含义是：


  • 1 （SRV_FORCE_IGNORE_CORRUPT)
    即使检测到损坏的页面，也允许服务器运行。尝试使 SELECT * FROM *tbl_name*跳过损坏的索引记载和页面，这有助于转储表。
  • 2 （SRV_FORCE_NO_BACKGROUND)
    阻止主线程和任何扫除线程运行。如果在扫除操作期间发生意外退出，则此规复值会阻止它。
  • 3 （SRV_FORCE_NO_TRX_UNDO)
    瓦解规复后不运行事件回滚.
  • 4 （SRV_FORCE_NO_IBUF_MERGE)
    阻止插入缓冲区归并操作。如果它们会导致瓦解，请不要如许做。不计算表统计信息。此值大概会永久损坏数据文件。利用此值后，请预备好删除并重新创建所有二级索引。将 InnoDB 设置为只读。
  • 5 （SRV_FORCE_NO_UNDO_LOG_SCAN)
    启动数据库时不查看撤消日记：InnoDB 甚至将未完成的事件视为已提交。此值大概会永久损坏数据文件。将 InnoDB 设置为只读。
  • 6（SRV_FORCE_NO_LOG_REDO)
    不执行与规复相干的重做日记前滚。此值大概会永久损坏数据文件。使数据库页处于过期状态，这反过来又大概会给 B 树和其他数据库结构带来更多损坏。将 InnoDB 设置为只读。
建议从1开始徐徐往上尝试启动，我是尝试到4之后才启动乐成的。
启动乐成之后我们此时不要就如许用了！由于我们利用的是规复模式运行的，顾名思义就是用来规复数据的！
启动乐成后我们在利用dump导出一下数据库的结构和数据(我用的是宝塔就直接点击备份数据了)

备份乐成之后我们就可以删除原来的数据库了，由于原来数据库的innodb文件已经损坏了，利用宝塔也删不掉这个数据库，我就想直接删除MySQL的数据文件
4、删除原来数据库

由于利用的是规复模式，而且innodb的文件已经损坏了，所以我们可以找到mysql配置文件，找到对应的数据文件，然后利用rm -rf 文件删撤除原有的数据库文件。
   数据无价！！！
  确保已备份全部数据！！！！！！！！
  1. # 删除宝塔的MySQL数据
  2. rm -rf /www/server/mysql
复制代码
删除完之后，我们重新安装数据库，接着把直接备份的数据库重新导入，MySQL就可以正常启动了。
版权所有：XuanRan
未经书面授权，禁止转载！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看，没有账号？立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览
返回列表

快速回复

高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

渣渣兔

论坛元老
这个人很懒什么都没写!

楼主热帖

标签云

集成商 AI 运维 CIO 存储 服务器
微信订阅号
微信服务号
微信客服
小程序
H5
关于我们 商务合作 网站地图
©Copyright 2022-2024 杭州祥升科技有限公司 版权所有 浙ICP备20004199号
快速回复 返回顶部 返回列表