修补与热修复

修补或热修复数据库通常涉及在生产环境中直接进行时间紧急的更改。例如，您可能直接向生产数据库添加索引，以解决慢查询问题。

直接修补生产数据库会导致模式漂移（schema drift）：您的数据库模式会“偏离”真实来源，与您的迁移历史记录不同步。您可以使用 prisma migrate resolve 命令来协调您的迁移历史记录，而无需使用 prisma migrate deploy 删除并重新应用热修复。

警告

本指南不适用于 MongoDB。
对于 MongoDB，使用 db push 而非 migrate dev。

使用修补或热修复协调您的迁移历史记录

以下场景假设您在生产环境中进行了手动更改，并希望将该更改传播到您的迁移历史记录和其他数据库。

在生产环境中协调您的迁移历史记录和数据库 schema

在 schema 中复制您在生产环境中进行的更改 - 例如，为特定模型添加 @@index。

生成新的迁移并记下完整的迁移名称，包括时间戳，它将写入 CLI：（20210316150542_retroactively_add_index）

npx prisma migrate dev --name retroactively-add-index

显示CLI结果

migrations/
└─ 20210316150542_retroactively_add_index/
└─ migration.sql

Your database is now in sync with your schema.

✔ Generated Prisma Client (2.19.0-dev.29) to .\node_modules\@prisma\client in 190ms

将迁移推送到生产环境，但不要运行 migrate deploy。相反，将上一步中创建的迁移标记为“已应用”，这样 Prisma Migrate 就不会尝试第二次应用您的热修复。
```
prisma migrate resolve --applied "20201127134938-retroactively-add-index"
```
此命令会将迁移添加到迁移历史记录表中，而不会运行实际的 SQL。
对其他已修补的数据库重复上一步 - 例如，如果您将修补应用于暂存数据库。
将迁移传播到其他未修补的数据库 - 例如，通过将迁移提交到源代码控制，并允许您的 CI/CD 流水线将其应用于所有数据库。

注意：该迁移不会应用于已通过 prisma migrate resolve 命令标记为已应用的数据库。

失败的迁移

迁移可能失败，如果

您在运行迁移之前修改了迁移并引入了语法错误
您向已包含数据的表中添加了强制 (NOT NULL) 列
迁移过程意外停止
数据库在迁移过程中关闭

_prisma_migrations 表中的每个迁移都有一个 logs 列，用于存储错误。

在生产环境中处理失败迁移有两种方法

回滚，可选地修复问题，并重新部署
手动完成迁移步骤并解决迁移

选项 1：将迁移标记为已回滚并重新部署

以下示例演示了如何回滚迁移，可选地进行更改以修复问题，并重新部署

将迁移标记为已回滚 - 这会更新 _prisma_migrations 表中的迁移记录，将其注册为已回滚，使其可以再次应用
```
prisma migrate resolve --rolled-back "20201127134938_added_bio_index"
```
如果迁移部分运行，您可以选择
- 修改迁移以检查某个步骤是否已完成（例如：CREATE TABLE ... IF NOT EXISTS）或者
- 手动恢复已完成的步骤（例如，删除已创建的表）
如果您修改了迁移，请确保将其复制回源代码控制，以确保您的生产数据库状态在开发环境中得到精确反映。
如果相关，修复失败迁移的根本原因 - 例如，如果迁移因 SQL 脚本本身的问题而失败。确保将任何更改的迁移复制回源代码控制。
重新部署迁移
```
prisma migrate deploy
```

选项 2：手动完成迁移并标记为已应用

以下示例演示了如何手动完成迁移的步骤并将其标记为已应用。

在生产数据库上手动完成迁移步骤。确保任何手动步骤与迁移文件中的步骤完全匹配，并将任何更改复制回源代码控制。
将迁移标记为已应用 - 这会告诉 Prisma Migrate 认为该迁移已成功应用
```
prisma migrate resolve --applied "20201127134938_my_migration"
```

使用 `migrate diff` 和 `db execute` 修复失败的迁移

为了帮助修复失败的迁移，Prisma ORM 提供了以下用于创建和执行迁移文件的命令

prisma migrate diff 用于对比两个数据库 schema 源，以创建将一个源转换为第二个源状态的迁移。您可以输出差异摘要或 SQL 脚本。脚本可以通过 > file_name.sql 输出到文件，或通过管道传递给 db execute --stdin 命令。
prisma db execute 将 SQL 脚本应用于数据库，而不与 Prisma 迁移表交互。

这些命令在 3.9.0 及更高版本的预览版中可用（使用 --preview-feature CLI 标志），并在 3.13.0 及更高版本中普遍可用。

本节给出了一个失败迁移的示例场景，并解释了如何使用 migrate diff 和 db execute 来修复它。

失败迁移示例

假设您的本地开发环境和生产环境中 schema 都有以下 User 模型

schema.prisma

model User {
  id   Int    @id
  name String
}

此时，您的 schema 是同步的，但两个环境中的数据不同。

然后，您决定更改数据模型，添加另一个 Post 模型并使 User 上的 name 字段唯一

schema.prisma

