☰

MySQL 使用外部存储时行为不稳定

tag-icon • tag-icon windows-server-2008 windows-server-2003 mysql storage
MySQL 使用外部存储时行为不稳定

在我们的项目中，我们使用带有外部存储的 MySQL 5.0.90（InnoDB 引擎）服务器。我们将 MySQL 数据文件存储在外部存储中。当外部存储因某种原因停机时，我们的行为就会不稳定。所以我们做了一些测试。

在 Windows Server 2008 中

我们物理关闭了外部存储。MySQL 服务停止，我们无法访问服务器。然后我们打开了存储单元，我们可以启动服务

日志

  1. 120618 14:49:30 InnoDB：文件操作中出现操作系统错误编号 21。
  2. InnoDB：一些操作系统错误编号描述如下
  3. InnoDB的：http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
  4. InnoDB：文件名 E:\Data\ibdata1
  5. InnoDB：文件操作调用：‘aio write’。
  6. InnoDB：无法继续操作。

我们从操作系统将存储单元脱机。经过 3-4 分钟和一些插入尝试（一些插入尝试成功）后，MySQL 服务停止，我们无法访问服务器。

日志

  1. 120618 14:27:21 InnoDB：文件操作中出现操作系统错误编号 21。
  2. InnoDB：一些操作系统错误编号描述如下
  3. InnoDB的：http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
  4. InnoDB：文件名 E:\Data\ibdata1
  5. InnoDB：文件操作调用：‘aio read’。
  6. InnoDB：无法继续操作。

然后我们使存储单元上线并尝试启动服务

日志

  1. InnoDB：第一个指定数据文件 E:\ibdata1 不存在：
  2. InnoDB：即将创建的新数据库！
  3. 120618 14:29:00 InnoDB：将文件 E:\ibdata1 大小设置为 10 MB
  4. InnoDB：数据库物理上写入文件已满：等待......
  5. InnoDB：错误：所有日志文件必须同时创建。
  6. InnoDB：所有日志文件也必须在创建数据库时创建。
  7. InnoDB：如果您想要更大或更小的日志文件，请关闭
  8. InnoDB：数据库并确保关闭时没有错误。
  9. InnoDB: 然后删除现有的日志文件。编辑.cnf 文件
  10. InnoDB：并重新启动数据库。
  11. 120618 14:29:00 [错误] 默认存储引擎 (InnoDB) 不可用
  12. 120618 14:29:00 [错误] 正在中止

然后我们尝试重新配置 MySQL

日志

  1. InnoDB：页面转储结束
  2. 120618 14:34:02 InnoDB：页面校验和 1575996416，4.0.14 版本之前的校验和 1371122432
  3. InnoDB：存储校验和 0，4.0.14 版之前存储校验和 0
  4. InnoDB：页面 lsn 0 0，页面末尾 lsn 的低4字节为 0
  5. InnoDB：页码（如果已存储到页面）0，
  6. InnoDB：空间 ID（如果使用 >= MySQL-4.1.1 创建并且已经存储）0
  7. 120618 14:34:02 - mysqld 发生异常 0xc0000005；

  8. 这可能是因为您遇到了错误。也可能是这个二进制文件或它所链接的某个库已损坏、构建不当或配置错误。此错误也可能是由硬件故障引起的。我们将尽力收集一些信息，希望这些信息有助于诊断问题，但由于我们已经崩溃，肯定出了问题，这可能会失败。

  9. 密钥缓冲区大小=0

  10. 读取缓冲区大小=65536
  11. 最大使用连接数=0
  12. 最大连接数=100
  13. 线程连接=0

  14. mysqld 有可能使用最多 key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 32000 K 字节的内存，希望这样没问题；如果不行，请减少等式中的某些变量。

  15. thd=00000000

  16. 尝试回溯。您可以使用以下信息来找出 mysqld 死机的位置。如果此后没有看到任何消息，则表明发生了严重错误...
  17. 006D2DB6 mysqld-nt.exe！page_cur_search_with_match()[page0cur.c:347]
  18. 0067A777 mysqld-nt.exe!btr_cur_search_to_nth_level()[btr0cur.c:500]
  19. 006B2E0E mysqld-nt.exe!btr_pcur_open_on_user_rec()[btr0pcur.c:549]
  20. 006A5615 mysqld-nt.exe！dict_load_indexes（）[dict0load.c:604]
  21. 006A6424 mysqld-nt.exe！dict_load_sys_table（）[dict0load.c:1023]
  22. 006BBB20 mysqld-nt.exe!dict_boot()[dict0boot.c:378]
  23. 00668A79 mysqld-nt.exe！innobase_start_or_create_for_mysql（）[srv0start.c:1462]
  24. 00444462 mysqld-nt.exe！innobase_init（）[ha_innodb.cc:1427]
  25. 0044B30D mysqld-nt.exe!ha_init()[handler.cc:483]
  26. 004B923E mysqld-nt.exe!init_server_components()[mysqld.cc:3431]
  27. 004BD070 mysqld-nt.exe!win_main()[mysqld.cc:3806]
  28. c004BD43B mysqld-nt.exe！mysql_service（）[mysqld.cc:3967]
  29. 006E28EF mysqld-nt.exe!_threadstart()[thread.c:196]
  30. 75583677 kernel32.dll!BaseThreadInitThunk()
  31. 77359D72 ntdll.dll!RtlInitializeExceptionChain()
  32. 77359D45 ntdll.dll!RtlInitializeExceptionChain()
  33. 手册页位于http://dev.mysql.com/doc/mysql/en/crashing.html包含可帮助您找出导致崩溃的原因的信息。120618 14:29:00 [注意] C:\Program Files (x86)\MySQL\MySQL Server 5.0\bin\mysqld-nt: 关闭完成

