数据库迁移指南

本文介绍了允许您将安全控制台数据库升级到PostgreSQL 11.7版本的产品内迁移过程。请阅读以下部分，了解为什么有必要进行迁移，了解可用性期间的重要日期，并了解如何启动该过程。

• 为什么迁移很重要
• 迁移日期和截止日期
• 迁移是如何工作的
• 如何启动迁移过程
• 常见问题

为什么迁移很重要

安全控制台在PostgreSQL数据库中存储您的评估数据和报告。到目前为止，该应用程序使用的是PostgreSQL数据库的9.4版本。然而，PostgreSQL在2020年2月13日结束了对该版本的官方支持。你可以在PostgreSQL版本策略资源中阅读更多关于这个日期和其他信息:

https://www.postgresql.org/support/versioning/

运行一个官方支持的数据库版本可以确保安全控制台可以接收来自PostgreSQL的安全更新。这个迁移过程将数据库升级到PostgreSQL的11.7版本，该版本将继续得到官方支持，直到2023年11月9日。

根据我们对您数据的安全性和完整性的承诺，Rapid7要求所有安全控制台数据库在此可用期内迁移到PostgreSQL 11.7。

迁移日期和截止日期

产品内迁移服务已于2020年2月26日随产品更新版本6.6.3提供。自4月1日起，这一时间段将无限期持续。

迁移是如何工作的

数据库迁移过程包括3个步骤:

1. 最近的备份验证-在您开始迁移数据到新的11.7数据库之前，迁移服务将检查最近的备份是否已经存在。此备份必须是在最近3天内创建的。
   • 出于预防原因，迁移需要有效的备份。在迁移过程本身期间不会使用它。

2. 在迁移开始—该过程运行一个初步的磁盘空间检查，以确保您的安全控制台主机有足够的存储空间来完成该过程。当主机存储空间不足时，不会进行迁移。假设您有足够的磁盘空间，该过程将开始将您的数据复制到一个新的PostgreSQL 11.7数据库。
   • 如果遇到磁盘空间限制，请参见我没有足够的磁盘空间来启动迁移。我该怎么办?FAQ。

3. 迁移完成-当所有数据成功复制到新的11.7数据库时，迁移将结束。

如何启动迁移过程

开始迁移:

1. 在安全控制台中导航到迁移服务。您可以直接从您的通知下拉，或手动通过管理>维护、存储和故障处理>迁移．迁移界面包含了整个过程的三个步骤和一个时间估计特征。
2. 如果迁移服务没有检测到有效的备份，则单击现在备份．这将带你到备份/恢复选项卡上的维护屏幕，您可以创建您的备份。为您的备份提供合适的描述(例如“11.7迁移备份”或类似的)，然后单击开始备份．准备好备份后返回迁移接口。
   • 有关备份创建过程的详细信息，请参见数据库备份、恢复和数据保留页面。
3. 准备好预防性备份后，就可以开始迁移了。如果需要，您可以通过单击估计现在链接。点击现在迁移当准备好了。
   • 虽然迁移时间估计是基于存储在数据库中的数据量，但实际迁移时间可能会根据环境中的其他条件而变化。
   • 请注意，此估计不包括服务器重新启动所花费的时间。根据您的预迁移状态,您的安全控制台可能重启3次:一次在创建你的最近的备份(如果你不已经有一个),一次实际的数据库迁移本身,一旦你的新基线的备份,你可以选择执行这个过程的步骤7。
4. 迁移完成后，安全控制台暂时保留迁移前9.4数据库的压缩副本。您可以选择自动删除此压缩副本以及其他临时文件，以节省安全控制台主机上的磁盘空间。

5. 通过检查数据库版本号来验证迁移是否成功。你可以通过导航来做到这一点管理>全局和控制台设置>管理>数据库．
6. 接下来，验证您的数据是否与开始迁移过程之前的数据一致。如果您发现迁移前后的数据集不一致，请联系我们Rapid7支持．
7. 最后，作为最佳实践，运行新的数据库备份操作以保留迁移后数据库的基线实例。

常见问题

在升级过程中遇到的常见故障和其他常见问题请参考以下faq。

为什么我需要迁移?

将数据库升级到11.7版本可以确保今后它将继续收到来自PostgreSQL的安全更新。升级截止日期目前暂时暂停，但请注意，如果您没有在新的截止日期之前进行迁移，则安全控制台将不会收到产品更新。尽管这并不影响漏洞内容更新，但如果您没有在截止日期前迁移，则会阻止您的Security Console每周收到改进和bug修复。

迁移前为什么需要创建备份?

备份数据库是保护文件的最佳实践。尽管备份过程被设计为对您的文件是安全的(即使在备份失败的情况下)，但考虑到对您的安全和业务需求至关重要的敏感信息，我们要求您首先创建备份，作为预防措施。在开始迁移过程之前，备份必须在最近3天内进行。

当我更新安全控制台时，迁移是否会自动发生?

