您可以恢复永久失败的数据流，而无需创建新的数据流。为此，您可以指定 Datastream 尝试从源继续读取更改的位置。
数据流恢复概览
正在运行的数据流可能会遇到一些不可恢复的错误，并将其状态更改为 FAILED_PERMANENTLY。此类错误会导致数据流无法继续运行，并且可能会导致数据丢失。
您可以将永久失败的数据流设置为忽略错误并继续读取正在进行的事件，而不是重新创建数据流并回填历史数据，从而恢复数据流。如需恢复永久失败的数据流，您可以重置复制，以便从其他复制位置开始读取。每种受支持的来源类型都有自己的复制位置定义：
- 对于 Oracle 来源，复制位置是数据库中的重做日志文件以及此文件中的系统更改编号 (SCN)。
- 对于 MySQL 来源，复制位置是数据库二进制日志 (binlog) 文件及其在该文件中的位置。
- 对于 SQL Server 源，复制位置是事务日志或更改表中的日志序列号 (LSN)。
- 对于 PostgreSQL 源（包括 AlloyDB for PostgreSQL），复制位置是复制槽中的日志序列号 (LSN)。在恢复期间，数据流会从复制槽中的第一个 LSN 开始读取。
恢复 MySQL 或 Oracle 源的数据流
如需恢复 MySQL 或 Oracle 源的流，您可以使用以下选项：
从当前位置重试（推荐）：选择此选项可尝试从上次流式传输失败的当前位置继续流式传输。您需要先修复日志文件或从备份中恢复该文件。这是推荐的选项。
跳过当前位置，从下一个可用位置继续流式传输：如果缺少一个或多个日志文件，请选择此选项以跳过这些文件，而从下一个可用文件的第一个位置继续流式传输。缺失日志文件中记录的变更将会丢失，但您可以通过执行回填来恢复。
跳过当前位置，从最近的位置继续流式传输：如果缺少一个或多个日志文件，请选择此选项以跳过这些文件，而从最新日志文件中的最新位置继续流式传输。缺失日志文件中记录的变更将会丢失，但您可以通过执行回填来恢复。
从您首选的流式传输文件和位置继续：选择此选项将从特定的日志文件和日志位置继续数据流。如果指定的日志位置与丢失的日志位置不重叠或不紧邻其后，则部分变更可能会丢失。您可以通过执行回填来恢复这些更改。
如需恢复 MySQL 或 Oracle 源的永久失败数据流，请执行以下步骤：
前往 Google Cloud 中的数据流页面。
在要恢复的直播的名称所在行中，点击恢复。
系统随即会打开选择恢复策略窗格。选择一个选项。如果您选择从您首选的流式传输文件和位置继续，请输入以下内容：
- 对于 MySQL 来源：File name 字段中的日志文件名和 Position 字段中的日志位置。如果您未指定位置，则流式传输会从指定日志文件中的第一个位置继续。
- 对于 Oracle 源：系统更改编号 (SCN) 字段中的系统更改编号 (SCN)。此字段是必填字段。
点击应用。
恢复数据流后，数据流页面中的已恢复列中会显示时间戳。
恢复 PostgreSQL 源的流
如需恢复 PostgreSQL 来源的数据流，您需要提供复制槽名称。服务器使用此复制槽向 Datastream 发送事件。复制槽名称可以与用于失败串流的槽相同，也可以不同：
- 如果新复制槽的名称不同，请向 Datastream 提供新的复制槽名称。
如果您未提供复制槽名称，Datastream 将使用来源配置中指定的复制槽名称。
如需详细了解复制槽，请参阅配置源 PostgreSQL 数据库。
在日志位置丢失与新复制槽中第一个 LSN 之间发生的任何来源更改事件都将丢失。您可以通过执行回填来恢复这些更改。
如需恢复 PostgreSQL 源的永久失败数据流，请执行以下步骤：
前往 Google Cloud 中的数据流页面。
在要恢复的直播的名称所在行中，点击恢复。
系统随即会打开定义新的复制槽窗格。
在复制槽名称字段中，提供数据流将尝试从中进行恢复的新复制槽的名称。如果您使用相同的名称重新创建了复制槽，或者您想重复使用在配置来源时指定的槽，则可以将此字段留空。
点击应用。
恢复数据流后，数据流页面中的已恢复列中会显示时间戳。
您还可以从数据流详情页面恢复永久失败的数据流。为此，请在查看数据流的详细信息时点击恢复数据流。
恢复 SQL Server 源的串流
如需恢复 SQL Server 源的流式传输，您可以使用以下选项：
从第一个可用位置继续：如果日志被截断或变更表中缺少一些记录，并且您想从第一个可用事件开始恢复，请选择此选项。缺失的事件会丢失，但您可以通过执行回填来恢复它们。
从您首选的日志序列号 (LSN) 继续：选择此选项可从事务日志或变更表中的特定 LSN 恢复数据流。如果指定的 LSN 与 Datastream 能够检索到的最后一个 LSN 不重叠或不紧随其后，部分事件可能会丢失。您可以通过执行回填来恢复这些事件。
事务日志和更改表中的 LSN 均包含 20 个十六进制字符，但对于事务日志，它由分隔符分隔。例如：
- 事务日志中的 LSN：
0000123C:0000BA78:0004 - 更改表中的 LSN：
0000123C0000BA780004
- 事务日志中的 LSN：
如需恢复 SQL Server 源的永久失败数据流，请执行以下步骤：
前往 Google Cloud 中的数据流页面。
在要恢复的直播的名称所在行中，点击恢复。
系统随即会打开选择恢复策略窗格。选择一个选项。
点击应用。
恢复数据流后，数据流页面中的已恢复列中会显示时间戳。
在手动故障切换场景中，对 MySQL 来源使用流式恢复
您可以执行手动故障切换并使用数据流恢复功能，以免在维护期间或主实例发生故障时从头重新创建数据流。通常，Datastream 不支持向副本进行故障转移，因为这会破坏 binlog 的连续性，但您可以按照以下步骤恢复数据流并确保捕获变更数据：
- 停止对主实例的所有写入操作。
- 确保将数据新鲜度指标设置为 0。这意味着 Datastream 捕获了所有更改，并且没有要从来源读取的新事件。如需了解详情，请参阅监控数据流。
- 故障转移到新的数据库实例。
- 根据需要，将数据流的连接配置文件更新为新的数据库实例（例如，您可能需要更改数据库主机名或 IP 地址）。如需了解详情，请参阅修改连接配置文件。
- 从故障切换实例上的特定位置恢复数据流，以确保 CDC 连续性。
后续步骤
- 如需详细了解数据流状态，请参阅数据流生命周期。
- 如需了解如何查看数据流的相关信息，请参阅查看数据流。
- 如需了解如何监控数据流，请参阅监控数据流。
- 如需了解如何管理数据流的回填，请参阅管理数据流对象的回填。
- 如需了解如何删除现有数据流，请参阅删除数据流。