云服务器数据库服务会自动关闭,然后库表消失,像是重新初始化一样
Bug 描述
云服务器安装mysql数据库服务,但是启动服务之后创建库表,发现数据库服务会自动关闭
复现时机
没有找到复现规律
每次服务关闭库表消失,对应下面这两个文件都会发生改变

期望结果
希望可以能给出一些排查手段或者是解决措施
错误信息
自己的思路和解决方案
ai给出可能是OOM,但是发现日志没有说明是kill,然后也说可能是配置的原因但也修改了 适配 7.5G 内存服务器的安全配置
key_buffer_size=256M innodb_buffer_pool_size=3G innodb-buffer-pool-instances=3 read_buffer_size=64K sort_buffer_size=256K read_rnd_buffer_size=128K max_connections=500 不知道是不是我的错觉我没按ai改key_buffer_size这些配置之前,原来的配置是比这个大,那个时候6月12日启动服务6月17日才自动关闭,改了之后发现没有坚持一天,可能也不是这个原因
评论
相关内容
0个评论
全部评论
点击登录,快来和大家讨论吧~
表情
图片
暂无评论
内容推荐
云图库项目 ShardingSphere 5.2.x 下更新分片键导致的 UPDATE 失败问题分析与解决
6
Spring AI MCP Stdio 报错信息排查
9
记录一个 Idea 配置文件解析的问题,最近更新了 Idea 发现打开之前的项目的 application.yml 全部飘黄,更新之前是不存在的 key 飘黄,现在是全部都票黄了,看着非常难受。解决:File | Settings | Languages & Frameworks | Schemas and DTDs | Remote JSON Schemas 取消勾选 Use schemasto
7
LangChain4j 调用 DeepSeek 工具时报 400?用 pi 抓包定位,同包覆盖修复 reasoning_content
7
最近在使用ChatGPT/Codex过程中发现了一个官方bug:高频日志写盘,会损坏电脑磁盘的寿命。桌面版和CLI都有这个问题,目前最新版的ChatGPT/Codex还没有彻底解决这个问题(虽然官方自称已经修复了,但实测还是有高频日志写盘问题)。建议使用下面这段提示词发给AI让它检查和修复:帮我检查 ~./codex/logs_2.sqlite 是否因 TRACE 日志持续高频写盘;如果中招,先备
2
