☰

MySQL 5.0 -> 5.1 升级，表升级需要很长时间

tag-icon • tag-icon mysql myisam
MySQL 5.0 -> 5.1 升级，表升级需要很长时间

我们有一个数据库服务器，之前在 Debian etch 上运行 MySQL 5.0（！），现在决定升级。现在它在 Debian squeeze 上运行 5.1。

该数据库服务器在 SATA RAID 阵列上拥有约 1.2TB 的 MyISAM 数据，以及 2GB 的 RAM。通常，速度不是该服务器运行查询的一个因素，它主要是后台操作。

在升级时，Debian 软件包运行了一个维护脚本来升级表，但升级每个表都需要花费很长时间。我说的“很长”是指每个表大约需要 18 个小时，按照目前的速度，完成所有这些工作大约需要 6 周的时间。这是一个相当大的问题。

我尝试将全局 key_buffer 增加到 512MB，这似乎符合建议，但没有效果。

问题似乎在于它使用了“使用密钥缓存修复”方法，该方法比排序方法慢得多：

mysql> show processlist;
+-----+------------------+----------------------------------+------------------+---------+-------+----------------------+--------------------------------------------------------------------------+
| Id  | User             | Host                             | db               | Command | Time  | State                | Info                                                                     |
+-----+------------------+----------------------------------+------------------+---------+-------+----------------------+--------------------------------------------------------------------------+
|   5 | debian-sys-maint | localhost                        | xxxxxxxxxxxxxxxx | Query   | 45146 | Repair with keycache | REPAIR TABLE `xxxxxxxxxxxxxxxx`.`xxxxxxxxxxxxxxxxxxxx`

由于需要升级，其他表无法访问：

mysql> check table xxxxxxxxxxxxxxxxxxxx fast quick;
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
| Table                                 | Op    | Msg_type | Msg_text                                                                                          |
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
| xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | check | error    | Table upgrade required. Please do "REPAIR TABLE `xxxxxxxxxxxxxxxxxxxx`" or dump/reload to fix it! |
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
1 row in set (1.09 sec)

主要问题是，我如何升级这些表并更快地将数据在线化？

次要问题是：

  • 使用 myisamchk 类似“ myisamchk --sort-recover --analyze --sort_buffer_size=256M --key_buffer=256M --read_buffer=2M --write_buffer=2M tablename”来升级表（即不使用 keycache 方法）吗？
  • 我可以安全地终止 debian 脚本并使用更有效的方法升级表吗？
  • 服务器最初启动时 key_buffer_size 仅为 16M。我后来通过设置全局变量更正了这个问题，但 debian 脚本的会话是否可能仍在使用某个较小的值？如果是，我可以更改它吗？

答案1

主要问题是，我如何才能升级这些表并更快地将数据在线化？

简单的答案是运行mysql_upgrade。

使用 myisamchk 类似“ myisamchk --sort-recover --analyze --sort_buffer_size=256M --key_buffer=256M --read_buffer=2M --write_buffer=2M tablename”来升级表（即不使用 keycache 方法）吗？

不。

我可以安全地终止 debian 脚本并使用更有效的方法升级表吗？

我需要了解该脚本的更多细节。

服务器最初启动时key_buffer_size只有 16M。我后来通过设置全局变量更正了这个问题，但 Debian 脚本的会话是否可能仍在使用一些较小的值？如果是的话，我可以修改它吗？

您可以在会话中执行此操作：

mysql> SET SESSION key_buffer_size = ... ;

答案2

事实证明，debian 脚本只是检查升级需要表的标准 init 脚本，因此终止它不是问题，因为它只是在 init 上重新运行。

键缓冲区值不是问题，因为我怀疑它是用来修复表的键缓存方法 - 对于这么多数据来说它太慢了。

一旦我们'set global myisam_max_sort_file_size=21474836480;'重新启动 mysql，它就会开始使用速度更快的排序方法。但是在另一个表上，它又回到了 keycache，所以我将其提高到 80G 并再次重新启动。

所有桌子现已升级。

相关内容