修补和热修复

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

直接修补生产数据库会导致schema 漂移：您的数据库 schema 已“偏离”真理来源，并且与您的迁移历史记录不同步。您可以使用 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​