model User {
  id    Int     @id
  name  String  @unique
  email String?
}

model Post {
  id    Int    @id
  title String
}

您使用命令 prisma migrate dev -n Unique 创建了一个名为 'Unique' 的迁移，该迁移保存在您的本地迁移历史记录中。在您的开发环境中应用迁移成功，现在是发布到生产环境的时候了。

不幸的是，这个迁移只能部分执行。创建 Post 模型和添加 email 列成功，但使 name 字段唯一失败并出现以下错误

ERROR 1062 (23000): Duplicate entry 'paul' for key 'User_name_key'

这是因为您的生产数据库中存在非唯一数据（例如，两个同名用户）。

您现在需要从部分执行的迁移中手动恢复。在您从失败状态恢复之前，无法使用 prisma migrate deploy 进行进一步的迁移。

此时有两种选择，取决于您决定如何处理非唯一数据

您意识到非唯一数据是有效的，并且您无法继续当前开发工作。您想回滚完整的迁移。为此，请参阅回退并恢复所有更改
数据库中存在非唯一数据是无意的，您希望修复它。修复后，您想继续进行剩余的迁移。为此，请参阅向前并应用缺失的更改

回退并恢复所有更改

在这种情况下，您需要创建一个迁移，使您的生产数据库回到上次迁移之前的数据模型状态。

首先，您需要失败迁移之前时间的迁移历史记录。您可以从 Git 历史记录中获取，或在本地删除迁移历史记录中最后一次失败迁移的文件夹。
您现在想将您的生产环境从当前的失败状态恢复到本地迁移历史记录中指定的状态
- 运行以下 prisma migrate diff 命令
```
 npx prisma migrate diff \
  --from-url "$DATABASE_URL_PROD" \
  --to-migrations ./prisma/migrations \
  --shadow-database-url $SHADOW_DATABASE_URL \
  --script > backward.sql
```
  这将创建一个 SQL 脚本文件，其中包含将您的生产环境从当前的失败状态转换为由您的迁移历史记录定义的目标状态所需的所有更改。请注意，由于我们使用了 --to-migrations，该命令需要一个影子数据库。
- 运行以下 prisma db execute 命令
```
 npx prisma db execute --url "$DATABASE_URL_PROD" --file backward.sql
```
  这将 SQL 脚本中的更改应用于目标数据库，而不与迁移表交互。
- 运行以下 prisma migrate resolve 命令
```
 npx prisma migrate resolve --rolled-back Unique
```
  这将在您的生产环境中的迁移表中将名为 'Unique' 的失败迁移标记为已回滚。

您的本地迁移历史记录现在与您的生产数据库状态相同。您现在可以再次修改数据模型，以创建符合您对正在处理的功能（带有非唯一名称）的新理解的迁移。

向前并应用缺失的更改

在这种情况下，您需要修复非唯一数据，然后按计划继续执行剩余的迁移

尝试将迁移部署到生产环境时出现的错误消息已经告诉您 name 列中存在重复数据。您需要更改或删除有问题的数据行。
继续应用剩余的失败迁移，以达到您 schema.prisma 文件中定义的数据模型状态
- 运行以下 prisma migrate diff 命令
```
npx prisma migrate diff --from-url "$DATABASE_URL_PROD" --to-schema-datamodel schema.prisma --script > forward.sql
```
  这将创建一个 SQL 脚本文件，其中包含将您的生产环境从当前的失败状态转换为您的 schema.prisma 文件中定义的目标状态所需的所有更改。
- 运行以下 prisma db execute 命令
```
npx prisma db execute --url "$DATABASE_URL_PROD" --file forward.sql
```
  这将 SQL 脚本中的更改应用于目标数据库，而不与迁移表交互。
- 运行以下 prisma migrate resolve 命令
```
npx prisma migrate resolve --applied Unique
```
  这将标记在您的生产环境中的迁移表中将名为 'Unique' 的失败迁移标记为已应用。

您的本地迁移历史记录现在与您的生产环境状态相同。您现在可以继续使用已知的 migrate dev /migrate deploy 工作流程。

迁移历史冲突

信息

从 3.12.0 及更高版本不再适用。

如果已应用的迁移被编辑过，prisma migrate deploy 会发出警告 - 但它不会停止迁移过程。要消除警告，请从源代码控制中恢复原始迁移。

Prisma Migrate 与 PgBouncer

如果您尝试在使用 PgBouncer 进行连接池的环境中运行 Prisma Migrate 命令，可能会看到以下错误

Error: undefined: Database error
Error querying the database: db error: ERROR: prepared statement "s0" already exists

请参阅Prisma Migrate 与 PgBouncer 变通方法以获取更多信息和变通方法。关注GitHub issue #6485以获取更新。

使用修补或热修复协调您的迁移历史记录​

失败的迁移​

选项 1：将迁移标记为已回滚并重新部署​

选项 2：手动完成迁移并标记为已应用​

使用 migrate diff 和 db execute 修复失败的迁移​

失败迁移示例​

回退并恢复所有更改​

向前并应用缺失的更改​

迁移历史冲突​

Prisma Migrate 与 PgBouncer​