MySQL在生产环境出现无法启动的问题解决

于 2024-04-16 13:52:29 发布
阅读量1.2k 收藏 24
点赞数 14
分类专栏： MySQL 文章标签： mysql 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_37945670/article/details/137822464
版权

MySQL在生产环境出现无法启动的问题解决

1、事由

今天现服务器重启了，然后服务器启动完成之后我发现为啥后端程序没有启动，排查之后发现是MySQL没有启动连接不上数据库，错误信息如下：

2024-04-16T02:34:01.507696Z 0 [Warning] [MY-000081] [Server] option ＇max_allowed_packet＇: unsigned value 107374182400 adjusted to 1073741824.
2024-04-16T02:34:01.507749Z 0 [Warning] [MY-011070] [Server] ＇binlog_format＇ is deprecated and will be removed in a future release.
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.
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.
2024-04-16T02:34:01.507955Z 0 [System] [MY-010116] [Server] /www/server/mysql/bin/mysqld (mysqld 8.0.36) starting as process 7075
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.
2024-04-16T02:34:01.526764Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-04-16T02:34:02.677451Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2024-04-16T02:34:02.975637Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: trx0types.h:541:m_rsegs_n ＜ 2 thread 47034609473280
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2024-04-16T02:34:02Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=911887188a59108d0b2707ced3fa0b5872644b4f
Thread pointer: 0x2ac79c0008c0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 2ac7193089e8 thread_stack 0x100000
/www/server/mysql/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x1fe320e]
/www/server/mysql/bin/mysqld(print_fatal_signal(int)+0x3a3) [0x107e883]
/www/server/mysql/bin/mysqld(my_server_abort()+0x5e) [0x107e98e]
/www/server/mysql/bin/mysqld(my_abort()+0xa) [0x1fdd96a]
/www/server/mysql/bin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x30c) [0x22259ec]
/www/server/mysql/bin/mysqld(TrxUndoRsegsIterator::set_next()+0x5f1) [0x21e6dd1]
/www/server/mysql/bin/mysqld() [0x21e6e5f]
/www/server/mysql/bin/mysqld() [0x21e7dc8]
/www/server/mysql/bin/mysqld(trx_purge(unsigned long, unsigned long, bool)+0x13d) [0x21eabdd]
/www/server/mysql/bin/mysqld(srv_purge_coordinator_thread()+0xb72) [0x21c3882]
/www/server/mysql/bin/mysqld(std::thread::_State_impl＜std::thread::_Invoker＜std::tuple＜Detached_thread, void (*)()＞ ＞ ＞::_M_run()+0xb4) [0x20e3374]
/www/server/mysql/bin/mysqld() [0x280f0cf]
/lib64/libpthread.so.0(+0x7ea5) [0x2ac6e6256ea5]
/lib64/libc.so.6(clone+0x6d) [0x2ac6e7d0eb0d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): is an invalid pointer
Connection ID (thread ID): 0
Status: NOT_KILLED

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
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数据库文件出现错误的原因

（已脱敏数据）

