修补和热修复

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

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

警告

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

使用修补程序或热修复协调迁移历史记录

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

协调生产环境中的迁移历史记录和数据库模式

复制您在生产环境中所做的模式更改 - 例如，向特定模型添加@@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 对两个数据库模式源进行比较以创建迁移，将其中一个迁移到第二个的状态。您可以输出差异的摘要或 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修复它。

失败迁移的示例

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

schema.prisma

model User {
  id   Int    @id
  name String
}

此时，您的模式已同步，但两个环境中的数据不同。

然后，您决定更改数据模型，添加另一个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 问题 #6485 以获取更新。

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

迁移失败​

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

选项 2：手动完成迁移并将其解析为已应用​

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

失败迁移的示例​

向后移动并撤消所有更改​

向前移动并应用缺失的更改​

迁移历史冲突​

Prisma Migrate 和 PgBouncer​