在 Windows Server 2003 中

我们使存储单元离线。经过 3-4 分钟和一些插入尝试（一些插入尝试成功）后，MySQL 服务停止，我们无法访问服务器。

日志

  1. InnoDB：日志扫描已超过检查点 lsn 0 9834427 120618 14:09:59 InnoDB：数据库未正常关闭！
  2. InnoDB：开始崩溃恢复。
  3. InnoDB：从 .ibd 文件读取表空间信息...
  4. InnoDB：从双写中恢复可能半写的数据页
  5. InnoDB：缓冲区...
  6. InnoDB：正在进行恢复：扫描至日志序列号 0 9834574
  7. 120618 14:09:59 InnoDB：开始将一批日志记录应用到数据库……
  8. InnoDB：进度百分比：51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 . 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
  9. InnoDB：应用批次完成
  10. 120618 14:10:00 InnoDB：已启动；日志序列号 0 9834574
  11. 120618 14:10:00 [注意] C:\Program Files (x86)\MySQL\MySQL Server 5.0\bin\mysqld-nt：已准备好连接。
  12. 版本：'5.0.90-community-nt' 套接字：'' 端口：3306 MySQL 社区版（GPL）
  13. 120618 14:12:36 InnoDB：文件操作中出现操作系统错误编号 21。
  14. InnoDB：一些操作系统错误编号描述如下
  15. InnoDB的：http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
  16. InnoDB：文件名 E:\Data\ibdata1
  17. InnoDB：文件操作调用：‘aio read’。
  18. InnoDB：无法继续操作。

然后我们将存储单元联机，直到重新安装 MySQL，我们才能启动服务。重新安装之前，我们尝试重新配置，但没有成功。

日志

  1. 120618 14:16:53 InnoDB：文件操作中出现操作系统错误编号 3。
  2. InnoDB：该错误表示系统找不到指定的路径。
  3. InnoDB：如果你正在安装 InnoDB，请记住你必须创建
  4. InnoDB：自己创建目录，InnoDB 不会创建它们。
  5. InnoDB：文件名 E:\Data\ibdata1
  6. InnoDB：文件操作调用：‘创建’。
  7. InnoDB：无法继续操作。

无法在本地计算机上启动 MySQL 服务。错误 1067：进程意外终止。（错误消息）

我们物理关闭了外部存储。MySQL 服务停止，我们无法访问服务器。之后我们打开了存储单元，我们可以启动服务（不是自动的）

日志

  1. 120618 14:01:26 InnoDB：文件操作中出现操作系统错误编号 21。
  2. InnoDB：一些操作系统错误编号描述如下
  3. InnoDB的：http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
  4. InnoDB：文件名 E:\Data\ibdata1
  5. InnoDB：文件操作调用：‘aio write’。
  6. InnoDB：无法继续操作。

我们希望服务在存储单元联机/打开后自动启动。但这些测试显示行为不稳定。对此有什么解决方案吗？

答案1

iSCSI 只是一种允许服务器访问远程模拟 SCSI 磁盘的协议。如果不了解有关实际存储的更多信息（有多少个控制器、是否有写入缓存、是否镜像），我无法确定答案。话虽如此，问题可能是一致性问题。

如果您断开连接到正在运行的数据库的存储，则必须处理所有正在进行的 IO，否则您将面临数据不一致的风险。当您对外部存储进行写入时，它通常会在进入缓存后立即得到确认。一旦发生这种情况，缓存中的数据将被转储到磁盘，但顺序与接收顺序不同。任何导致您丢失缓存的正在进行的 IO 的断电都会导致磁盘丢失写入。

答案2

在我看来，您的错误根源在于底层设备。我会使用其他应用程序对设备进行 IO 测试，看看您是否可以用它来调试错误。设备未准备好和路径未找到错误似乎是根本原因，这表明您的外部存储链接表现不佳。

相关内容