不。升级到控制台产品版本6.6.3(以及这个宽限期内包含的任何其他产品版本)只会使迁移服务在您的政府页面。除了通知您服务可用之外，安全控制台不会强制您立即采取行动。虽然迁移的时间最终取决于您，但请记住，您必须在某个时刻进行迁移在可用期内．

迁移过程是否与安全控制台更新过程相同?

不。数据库迁移与您的Security Console每周进行的产品版本更新是完全分离的。如前所述，产品版本6.6.3只是包含迁移服务的几个版本中的第一个。因此，在迁移宽限期内，从6.6.3开始的所有产品版本在技术上都可以运行PostgreSQL 9.4或11.7。但是，请注意，宽限期结束后的新产品版本只能运行11.7。由于这个原因，到目前为止还没有迁移的安全控制台数据库将无法收到新的产品版本更新。

如果我要将我的安全控制台部署转移到另一个主机上，我还需要迁移到11.7吗?

是的。从产品版本6.6.3开始，新安全控制台的安装已经包含了一个PostgreSQL 11.7数据库，但是您仍然需要将原来的9.4数据库迁移到11.7，以便创建一个兼容的备份文件。在11.7上无法恢复从9.4数据库创建的备份。

迁移过程中发生了什么?

启动迁移后，安全控制台进入维护模式，同时将数据从9.4数据库复制到新的11.7数据库。迁移过程将检查以确保有足够的磁盘空间提前完成该操作。在此期间，全局管理员可以登录监控迁移的状态。

迁移完成后，安全控制台会备份9.4数据库，并将其保存在以下目录下:

• Linux-/ opt / rapid7 / nexpose / nsc / nxpgsql-backup-dd-MM-yyyy-HH-MM
• 窗户-C:\Program Files\Rapid7\NeXpose\nsc\ nxpgsql-backup-dd-MM-yyyy-HH-MM

在所有迁移过程完成后，安全控制台将重新启动，您可以恢复正常操作。

如果迁移失败，您当前版本的PostgreSQL数据库将保持完整，您可以继续使用安全控制台而不中断。查看常见问题解答如果迁移失败，该怎么办?如果发生这种情况。

如果我的安全控制台主机被隔离在脱机环境中，这会影响迁移吗?

迁移过程将保持不变，但要注意离线部署在功能上无法接收内容更新，如果您没有在截止日期之前迁移。如果您的部署是在一个与公共互联网隔离的环境中(也称为“气隙”状态)，那么您可能已经依赖于新的控制台产品版本安装程序来获取内容更新，这是您工作流程的一部分。在结尾迁移的宽限期，新的控制台产品版本将只支持PostgreSQL 11.7。如果到那时您还没有进行迁移，您将无法安装新产品版本。这意味着在您完成迁移之前，气隙部署也将无法接收新的内容更新。

迁移是否会影响我的数据仓库功能?

除非你的仓库数据库运行的是8.2之前的PostgreSQL版本。新的11.7版本的安全控制台数据库包含更新的仓库导出驱动程序，但只要您的仓库数据库运行PostgreSQL 8.2或更高版本，这将不会影响您当前的数据仓库功能。

如果您的仓库数据库没有运行PostgreSQL版本8.2以上的版本，您还需要将其升级到支持的版本，然后才能恢复导出。

迁移需要多长时间?

中所示的估计函数可以生成对迁移时间的估计迁移PostgreSQL到11.7在这个屏幕上。虽然这个估计是基于数据库的大小，但实际迁移时间可能会因环境中的其他条件而不同。该估计不考虑服务器重启期间所花费的时间。

如果我使用外部源(如LDAP或Kerberos)向安全控制台进行身份验证，我是否能够监视迁移?

不。数据库存储关于外部身份验证源的信息，它们在迁移期间无法操作。作为一种替代方法，您可以通过以下方式监视迁移的进度:

• 具有全局管理员权限的控制台身份验证用户可以在安全控制台处于维护模式时登录，以监视出现的新状态消息。
• 如果控制台身份验证的Global Administrator用户不可用，您还可以通过读取nsc.log文件位于以下目录:
  • Linux-/ opt / rapid7 / nexpose / nsc /日志
  • 窗户-C:\Program Files\Rapid7\NeXpose\nsc\logs

我的PostgreSQL数据库在外部服务器上。我可以迁移它吗?

目前不支持外部数据库配置。联系Rapid7支持为更多的信息。

50432端口被占用，迁移失败。我该怎么办?

端口50432是为迁移预留的，所以您必须让它可用。请与系统管理员联系，以确定端口50432上运行的是什么服务，并关闭该服务，直到迁移完成。

我没有足够的磁盘空间来启动迁移。我该怎么办?

如果在上一次迁移尝试失败后出现此问题，请参阅FAQ如果迁移失败，该怎么办?否则，请执行以下步骤:

1. 请将以下暴露目录从主机系统中移除，并在迁移完成后进行恢复。随着安全控制台积累数据，这些目录和文件会随着时间的推移占用越来越多的磁盘空间。