#240416  2:00:56 server id 1  end_log_pos 651706988 CRC32 0xecb191f3 	Xid = 25647715
COMMIT/*!*/;
# at 651706988
#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
# original_commit_timestamp=1713204056015478 (2024-04-16 02:00:56.015478 CST)
# immediate_commit_timestamp=1713204056015478 (2024-04-16 02:00:56.015478 CST)
/*!80001 SET @@session.original_commit_timestamp=1713204056015478*//*!*/;
/*!80014 SET @@session.original_server_version=80036*//*!*/;
/*!80014 SET @@session.immediate_server_version=80036*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 651707067
#240416  2:00:56 server id 1  end_log_pos 651707162 CRC32 0x156f48b9 	Query	thread_id=2911	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
BEGIN
/*!*/;
# at 651707162
#240416  2:00:56 server id 1  end_log_pos 651707435 CRC32 0x9dd48b58 	Query	thread_id=2911	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
UPDATE QRTZ_TRIGGERS SET TRIGGER_STATE = 'ACQUIRED' WHERE SCHED_NAME = 'schedulerName' AND TRIGGER_NAME AND TRIGGTE = 'WAITING'
/*!*/;
# at 651707435
#240416  2:00:56 server id 1  end_log_pos 651707891 CRC32 0x35e6afbf 	Query	thread_id=2911	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
INSERT INTO QRTZ_FIRED_TRIGGERS (SCHED_NAME, ENTRY_ID, TRIGGER_NAME, TRIGGER_GROUP, INSTANCE_NAME, FIRED_TIME 5)
/*!*/;
# at 651707891
#240416  2:00:56 server id 1  end_log_pos 651707922 CRC32 0x451c13c4 	Xid = 25647718
COMMIT/*!*/;
# at 651707922
#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
# original_commit_timestamp=1713204056017004 (2024-04-16 02:00:56.017004 CST)
# immediate_commit_timestamp=1713204056017004 (2024-04-16 02:00:56.017004 CST)
/*!80001 SET @@session.original_commit_timestamp=1713204056017004*//*!*/;
/*!80014 SET @@session.original_server_version=80036*//*!*/;
/*!80014 SET @@session.immediate_server_version=80036*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 651708001
#240416  2:00:56 server id 1  end_log_pos 651708118 CRC32 0x1f8b6580 	Query	thread_id=2882	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
BEGIN
/*!*/;
# at 651708118
#240416  2:00:56 server id 1  end_log_pos 651708439 CRC32 0xb4b71846 	Query	thread_id=2882	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
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
/*!*/;
# at 651708439
#240416  2:00:56 server id 1  end_log_pos 651708470 CRC32 0x93c3d766 	Xid = 25647730
COMMIT/*!*/;
# at 651708470
#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
# original_commit_timestamp=1713204056020270 (2024-04-16 02:00:56.020270 CST)
# immediate_commit_timestamp=1713204056020270 (2024-04-16 02:00:56.020270 CST)
/*!80001 SET @@session.original_commit_timestamp=1713204056020270*//*!*/;
/*!80014 SET @@session.original_server_version=80036*//*!*/;
/*!80014 SET @@session.immediate_server_version=80036*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 651708549
#240416  2:00:56 server id 1  end_log_pos 651708644 CRC32 0x82977794 	Query	thread_id=2915	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
BEGIN
/*!*/;
# at 651708644
#240416  2:00:56 server id 1  end_log_pos 651708905 CRC32 0xa05db17c 	Query	thread_id=2915	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
UPDATE QRTZ_TRIGGERS SET TRIG'BLOCKED'
/*!*/;
# at 651708905
#240416  2:00:56 server id 1  end_log_pos 651709172 CRC32 0xf8de225b 	Query	thread_id=2915	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
UPDATE QRTZ_TRIGGERSE = 'PAUSED_BLOCKED'
/*!*/;
# at 651709172
#240416  2:00:56 server id 1  end_log_pos 651709377 CRC32 0xb4ef1017 	Query	thread_id=2915	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
DELETE FROM QRTZ_FIRED_TRIGGERS WHERE SCHED_NAME = 'schedulerName' AND 
/*!*/;
# at 651709377
#240416  2:00:56 server id 1  end_log_pos 651709408 CRC32 0xfc3cd382 	Xid = 25647729
COMMIT/*!*/;
# at 651709408
#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
# original_commit_timestamp=1713204056026583 (2024-04-16 02:00:56.026583 CST)
# immediate_commit_timestamp=1713204056026583 (2024-04-16 02:00:56.026583 CST)
/*!80001 SET @@session.original_commit_timestamp=1713204056026583*//*!*/;
/*!80014 SET @@session.original_server_version=80036*//*!*/;
/*!80014 SET @@session.immediate_server_version=80036*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 651709487
#240416  2:00:56 server id 1  end_log_pos 651709582 CRC32 0x954d1385 	Query	thread_id=2882	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
BEGIN
/*!*/;
# at 651709582
#240416  2:00:56 server id 1  end_log_pos 651709855 CRC32 0x4443046e 	Query	thread_id=2882	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
UPDATE QRTZ_TRIGGERS SET TRIGGER_STATE = 'WAITISTATE = 'ACQUIRED'
/*!*/;
# at 651709855
#240416  2:00:56 server id 1  end_log_pos 651710127 CRC32 0x2a9b0ef0 	Query	thread_id=2882	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
UPDATE QRTZ_TRIGGERS 
/*!*/;
# at 651710127
#240416  2:00:56 server id 1  end_log_pos 651710332 CRC32 0xd8fea345 	Query	thread_id=2882	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
DELETE FROM QRTZ_FIRED_TR
/*!*/;
# at 651710332
#240416  2:00:56 server id 1  end_log_pos 651710363 CRC32 0xc4b82dea 	Xid = 25647738
COMMIT/*!*/;
# at 651710363
#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
# original_commit_timestamp=1713204056032340 (2024-04-16 02:00:56.032340 CST)
# immediate_commit_timestamp=1713204056032340 (2024-04-16 02:00:56.032340 CST)
/*!80001 SET @@session.original_commit_timestamp=1713204056032340*//*!*/;
/*!80014 SET @@session.original_server_version=80036*//*!*/;
/*!80014 SET @@session.immediate_server_version=80036*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 651710442
#240416  2:00:56 server id 1  end_log_pos 651710537 CRC32 0x15fddec2 	Query	thread_id=2882	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
BEGIN
/*!*/;
# at 651710537
#240416  2:00:56 server id 1  end_log_pos 651710807 CRC32 0x87d15abb 	Query	thread_id=2882	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
UPDATE QRTZ_TRIGGERS SET TRSTATE = 'WAITING'
/*!*/;
# at 651710807
#240416  2:00:56 server id 1  end_log_pos 651711260 CRC32 0xb988e5b0 	Query	thread_id=2882	exec_time=0	error_code=0
SET TIMESTAMP=1713204056/*!*/;
INSERT INTO
/*!*/;
# at 651711260
#240416  2:00:56 server id 1  end_log_pos 651711291 CRC32 0x889caa0e 	Xid = 25647746
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

