您可以恢复永久失败的数据流，而无需创建新的数据流。 为此，您可以指定 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。如需了解更多信息，请参阅恢复数据流： PostgreSQL 源）。
- 如果您未提供复制槽名称，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 的连续性。