您可以恢复永久性失败的数据流，而无需创建新的数据流。 为此，您可以指定 Datastream 尝试从哪个位置继续读取源中的变更。
数据流恢复概览
正在运行的流可能会遇到一些不可恢复的错误，并将其状态更改为 FAILED_PERMANENTLY。此类错误会阻止数据流继续运行，并可能导致数据丢失。
您可以恢复永久性失败的数据流，方法是将该数据流设置为忽略错误并继续读取正在进行的事件，而不是重新创建数据流并回填历史数据。如需恢复永久性失败的数据流，您可以重置复制，以便从其他复制位置开始读取。每种受支持的源类型都有自己的复制位置定义：
- 对于 Oracle 源，复制位置是指数据库中的重做日志文件以及该文件中的系统更改编号 (SCN)。
- 对于 MySQL 源，复制位置是指数据库二进制日志 (binlog) 文件和此文件中的位置（对于基于 binlog 的复制），或者一组称为 GTID 集的全局事务标识符（对于基于 GTID 的复制，仅在 Datastream API 中受支持）。
- 对于 SQL Server 源，复制位置是指事务日志或变更表中的日志序列号 (LSN)。
- 对于 PostgreSQL 来源（包括 AlloyDB for PostgreSQL），复制位置是复制槽中的日志序列号 (LSN)。在恢复期间，数据流会从复制槽中的第一个 LSN 开始读取。
- 对于 MongoDB 源，复制位置是 MongoDB 操作日志 (oplog) 中的时间戳。
恢复 MySQL 或 Oracle 源的数据流
如需恢复 MySQL（基于 binlog 的复制）或 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 与 Datastream 能够检索到的最后一个 LSN 不重叠或不紧随其后，则可能会丢失一些事件。您可以通过执行回填来恢复这些事件。
事务日志和更改表中的 LSN 都包含 20 个十六进制字符，但对于事务日志，它由分隔符分隔。例如：
- 交易日志中的 LSN：
0000123C:0000BA78:0004 - 更改表中的 LSN：
0000123C0000BA780004
- 交易日志中的 LSN：
如需恢复 SQL Server 源的永久性失败数据流，请执行以下步骤：
前往 Google Cloud中的数据流页面。
在要恢复的直播的名称所在的行中，点击恢复。
系统会打开选择恢复策略窗格。选择一个选项。
点击应用。
恢复直播后，“直播”页面上的“已恢复”列中会显示时间戳。
恢复 MongoDB 源的数据流
您可以使用 Datastream API 为 MongoDB 源执行流恢复。您可以使用以下选项恢复 MongoDB 流：
最近的起始位置：如果您想从 MongoDB oplog 中的当前时间戳恢复数据流，请选择此选项。丢失的事件会丢失，但您可以通过执行回填来恢复这些事件。
特定开始位置：选择此选项可从所选时间戳继续数据流。您在请求中使用的时间戳必须有效，也就是说，它不能早于 MongoDB oplog 中可用的最早位置，也不能是未来的时间。
如需了解如何创建恢复 MongoDB 数据流的请求，请参阅 Datastream API 参考文档。
如需了解 MongoDB 操作日志，请参阅 MongoDB 文档。
在手动故障切换场景中，对 MySQL 源使用流恢复
您可以执行手动故障切换并使用流恢复，以避免在维护或主实例发生故障期间从头开始重新创建流。一般来说，Datastream 不支持故障转移到副本，因为这会中断 binlog 连续性，但您可以按照以下步骤恢复数据流并确保捕获变更数据：
- 停止对主实例的所有写入操作。
- 确保将“数据新鲜度”指标设置为 0。这意味着 Datastream 已捕获所有更改，并且没有新的事件可从来源中读取。如需了解详情，请参阅监控直播。
- 故障切换到新的数据库实例。
- 如果需要，请将数据流的连接配置文件更新为新的数据库实例（例如，您可能需要更改数据库主机名或 IP 地址）。 如需了解详情，请参阅修改连接配置文件。
- 从故障切换实例上的特定位置恢复数据流，以确保 CDC 连续性。
后续步骤
- 如需详细了解数据流状态，请参阅数据流生命周期。
- 如需了解如何查看有关直播的信息，请参阅查看直播。
- 如需了解如何监控数据流，请参阅监控数据流。
- 如需了解如何管理数据流的回填，请参阅管理数据流对象的回填。
- 如需了解如何删除现有直播，请参阅删除直播。