3、数据恢复

既然原因大概就是这样，我们现在得解决数据恢复的问题，既然是innodb文件的问题，那这个库我的想法就是别用了，导出原有数据库的文件，然后新建一个库，毕竟Innodb的文件我也实在不知道怎么修复，但是现在由于mysql启动不了无法导出数据，按照错误信息的提示，我们在mysql的配置文件中加入以下内容：

# 强制启用恢复模式
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 文件删除掉原有的数据库文件。

数据无价！！！

确保已备份全部数据！！！！！！！！

# 删除宝塔的MySQL数据
rm -rf /www/server/mysql

删除完之后，我们重新安装数据库，接着把直接备份的数据库重新导入，MySQL就可以正常启动了。

版权所有：XuanRan

未经书面授权，禁止转载！

XuanRanDev
关注
  • 14
    点赞
  • 踩
  • 24
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
MySQLDBA运维笔记.pdf
11-04
1.5 生产环境关闭 mysql 的命令..........................................................................................22 1.5.1 生产环境不能用强制命令关闭 mysql 服务 .....................................
Mariadb远程登陆配置及问题解决
12-14
当然，在测试和解决问题之前，得首先保证你的数据库与远程主机之间的网络通信没有问题，简单的来说，就是互相ping通，其次，为了避免防火墙的干扰，将本地主机和数据库主机的防火墙都关闭，当然，生产环境下防火墙...
mysql [ERROR] [MY-013183] [InnoDB] Assertion failure: fil0fil.cc:10754 Status: NOT_KILLED
weixin_44696445的博客
05-30 1263
启动数据库，随后找到mysql数据目录 /var/lib/mysql,将 出现问题的数据库删除，再将innodb_force_recovery修改为0启动数据库。innodb_force_recovery 从0-6以此重启，但是到6可以重启，重启完成后也无法使用。恢复数据库时导致服务器磁盘满了，mysql宕机，重启报错。2.网上搜索很多方面解决办法。1.mysql启动报错。再附一个详细有用的链接。
mysqld - 官方详细文档（MySQL社区版Ver 8.0.20 for Win64）_1
ctrigger的专栏
04-29 785
mysqld.exe Ver 8.0.20 for Win64 on x86_64 (MySQL Community Server - GPL) Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corpo...
mysql突然挂掉，一直启动不了，那位大神路过帮忙看看呗！！
weixin_38732963的博客
07-28 1696
急，有哪位mysql大神给解答一下，万分感激； 数据库突然关闭，然后就启动不了了，报错如下： 200728 10:38:32 mysqld_safe Starting mysqld daemon with databases from /www/server/data 2020-07-28 10:38:33 22496615563072 [Warning] option 'max_allowed_packet': unsigned value 107374182400 adjusted to 1073741
CentOS 7 下安装 MySQL 8.x
Practitioner
10-05 799
如果要远程访问 MySQL，操作系统需要打开 MySQL 的默认 3306 端口的访问权限。创建一个用户名为 dump 的用户，密码初始化为 1234（可根据自定义需求修改）目录下并解压，并将解压后的 mysql 安装目录中的内容放入。赋予权限，并配置可访问的 ip（可根据自定义需求修改）这样就可以通过如下命令进行 MySQL 的启动了。将下载好的 MySQL 安装包上传至服务器的。修改配置之前，一个比较好的习惯的是先备份配置。出来的文件没有需要保留的文件，也可以执行。MySQL 的配置文件默认位置是。
mysql8.0以上版本安装出现问题
clionliang的博客
06-13 7973
mysql的安装，8.0以上的版本会遇到一些问题
mysql ping 崩溃_MySQL之——崩溃-修复损坏的innodb：innodb_force_recovery
weixin_39645308的博客
01-20 639
转： https://blog.csdn.net/l1028386804/article/details/77199194一、问题描述今天在线运行的一个mysql崩溃了。查看错误日志，如下：-----------------------------------------161108 11:36:45 mysqld_safe Starting mysqld daemon with database...
Mysql集群配置.docx
最新发布
09-18
随着人们对业务的要求和用用户的...我们将可将应用服务再整合，搭建一个集群环境，保证能够把出现问题的机器自动启动，使其恢复到初始状态。而且在整个服务切换过程中，不需要任何的人为干预。这也是高效能的解决方案
2017最新老男孩MySQL高级专业DBA实战课程全套【清晰不加密】，看完教程月入40万没毛病
06-23
28-MySQL数据库多实例启动问题排错方法及实战排错.avi 29-MySQL数据库多实例实战排错02.avi 30-增加MySQL数据库第三个实例实战讲解.avi 31-MySQL数据库多实例的其他故障问题说明.avi 第三部：MySQL应用管理及进阶...
教您修复mysql数据库的方法
01-19
会mysql的朋友都知道mysql在长时间使用过后数据库会出现一些问题，这就需要快速修复损坏mysql数据库以方便我们的工作和学习。下面小编为大家下面介绍两种快速检修 MySQL 数据库的方法。 本人常用这样的代码，直接放到mysql数据库目录里面 代码如下:cmd /k myisamchk -r jb51_tablenamejb51_tablename是jb51_tablename.MYD的名称。运行以下就可以了。 有的时候因为掉电或者其他原因导致数据库损坏,我们可以使用mysql自带的mysqlcheck命令来快速修复所有的数据库或者特定的数据库;例如 检查优化并修复所有的数据库用: 1
Mysql集群配置
11-30
项目背景 随着人们对业务的要求...我们将可将应用服务再整合，搭建一个集群环境，保证能够把出现问题的机器自动启动，使其恢复到初始状态。而且在整个服务切换过程中，不需要任何的人为干预。这也是高效能的解决方案。
mysql 报错 this error can also be caused by malfunctioning hardware 导致重启 数据库损坏 简介
whatday的专栏
08-31 4397
InnoDB: broken FIL_PAGE_NEXT or FIL_PAGE_PREV links，innodb 数据页双向链表出现问题(比如FILE_PAGE_NEXT指定下一个页是 page:32 ,但是读取到的页号却不是32)日志开头 Assertion failure: btr0pcur.cc:318:page_is_comp(next_page) == page_is_comp(page)，扫描全表时遇到坏块。研发兄弟反馈说，他们的压测数据库中有一些表不能正常查询。...
Assertion failure错误 更新【已解决】
qq_34028848的博客
12-17 5899
点击file 打开project structure 然后打开tomcat 重启 成功打包
win10 安装mysql8.0 主从复制
黄泉路的博客
03-04 380
mysql安装包地址mysql8.0 64位 免安装 一 基础配置 下载下来然后解压到目录下复制一份出来 ,我的命名如下 然后进入master和slave文件夹 创建文件夹 data和config文件夹 进入master的config文件夹创建文件my.ini,把下面的配置复制进去: [mysqld] [client] port=3307 default-character-set=UTF8MB4 [mysqld] server_id=1 ......
MySQL日志文件总结
zhangyuanshuai的博客
05-17 1185
MySQL日志文件 MySQL 服务器会产生很多日志，这些日志有些有助于分析问题，有些用于主从复制、崩溃恢复。有些日志仅特定存储引擎才有。MySQL 服务器产生的日志有一下几种： 错误日志（error log） 该日志记录了 MySQL 服务器的启动和关闭，以及发生错误时的相关异常信息。 如果没做特殊配置，该日志默认是在控制台输出的，可以通过修改配置文件的形式启用。 如：修改 MySQL 配置文件 [mysqld] server-id=1 log_error=mysql_errlog.err 通过 log
MySQL 服务无法启动如何解决
热门推荐
qq_41847894的博客
05-12 5万+
用管理员身份打开cmd试图启动MySQL时出现如下情况： 一个亲测有效的解决办法： 1.进入MySQL安装目录bin的路径下，输入命令 netstat -ano ，找到3306接口的PID值。 2.打开任务管理器，找到对应PID的mysql进程，右击关闭，下图已关闭完成。（点击PID进行PID值排序可方便查找） 3.重新输入命令net start mysql，服务就能启动成功了。 ...
docker部署生产环境的mysql
08-14
### 回答1： 很高兴回答您的问题。Docker可以用于部署生产环境的MySQL，您可以使用Docker容器来构建MySQL服务器，并且可以让您更快、更安全地设置和部署MySQL服务器。Docker可以帮助您更轻松地实施MySQL，同时仍然可以保持高性能、可靠性和稳定性。 ### 回答2： 在生产环境中，使用Docker来部署MySQL数据库是一个行之有效且推荐的解决方案。以下是使用Docker部署生产环境的MySQL的步骤： 首先，我们需要确保所需的MySQL镜像可从Docker Hub获取。我们可以使用以下命令拉取最新版本的MySQL镜像： ``` docker pull mysql:latest ``` 在拉取镜像之后，我们可以通过运行以下命令创建并启动一个MySQL容器： ``` docker run -p 3306:3306 --name mysql-container -e MYSQL_ROOT_PASSWORD=password -d mysql:latest ``` 在此命令中，我们使用`-p`参数将主机的端口 3306 映射到容器的端口 3306，以便可以在主机上访问MySQL服务。`--name`参数为容器指定一个名称，方便后续管理。`-e`参数用于指定环境变量，这里我们设置了MySQL的root用户密码为"password"。`-d`参数将容器以守护进程方式运行。 成功创建并启动容器后，我们可以使用以下命令来连接到MySQL服务： ``` docker exec -it mysql-container mysql -u root -p ``` 这将在容器的命令行中启动MySQL客户端，并要求输入密码。输入之前设置的密码即可登录到MySQL。 一旦登录成功，我们可以像在常规的MySQL服务器上一样管理MySQL数据库，例如创建新的数据库、用户、表等。 在部署生产环境的MySQL时，我们还应该考虑对数据进行备份和持久化处理。我们可以使用Docker数据卷来实现这一点，将MySQL的数据存储在宿主机器的持久化目录中。 以上是使用Docker部署生产环境的MySQL的基本步骤。通过使用Docker，我们可以轻松地在任何环境中部署和管理MySQL数据库，并确保其稳定性和可靠性。 ### 回答3： Docker是一种容器化技术，可以帮助开发者更方便地部署和管理应用程序。在生产环境中使用Docker部署MySQL数据库可以带来许多好处。 首先，使用Docker可以快速部署MySQL数据库。只需在Docker上运行一个MySQL容器，就可以快速搭建一个完整的MySQL环境。这样可以大大简化部署过程，节省时间和精力。 其次，Docker使得MySQL的部署和配置变得可重复和可移植。可以将整个MySQL容器保存为镜像，然后在不同的服务器或环境中轻松部署。这样可以确保在不同的生产环境中都使用相同的数据库配置，减少因为环境差异而引发的问题。 此外，使用Docker可以更好地隔离MySQL数据库和其他应用程序。每个Docker容器都运行在独立的隔离环境中，这样可以避免不同应用程序之间的相互影响。同时，可以为每个MySQL容器指定特定的资源配额，以确保数据库性能和稳定性。 最后，Docker提供了便捷的监控和管理工具。可以使用Docker的CLI或图形化界面工具来监控MySQL容器的运行状态、日志输出和资源利用情况。此外，还可以使用Docker的自动化部署和扩容功能，根据需要自动创建和销毁MySQL容器，以实现弹性扩展。 综上所述，使用Docker部署MySQL数据库可以提高部署效率、保证配置一致性、隔离应用程序以及简化监控和管理。这些优势使得Docker成为生产环境中部署MySQL的理想选择。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值