主页 / dba / 问题 / 1261
Accepted
Derek Downey
Asked: 2011-02-17 07:01:01 +0800 CST

如何安全地更改 MySQL innodb 变量“innodb_log_file_size”？

  • 772

所以我对调整 InnoDB 还是很陌生。我正在慢慢地将表（如有必要）从 MyIsam 更改为 InnoDB。我在 innodb 中有大约 100MB，所以我将innodb_buffer_pool_size变量增加到 128MB：

mysql> show variables like 'innodb_buffer%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.00 sec)

当我去更改innodb_log_file_size值时（例如mysql的innodb配置页面上的my.cnf注释将日志文件大小更改为缓冲区大小的25％。所以现在我的my.cnf看起来像这样：

# innodb
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M

当我重新启动服务器时，我收到此错误：

110216 9:48:41 InnoDB：正在初始化缓冲池，大小 = 128.0M
110216 9:48:41 InnoDB：已完成缓冲池
InnoDB 的初始化：错误：日志文件 ./ib_logfile0 的大小不同 0 5242880 字节
InnoDB：比在.cnf 文件 0 33554432 字节！
110216 9:48:41 [错误] 插件“InnoDB”初始化函数返回错误。
110216 9:48:41 [错误] 插件“InnoDB”注册为存储引擎失败。

所以我的问题是：删除旧的 log_files 是否安全，或者是否有另一种方法来更改innodb_log_file_size变量？

mysql innodb

5 个回答

  1. Best Answer

    是的，一旦 mysqld 关闭，删除日志文件是安全的

    鉴于此，只需执行以下步骤：

    mysql -uroot -p... -e"SET GLOBAL innodb_fast_shutdown = 0"
service mysql stop
mv /var/lib/mysql/ib_logfile[01] /tmp
service mysql start

    启动 mysqld 将重新创建ib_logfile0和ib_logfile1

    试试看 ！！！

    更新 2011-10-20 16:40 EDT

    它在重做日志文件之前干净地分页出 InnoDB 缓冲池中的所有数据，您应该在关闭前大约 1 小时设置此选项：

    SET GLOBAL innodb_max_dirty_pages_pct = 0;

    默认情况下，innodb_max_dirty_pages_pct为 75（MySQL 5.5+）或 90（MySQL 5.5 之前）。将此设置为零可使脏页数保持在 InnoDB 缓冲池的 1% 以下。service mysql stop无论如何，表演都会这样做。此外，关闭将完成重做日志中的所有剩余项目。要保留此选项，只需将其添加到 /etc/my.cnf：

    [mysqld]
innodb_max_dirty_pages_pct = 0

    更新 2013-04-19 16:16 EDT

    我用innodb_fast_shutdown更新了我的答案，因为我曾经重新启动 mysql 并停止 mysql 来执行此操作。现在，这一步至关重要，因为每个未提交的事务都可能在 InnoDB 事务日志内部和外部有其他移动部分（请参阅 InnoDB 基础设施）。

    请注意，将innodb_fast_shutdown设置为 2 也会清除日志，但仍然存在更多移动部件，并在 mysqld 启动期间在崩溃恢复中被选中。最好设置为 0。

    • 92

  2. 我会推荐官方方法，为方便起见，我在这里复制：

    要更改MySQL 5.6.7 或更早版本中 InnoDB 日志文件的数量或大小，请使用以下说明。使用的过程取决于 innodb_fast_shutdown 的值，它决定在关闭操作之前是否使系统表空间完全更新：

    • 如果 innodb_fast_shutdown 未设置为 2：停止 MySQL 服务器并确保它关闭时没有错误，以确保重做日志中没有未完成事务的信息。将旧的重做日志文件复制到安全的地方，以防关闭期间出现问题并且您需要它们来恢复表空间。从日志文件目录中删除旧的日志文件，编辑my.cnf更改日志文件配置，重新启动MySQL服务器。mysqld 在启动时看到不存在 InnoDB 日志文件并创建新的。

    • 如果 innodb_fast_shutdown 设置为 2： 将 innodb_fast_shutdown 设置为 1：

    mysql> SET GLOBAL innodb_fast_shutdown = 1;

    然后按照上一项中的说明进行操作。

    从 MySQL 5.6.8 开始，innodb_fast_shutdown 设置在更改 InnoDB 日志文件的数量或大小时不再相关。此外，您不再需要删除旧日志文件，尽管您可能仍希望将旧日志文件复制到安全的地方作为备份。要更改 InnoDB 日志文件的数量或大小，请执行以下步骤：

    1. 停止 MySQL 服务器并确保它在没有错误的情况下关闭。

    2. 编辑 my.cnf 以更改日志文件配置。要更改日志文件大小，请配置 innodb_log_file_size。要增加日志文件的数量，请配置 innodb_log_files_in_group。

    3. 再次启动 MySQL 服务器。

    如果 InnoDB 检测到 innodb_log_file_size 与重做日志文件大小不同，它将写入日志检查点，关闭并删除旧日志文件，以请求的大小创建新日志文件，并打开新日志文件。

    • 32

  3. innodb_buffer_pool_size-- 只需更改my.cnf( my.ini) 并重新启动 mysqld。

    innodb_log_file_size不太重要。除非有理由，否则不要更改它。罗兰提供了步骤，但有一个方面让我担心……我不知道前两个步骤是否重要；看起来他们可能是：

    1. set innodb_fast_shutdown = OFF
    2. 重启mysql
    3. 停止mysql
    4. 删除日志文件
    5. 启动mysql

    日志文件跟踪未完成的业务；" " 表示重启后innodb_fast_shutdown处理那些东西。所以删除文件可能会丢失信息？

    新版本改进了一些东西：（ 更多讨论在评论中）

    • 5.6 允许innodb_log_file_size> 4GB
    • 5.6innodb_log_file_size可以在不先删除 iblog 的情况下更改*
    • 5.7 允许动态调整大小innodb_buffer_pool_size

    我应该更改 log_file_size 吗？

    用于GLOBAL STATUS计算日志周期之前的分钟数。

    Uptime / 60 * innodb_log_file_size / Innodb_os_log_written`

    如果它远小于60（分钟），那么增加 log_file_size 可能会有所帮助。如果更多，则日志文件正在浪费磁盘空间。那个“1 小时”是相当随意的，所以如果你接近它，不要费心改变 log_file_size。

    保留innodb_log_files_in_group默认值 2。

    • 23

  4. 当您登录到 mysql 时，键入这些命令：

    pager grep seq;
show engine innodb status \G select sleep(60); show engine innodb status \G

    你会得到两个数字。首先你得到一个，然后等待一分钟。你会得到另一个。

    假设第一个是 3.456.718.123，第二个是 4.098.873.134

    现在 (4.098.873.134-3.856.718.123)*60/1024/1024

    结果是 = 13.856 MB

    您有两个日志文件。所以将它除以 2，你会得到一个接近 7.000 MB 的数字。可以肯定的是，将您的日志文件大小设置为 8GB

    • 1

  5. chown mysql:mysql -R /etc/mysql /var/lib/mysql && cd /var/lib/mysql && rm -f ib_logfile* && service mysql restart || 服务mysql重启

    试试看，保证可以工作 [在 Debian 6 上测试]

    • -5

相关问题