Windows 11 Pro 上的 MariaDB 因权限表的文件问题而失败

Windows 11 Pro 上的 MariaDB 因权限表的文件问题而失败

大约 5-6 天后每个在 Windows 11 Pro(10.0.22621 Build 22621)上全新安装(最新的)XAMPP 8.2.4,并安装 MariaDB 10.4.28,每次运行时都会失败:

有时我会在 XAMPP 中直接收到错误:

Attempting to start MySQL app...
Status change detected: running
Status change detected: stopped
Error: MySQL shutdown unexpectedly.
This may be due to a blocked port, missing dependencies, 
improper privileges, a crash, or a shutdown by another method.

我完全是新手,但我认为没有什么“不寻常的”mysql_错误日志

[Note] Starting MariaDB 10.4.28-MariaDB source revision c8f2e9a5c0ac5905f28b050b7df5a9ffd914b7e7 as process 20488
[Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
[Note] InnoDB: Uses event mutexes
[Note] InnoDB: Compressed tables use zlib 1.2.12
[Note] InnoDB: Number of pools: 1
[Note] InnoDB: Using SSE2 crc32 instructions
[Note] InnoDB: Initializing buffer pool, total size = 16M, instances = 1, chunk size = 16M
[Note] InnoDB: Completed initialization of buffer pool
[Note] InnoDB: 128 out of 128 rollback segments are active.
[Note] InnoDB: Creating shared tablespace for temporary tables
[Note] InnoDB: Setting file 'C:\XAMPP\mysql\data\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
[Note] InnoDB: File 'C:\XAMPP\mysql\data\ibtmp1' size is now 12 MB.
[Note] InnoDB: 10.4.28 started; log sequence number 1972203; transaction id 2830
[Note] InnoDB: Loading buffer pool(s) from C:\XAMPP\mysql\data\ib_buffer_pool
[Note] Plugin 'FEEDBACK' is disabled.
[Note] Server socket created on IP: '::'.

但是 Windows 事件日志中有一些非常令人费解的条目。

每次运行我都只得到以下结果:

Aborting
Fatal error: Can't open and lock privilege tables: Incorrect file format 'db'

或者上面的内容后面跟着:

mysqld.exe: Aria engine: checkpoint failed
mysqld.exe: Can't sync file 'C:\XAMPP\mysql\data\aria_log.00000001' to disk (Errcode: 9 "Bad file descriptor")
mysqld.exe: Error writing file 'C:\XAMPP\mysql\data\aria_log.00000001' (Errcode: 9 "Bad file descriptor")

“坏文件描述符”这个词在我脑子里敲响了“磁盘损坏”的警钟,但 Windows 却说不是:

在此处输入图片描述

(...)
0 bad file records processed.
Phase duration (Bad file record checking): 1.61 milliseconds.
(...)
Windows has scanned the file system and found no problems.
No further action is required.

我尝试了“白痴”方法,简单地删除aria_log.00000001。我所取得的成就是:

  • MariaDB 的启动时间
  • 添加额外的行来记录aria_log.00000001没找到
  • 创建和使用aria_log.00000002aria_log.00000003ETC。

但那只是一次“虚拟”运行。所有客户端都可以看到 MariaDB 正在运行(XAMPP 具有Status change detected: running最后一行日志且没有错误),但实际上这是一种奇怪的“锁定”,客户端无法检测到这一事实并永远挂起而不会超时:

在此处输入图片描述

浏览器也是如此,它永远显示“旋转的圆圈”,直到我手动关闭数据库。

此后,Error: MySQL shutdown unexpectedly.每次运行一切都会恢复到“正常”状态。

我还没有尝试过“暴力破解模式”(这里)当一系列“意外关机”开始时,我只是:

  • 卸载 XAMPP(备份数据)
  • 删除整个目录:\XAMPP文件夹
  • 全新安装 XAMPP 8.2.4

此后,我总是“在接下来的几天里都很好”。通常是五到六天。

我已经在 Windows 上使用 XAMPP 十余年了,从 XP 开始的 Windows 版本从未遇到过任何问题。直到现在。

除了永远摆脱 XAMPP 并尝试其他 LAMP(因为重新安装不会带来任何东西)之外,我还能做什么吗?

编辑Maria DB 和整个类似服务器的系统 (Apache/XAMPP) 均未更新。所有内容均保留在 XAMPP 8.2.4 和 MariaDB 10.4.28 上强文本至少半年了。唯一的“更新”是我不断地卸载-重新安装(现在就这样)。

编辑这是 Windows 11 Pro(10.0.22621 Build 22621),因此底层存储系统是单个 SSD 驱动器(KBG50ZNS512G NVMe KIOXIA 512 GB;475 GB 真实容量)。这是一台全新的笔记本电脑,因此到目前为止磁盘已经运行了 2.5 周。

答案1

尝试以下命令修复权限表 mysql_upgrade --force -uroot -p

答案2

您可以考虑以下解决方案之一。

数据备份

各种报告(这里这里)建议解决方案可能是:

  1. 导航到 XAMPP MariaDB 目录(目录:\xampp\mysql
  2. 创建一些备份文件夹,例如数据备份(万一)
  3. 复制内容备份数据文件夹数据备份文件夹
  4. 复制并覆盖所有内容数据文件夹内容备份文件夹
  5. 复制ibdata1文件来自数据备份\数据文件夹数据覆盖文件
  6. 尝试重新启动 MySQL。

许多用户这里有人报告说上述解决方案有效。我没有尝试过。

文件修复

完全是偶然,我发现了一个文件mysql\bin文件夹名为[用户名].err在哪里[用户名]是您的 Windows 用户名。其内容显示了问题的真正本质(见下文):

Cannot find checkpoint record at LSN (1,0x5dd7)
[ERROR] Plugin 'Aria' init function returned error.
[ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.

并且还提出了可能的解决方案:

[ERROR] mysqld: Aria recovery failed. Please run aria_chk -r on all Aria tables and delete all aria_log.######## files

我也没有尝试过这个解决方案。

数据库服务器升级

我没有尝试这两种方法中的任何一种,只是将我的 MariaDB 数据库版本更新为最新版本。

这个解决方案要求我对我的 MariaDB 用户施展一些魔法因为最新的 MariaDB 服务器使用不同的身份验证方法(GSSAPI 插件)而不是旧版本(本机 MySQL 身份验证)。

不幸的是,这个解决方案也只起作用了 2-3 天,之后MariaDB 开始崩溃,行为也完全相同,情况完全相同,而且没有任何恢复的机会。

作为 Windows 系统服务运行

在阅读更多帖子时,我发现有人声称“所有这些 *nix 服务在 Windows 中作为系统服务运行时工作得更稳定“。

我不知道这种说法有多少真实性,但是由于 XAMPP 可以轻松实现这一点,因此我尝试了这个解决方案:

在此处输入图片描述

这个解决方案似乎有效(至少目前如此)。

最后的手段。不停止或伪备份

如果上述解决方案像所有其他解决方案一样开始失败,那么对我来说最后的机会就是使用一个老办法,即根本不停止 MariaDB,而是让开发 PC 休眠而不是关闭它。

听起来很疯狂,但正如我的一个朋友所证明的那样......有效。

所有报告(链接在此处和我读过的所有报告)都表明 MariaDB 的问题始于第一次或第二次关闭。所以... 我们不要让她休息一刻!:]

另一个“愚蠢”且“硬核”的解决方案是在 MariaDB 仍可工作时压缩整个 XAMPP 安装,然后在它停止工作时将其“重新创建”回该阶段。有点类似于提到的“硬核数据覆盖”这里

对我来说幸运的是,这只是一台开发笔记本电脑,只要它能用,我才不在乎数据库里有什么数据。当然,这种解决方案并不适用于所有这些数据很重要且不能简单地覆盖或回滚几天的场景。

相关内容