备份文件

• Linux-/ opt / rapid7 / nexpose / nsc / * . bak和/ opt / rapid7 / nexpose / nsc / * . zip
• 窗户-C:\Program Files\Rapid7\NeXpose\nsc\*.bak和C:\Program Files\Rapid7\NeXpose\nsc\*.zip

报告目录

• Linux-/ opt / rapid7 / nexpose / nsc / htroot /报告
• 窗户-C:\Program Files\Rapid7\NeXpose\nsc\ htroot /报告

访问日志目录，包括Tomcat日志子目录

• Linux-/ opt / rapid7 / nexpose / nsc /日志
• 窗户-C:\Program Files\Rapid7\NeXpose\nsc\logs

扫描事件数据文件目录

• Linux-/ opt / rapid7 / nexpose /研究/扫描
• 窗户-C:\Program Files\Rapid7\NeXpose\nse\scans

安全控制台日志

• Linux-/ opt / rapid7 / nexpose / nsc /日志/ * . log
• 窗户-C:\Program Files\Rapid7\NeXpose\nsc\logs\*.log*

PostgreSQL的日志

• Linux-/ opt / rapid7 / nexpose nsc / nxpgsql / nxpgsql.log
• 窗户-C:\Program Files\Rapid7\NeXpose\nsc\nxpgsql\ nxpgsql.log

2. 从主机系统中移动任何不在安全控制台安装目录中且其他应用程序不需要运行的文件或目录。迁移完成后可以进行恢复操作。
3. 删除的内容java.io.tmpdir主机系统上的目录，位于/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000 / T /．

执行上述步骤后，再次尝试启动迁移。如果您仍然没有足够的磁盘空间，请联系Rapid7支持．

迁移完成。接下来我该怎么做?

首先，检查PostgreSQL数据库的版本是否正确。你可以打开nsc.log文件位于以下目录:

• Linux-/ opt / rapid7 / nexpose / nsc /日志
• 窗户-C:\Program Files\Rapid7\NeXpose\nsc\logs

搜索PostgreSQL字符串。你会发现激活的PostgreSQL版本号带有一个该字符串的实例，它应该是11.7。或者，您可以通过导航到安全控制台中检查此版本号管理员>管理员>数据库．

接下来，检查您的Security Console接口，并确认您的数据与迁移之前存在的数据一致。特别注意以下项目:

• 报告
• 网站
• 资产
• 资产组
• 漏洞
• 用户添加标签

如果您在迁移后注意到数据中的任何差异，请联系Rapid7支持．

确认迁移成功后，执行以下任务:

1. 作为故障保护，保存/ nxpgsql-backup-dd-MM-yyyy-HH-MM目录到外部位置，以防需要回滚迁移到9.4。该目录包含迁移前9.4数据库的压缩副本。如果您选择跳过此步骤，则该目录将在整个迁移过程的第3步中删除。
2. 作为一种最佳实践，运行一个新的数据库备份操作，以保留迁移后数据库的基线实例。
3. 最后，将在准备迁移时为了磁盘空间的目的而迁移的任何Security Console文件或目录移回原位。

迁移花费了很长时间，没有新的状态消息。这是正常的吗?

根据数据量的不同，从9.4迁移到11.7可能需要几个小时。因此，长时间的迁移并不罕见，而且没有新状态消息的长时间迁移并不一定表明迁移是“挂起”的。您可以执行一些快速检查，以确认迁移仍在进行中，即使没有可见的状态消息:

• 运行前命令或在Windows下打开任务管理器。检查是否有PostgreSQL进程正在运行并占用CPU资源。
• 您还可以检查迁移日志文件中关于正在复制的数据库表的消息:
  • Linux-/ opt / rapid7 / nexpose / nsc / nxpgsql / pgsql / bin / pg_upgrade_ * . log
  • 窗户-C:\Program Files\Rapid7\NeXpose\nsc\nxpgsql\pgsql\bin\ pg_upgrade_ * . log

迁移过程完成后，Security Console将重新启动并显示一条成功消息。

如果在迁移完成之前停止迁移，会发生什么?

如果您选择在迁移完成之前取消迁移，Security Console将停止迁移过程，并删除在此之前创建的任何构件。然后可以重新启动安全控制台，使其处于正常的操作模式。

如果迁移失败，该怎么办?

通常，如果迁移失败，当前版本的PostgreSQL数据库将保持完整。只需重新启动安全控制台并恢复正常操作。如果您重试迁移，并且第二次失败，请联系Rapid7支持寻求帮助。

如果迁移由于系统故障或断电而失败，而您试图再次运行迁移，则可能会遇到磁盘空间限制问题。这是由安全控制台创建nxpgsql-temp目录。要解决此问题，请删除此目录并再次开始迁移。临时目录的位置如下:

• Linux-/ opt / rapid7 / nexpose / nsc /
• 窗户-C:\Program Files\Rapid7\NeXpose\nsc\