您可以恢复永久失败的数据流，而无需创建新的数据流。 为此，您可以指定 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 来源：文件名字段中的日志文件名和日志位置 位置字段中指定的位置。如果您未指定位置，则流式传输会从指定日志文件中的第一个位置继续。
- 对于 Oracle 源：系统更改编号 (SCN) 字段中的系统更改编号 (SCN)。此字段是必填字段。
点击应用。
恢复数据流后，数据流页面中的已恢复列中会显示时间戳。
恢复 PostgreSQL 源的流
如需恢复 PostgreSQL 源的数据流，您需要提供复制 。服务器使用此复制槽向 Datastream 发送事件。复制槽名称可与用于失败数据流的槽相同， 不同：
- 如果新复制槽的名称不同，请向 Datastream 提供新的复制槽名称。
如果您未提供复制槽名称，Datastream 将使用 源配置中指定的复制槽名称。
如需详细了解复制槽，请参阅配置源 PostgreSQL 数据库。
在日志位置丢失和日志位置丢失之间发生的任何来源更改事件 新复制槽中的第一个 LSN 会丢失。您可以通过执行回填来恢复这些更改。
如需恢复 PostgreSQL 源永久失败的数据流，请执行以下操作： 操作步骤：
前往 Google Cloud 中的数据流页面。
在要恢复的数据流名称行中，点击恢复。
系统随即会打开定义新的复制槽窗格。
在复制槽名称字段中，提供新复制的名称 音频流将尝试从该槽中恢复。如果您使用相同的名称重新创建了复制槽，或者您想重复使用在配置来源时指定的槽，则可以将此字段留空。
点击应用。
恢复数据流后，已恢复列中会显示时间戳 在信息流页面中。
您还可以从数据流详情页面恢复永久失败的数据流。为此，请在查看详细信息时点击恢复数据流 与你的直播有关
恢复 SQL Server 源的数据流
如需恢复 SQL Server 源的流式传输，您可以使用以下选项：
从第一个可用位置继续：如果日志被截断或变更表中缺失一些记录，并且您想从第一个可用事件开始恢复，请选择此选项。丢失的活动会丢失，但您可以恢复 通过执行回填来对它们进行更新
使用首选日志序列号 (LSN) 恢复：选择此选项可以 从事务日志或变更表中恢复来自特定 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 的连续性。
后续步骤
- 如需详细了解数据流状态，请参阅数据流生命周期。
- 如需了解如何查看数据流的相关信息，请参阅查看数据流。
- 如需了解如何监控数据流，请参阅监控数据流。
- 如需了解如何管理数据流的回填，请参阅管理数据流对象的回填。
- 如需了解如何删除现有信息流，请参阅删除信息流。