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

于 2024-04-16 13:52:29 发布
阅读量1.3k 收藏 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
    评论
专栏目录
linux安装mysql-8.0.11出现错误
weixin影子的博客
04-16 3444
linux安装mysql-8.0.11出现 2020-04-16T11:47:06.723455Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this optio...
使用innodb_force_recovery解决MySQL崩溃无法重启问题
09-10
如果可能，最好在测试环境中先验证这种方法，避免在生产环境中造成不可逆的数据损失。 总结起来，`innodb_force_recovery`是一个在MySQL遇到严重崩溃时的应急工具，可以帮助数据库在某些情况下恢复服务，但并不能...
教您修复mysql数据库的方法
01-19
会mysql的朋友都知道mysql在长时间使用过后数据库会出现一些问题，这就需要快速修复损坏mysql数据库以方便我们的工作和学习。下面小编为大家下面介绍两种快速检修 MySQL 数据库的方法。 本人常用这样的代码，直接放到mysql数据库目录里面 代码如下:cmd /k myisamchk -r jb51_tablenamejb51_tablename是jb51_tablename.MYD的名称。运行以下就可以了。 有的时候因为掉电或者其他原因导致数据库损坏,我们可以使用mysql自带的mysqlcheck命令来快速修复所有的数据库或者特定的数据库;例如 检查优化并修复所有的数据库用: 1
mysqld - 官方详细文档（MySQL社区版Ver 8.0.20 for Win64）_1
ctrigger的专栏
04-29 793
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 1717
急，有哪位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 801
如果要远程访问 MySQL，操作系统需要打开 MySQL 的默认 3306 端口的访问权限。创建一个用户名为 dump 的用户，密码初始化为 1234（可根据自定义需求修改）目录下并解压，并将解压后的 mysql 安装目录中的内容放入。赋予权限，并配置可访问的 ip（可根据自定义需求修改）这样就可以通过如下命令进行 MySQL 的启动了。将下载好的 MySQL 安装包上传至服务器的。修改配置之前，一个比较好的习惯的是先备份配置。出来的文件没有需要保留的文件，也可以执行。MySQL 的配置文件默认位置是。
MySQL server has gone away 问题的解决方法
scropio0zry的博客
11-09 520
前段时间，应领导要求，把现网数据导入开发数据库中，报出MySQL server has gone away问题，经过排查发现是执行SQL时，SQL文件过大导致的   MySQL会根据配置文件会限制server接受的数据包的大小。如果写入大数据时，因为默认的配置太小，插入和更新操作会因为 max_allowed_packet 参数限制，而导致失败。   查看当前配置： mysql> ...
解决Linux下Mysql5.7忘记密码问题
09-09
4. 如果你在执行过程中遇到任何问题，如权限错误、服务无法启动等，可能需要检查系统的日志文件以获取更多信息。 总结来说，通过上述步骤，即使在Linux系统中忘记MySQL 5.7的root密码，也能成功地重置并恢复数据库...
mysql ERROR 1045 (28000)问题的解决方法
09-09
在日常操作中，应该避免在生产环境中长时间启用`skip-grant-tables`，因为它会严重降低系统的安全性。 如果你遇到了其他版本的MySQL安装问题，可以参考专门针对各个版本的MySQL安装教程，如mysql5.7、5.6和8.0等。...
最新Linux下安装mysql版本冲突问题解决.pdf
09-13
在Linux环境下，安装MySQL数据库时可能会遇到版本冲突的问题，尤其是当系统中已存在一个较低版本的MySQL服务时。...在部署生产环境时，建议先备份现有数据，并遵循官方文档或最佳实践来确保操作的安全性和可靠性。
在CentOS上安装搭建PHP+Apache+Mysql的服务器环境
09-15
1. 关闭防火墙服务（不推荐在生产环境中关闭）： ``` service iptables stop ``` 2. 再次尝试访问，如果能够正常访问，说明问题出在防火墙策略上。你应该根据需要调整防火墙规则，允许80端口的HTTP流量。 总的...
mysql 报错 this error can also be caused by malfunctioning hardware 导致重启 数据库损坏 简介
whatday的专栏
08-31 4459
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)，扫描全表时遇到坏块。研发兄弟反馈说，他们的压测数据库中有一些表不能正常查询。...
mysql binlog format_binlog之四：mysql中binlog_format模式与配置详解，binlog的日志格式详解...
weixin_42575505的博客
01-27 7827
mysql复制主要有三种方式：基于SQL语句的复制(statement-based replication, SBR)，基于行的复制(row-based replication, RBR)，混合模式复制(mixed-based replication, MBR)。对应的，binlog的格式也有三种：STATEMENT，ROW，MIXED。① STATEMENT模式(SBR)每一条会修改数据的sql...
写入MySQL报错超出 max_allowed_packet 的问题
热门推荐
sunny05296的博客
05-25 8万+
写入MySQL报错超出 max_allowed_packet 的问题。MySQL会根据配置文件会限制server接受的数据包的大小。如果写入大数据时，因为默认的配置太小，插入和更新操作会因为 max_allowed_packet 参数限制，而导致失败。查看当前配置：mysql> show variables like 'max_allowed_packet';+---------------...
服务器上的MySQL启动失败：Starting MySQL...The server quit without updating PID file
夜中听雪的博客
05-17 3453
mysql日志报错：Bind on unix socket: Address already in use。 解决方法：删除/tmp目录下的四个文件：mysql.sock.lock、mysql.sock、mysqlx.sock.lock、mysqlx.sock。
mysql InnoDB: Assertion failure in thread xxxx in file ut0mem.cc line 105
weixin_30376163的博客
08-29 3370
mysql InnoDB: Assertion failure in thread xxxx in file ut0mem.cc line 105 错误信息 InnoDB: Assertion failure in thread xxxx in file ut0mem.cc line 105 InnoDB: Failing assertion: ret || !assert_on_err...
mysql启动报sock_mysql启动错误：mysql.sock丢失问题处理
javanet001的博客
01-11 1626
备注：每个人出现的问题都不一样，根据错误日志逐步纠正，问题即可解决，摸索了几个小时，希望能帮到大家。第二步：重启mysql，systemctl restart mysqld，启动成功。第一步：找到mysqld.log ----- 我的log位置在var/log。颜色标记的地方是出现问题的，找到对应文件删除，重新建表导入数据即可。
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、付费专栏及课程。

余额充值