时间戳

首页 > 解决方案 > Rails5：为什么迁移会破坏我的生产环境，但不会破坏我的测试环境？

mysql - Rails5：为什么迁移会破坏我的生产环境，但不会破坏我的测试环境？

问题描述

我在 Rails 中有一个迁移，它执行以下操作：

class AddMissingIndexes < ActiveRecord::Migration[5.1]
  def change
    # Applications
    add_index :applications, :evid, length: { evid: 255 }
  end
end

这似乎在我的测试环境中运行顺利

但是，当我在生产环境中运行迁移时， 出现此错误：

Mysql2::Error: Specified key was too long; max key length is 767 bytes: CREATE  INDEX `index_applications_on_evid`  ON `applications` (`evid`(255))

我正在尝试使用此问题的第二个答案来解决此问题

class AddMissingIndexes < ActiveRecord::Migration[5.1]
  def change
    # Applications
    add_index "applications", ["evid"], :name => :evid, :length => { :evid => 255 }
  end
end

但是，我想在对架构进行任何进一步更改之前确保它有效。所以我需要能够在我的测试环境中重现这个错误。

测试环境：

+-------------------------+------------------+
| Variable_name           | Value            |
+-------------------------+------------------+
| innodb_version          | 5.5.62           |
| protocol_version        | 10               |
| slave_type_conversions  |                  |
| version                 | 5.5.62-0+deb8u1  |
| version_comment         | (Debian)         |
| version_compile_machine | x86_64           |
| version_compile_os      | debian-linux-gnu |
+-------------------------+------------------+

生产环境

+-------------------------+---------------------+
| Variable_name           | Value               |
+-------------------------+---------------------+
| innodb_version          | 5.6.40              |
| protocol_version        | 10                  |
| slave_type_conversions  |                     |
| version                 | 5.6.40-log          |
| version_comment         | Source distribution |
| version_compile_machine | x86_64              |
| version_compile_os      | Linux               |
+-------------------------+---------------------+

使用SHOW GLOBAL VARIABLES LIKE 'innodb_%'; 我可以看到我的测试环境数据库，这就是我发现我的本地数据库环境具有以下变量，如下所示：

测试环境

innodb_file_format=Barracuda;
innodb_large_prefix=1;
innodb_file_per_table=1;
innodb_file_format_max=Barracuda;
innodb_strict_mode=1;
character_set_server='utf8mb4';

生产环境

innodb_file_format=Antelope;
innodb_large_prefix=OFF;
innodb_file_per_table=ON;
innodb_file_format_max=Antelope;
innodb_strict_mode=OFF;
character_set_server='utf8mb4';

我试图重现我的生产环境，一次将变量设置为 1。但无济于事。

标签： mysqlmigrationruby-on-rails-5

解决方案

SHOW CREATE TABLE applications\G在您的测试和生产环境中运行。我预测差异将是：

测试：

CREATE TABLE `applications` (
  ...
  `evid` varchar(255) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8

生产：

CREATE TABLE `applications` (
  ...
  `evid` varchar(255) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

正如错误所说，索引必须能够容纳 767 个字节。utf8 字符集将每个字符 3 个字节计入此限制，因此 3*255 = 765，适合。

而 utf8mb4 每个字符计算 4 个字节。4*255 = 1020，太长了。

您可以在使用 utf8mb4 时对 VARCHAR(191) 进行索引，以保持在 767 字节以内。

或者，您可以使用更新的 InnoDB 行格式来支持高达 3072 字节的索引大小。请参阅mysql 更改 innodb_large_prefix

如果你想避免这些意外，重要的是在测试和生产中运行相同版本的 MySQL，并确保 MySQL 配置选项尽可能接近，并确保表定义相同。

使用 innodb 配置变量重新更新您的问题。

我看到您的生产环境的设置意味着它无法使用梭子鱼文件格式定义表，这意味着没有 DYNAMIC 行格式，这意味着没有innodb_large_prefix.

您需要使设置与您的测试环境相匹配，然后您可能需要重建您的表，使其真正采用梭子鱼格式和动态行格式。

我还建议（再次）将您的测试服务器升级到您在生产中运行的相同 MySQL 版本。

还要比较其他配置设置，看看是否有其他差异（除了那些适合与生产不同的差异，如 innodb_buffer_pool_size）。

您还应该确保使用与您的技术堆栈的其他部分相同的版本，例如 Linux 版本、Ruby 版本等。如果您对版本不兼容感到惊讶，如果您未能做到，这是众所周知的项目不稳定和进度延迟的来源使您的开发和测试环境与您的生产环境相匹配。

推荐阅读