从 MySQL 数据库流式传输数据

借助 Datastream，您可以将历史数据和持续更改从源 MySQL 数据库复制到目标数据库，以进行实时分析和数据库同步。

在配置 MySQL 来源之前，请先查看 Datastream 中的复制行为、支持的版本和数据库类型、最佳实践和已知限制。

行为

本部分介绍了使用 Datastream 复制数据时 MySQL 来源的行为。从 MySQL 数据库中注入数据时，您可以使用基于 binlog 的复制或基于全局事务标识符 (GTID) 的复制。您可以在创建流时选择 CDC 方法。

基于 Binlog 的复制

Datastream 可以使用二进制日志文件来记录 MySQL 数据库中的数据更改。然后，这些日志文件中包含的信息会复制到目标位置，以重现对来源所做的更改。

Datastream 中基于 binlog 的复制的主要特征如下：

  • 您可以选择给定 MySQL 来源中的所有数据库或特定数据库，以及数据库中的所有表或特定表。
  • 复制所有历史数据。
  • 所有数据操纵语言 (DML) 更改（例如从指定数据库和表中插入、更新和删除）都会被复制。
  • 仅复制已提交的更改。

基于全局事务标识符 (GTID) 的复制

Datastream 还支持基于全局标识符 (GTID) 的复制。

全局事务标识符 (GTID) 是一个唯一标识符，它在 MySQL 来源上提交的每个事务中创建并与之关联。此标识符不仅对于其来源是唯一的，而且在给定复制拓扑中的所有服务器中也是唯一的，这与基于二进制日志的复制不同，在基于二进制日志的复制中，数据库集群中的每个节点都维护自己的 binlog 文件，并有自己的编号。如果发生故障或计划内停机，维护单独的 binlog 文件和编号可能会成为问题，因为 binlog 连续性会中断，并且基于 binlog 的复制会失败。

基于 GTID 的复制支持故障切换、自管理数据库集群，并且无论数据库集群发生何种变化，都可以继续运行。

Datastream 中基于 GTID 的复制的主要特征如下：

  • 您可以选择给定 MySQL 来源中的所有数据库或特定数据库，以及数据库中的所有表或特定表。
  • 复制所有历史数据。
  • 所有数据操纵语言 (DML) 更改（例如从指定数据库和表中插入、更新和删除）都会被复制。
  • 仅复制已提交的更改。
  • 无缝支持故障切换。

从基于 binlog 的复制切换到基于 GTID 的复制

如果您想更新数据流并从基于 binlog 的复制切换到基于 GTID 的复制，而无需执行回填，请执行以下步骤：

  1. 确保满足基于 GTID 的复制的所有要求。如需了解详情，请参阅配置源 MySQL 数据库。
  2. （可选）创建并运行测试基于 GTID 的数据流。如需了解详情，请参阅创建数据流。
  3. 创建基于 GTID 的数据流。先不要启动。
  4. 停止流向来源数据库的应用流量。
  5. 暂停现有的基于 binlog 的数据流。如需了解详情，请参阅暂停直播。
  6. 等待几分钟，确保 Datastream 已赶上数据库。您可以使用数据流的数据流详情页面上监控标签页中的指标来检查此情况。数据新鲜度和吞吐量的值需要为 0。
  7. 启动基于 GTID 的数据流。如需了解详情，请参阅启动数据流。
  8. 恢复流向源数据库的流量。

如果执行回填不是问题，您可以在 BigQuery 中截断表，删除旧数据流，然后启动包含回填的新数据流。如需详细了解如何管理回填，请参阅管理数据流对象的回填。

版本

Datastream 支持以下版本的 MySQL 数据库：

  • MySQL 5.6
  • MySQL 5.7
  • MySQL 8.0

  • MySQL 8.4（仅支持基于 GTID 的复制）

Datastream 支持以下类型的 MySQL 数据库：

最佳做法

本部分介绍了配置 MySQL 来源以与 Datastream 搭配使用的推荐最佳实践。

对高可用性设置使用 GTID

如果您的生产 MySQL 来源使用副本或任何其他高可用性配置，请使用基于 GTID 的复制。

在数据库故障切换期间，基于 binlog 文件和位置的复制可能会中断，因为当主数据库发生故障时，新的主数据库具有不同的 binlog 历史记录。在这种情况下，Datastream 会丢失其位置，并且无法恢复。

GTID 会为整个复制拓扑（主实例和副本）中的每个事务分配一个唯一 ID。故障切换后，Datastream 可以从新主实例上记录的最后一个 GTID 恢复，而无需知道 binlog 文件或位置。

建议：对于具有副本或高可用性配置的任何生产 MySQL 来源，必须使用 GTID CDC 方法来实现弹性可靠的数据复制。

合理调整读取副本的大小

如果您将 Datastream 配置为从读取副本进行复制，则可能会遇到双重延迟，即 MySQL 复制延迟（从主实例到副本）和 Datastream 复制延迟（从副本到目标位置）的组合。为了节省成本，只读副本通常预配的资源（CPU、RAM、IOPS）少于主实例，这可能会导致它们在写入高峰期落后于主实例。

建议：将读取副本用作 Datastream 的来源时，请为其预配与主实例相当的资源，以便副本能够跟上主实例的写入吞吐量。

提高 binlog CDC 方法的吞吐量

如果您使用的是基于 binlog 的复制，并且由于源写入量大导致 binlog 文件的生成速度快于单个任务的处理速度，从而导致延迟时间较长，请通过调整 maxConcurrentCdcTasks 参数来提高吞吐量。此参数控制数据流并行运行的 CDC 任务数量。增加此参数的值可让 Datastream 同时处理更多 binlog 文件。

建议：如需确定合适的数据新鲜度值，请在高峰时段监控 MySQL 服务器的 binlog 生成速率。为此，您可以观察 MySQL 数据目录中新 binlog 文件的创建和轮替速率，也可以使用 MySQL 监控工具跟踪二进制日志的增长情况。例如，如果您的来源在高峰期每分钟生成 10 个 binlog 文件，则将 maxConcurrentCdcTasks 设置为 10-15 等值可让 Datastream 并行处理这些文件，从而防止积压。

您可以将 maxConcurrentCdcTasks 增加到支持的最大值 50，前提是源数据库上的负载保持在可控范围内。如需了解详情，请参阅直播并发控制。

正确设置 max_allowed_packet 参数的大小

MySQL 中的默认 max_allowed_packet 设置（例如 16MB-64MB）可能太小。如果包含大型 BLOB、JSON 或 TEXT 类型字段的单行或单个大型事务超过此大小，MySQL 会终止 Datastream 连接，从而导致流失败并出现 Packet for query is too large 或 Got a packet bigger than 'max_allowed_packet' bytes 等错误。

建议：将 MySQL 服务器上的 max_allowed_packet 参数设置为其允许的最大值 1G。这可确保服务器能够处理 Datastream 需要从 binlog 中读取的任何大型行或事务。

已知限制

将 MySQL 数据库用作来源的已知限制包括：

  • 数据流限 10,000 个表。
  • 复制的表必须使用 InnoDB 存储引擎。不支持使用 MyISAM 存储引擎的表，并且这些表无法通过流验证。
  • 主键定义为 INVISIBLE 的表无法回填。
  • 除非满足以下条件，否则无法回填行数超过 5 亿的表：
    1. 该表具有唯一索引。
    2. 索引的所有列都不可为 null。
    3. 索引不是降序。
    4. 索引的所有列都会包含在数据流中。
  • Datastream 在处理事件时定期从来源提取最新的架构。如果架构发生更改，Datastream 会检测到架构更改并触发架构提取。不过，在架构提取之间，某些事件可能会被错误处理或丢弃，这可能会导致数据差异。
  • 并非所有对源架构的更改都可以自动检测到，在这种情况下可能会发生数据损坏。以下架构更改可能会导致数据损坏或无法处理下游事件：
    • 删除列
    • 在表中间添加列
    • 更改列的数据类型
    • 对列重新排序
    • 删除表（如果同一表被重新创建并添加了新的数据，则与此相关）
    • 截断表
  • Datastream 不支持复制视图。
  • Datastream 不支持空间数据类型的列，例如 GEOMETRY、POINT、LINESTRING、POLYGON。这些列中的值会替换为 NULL 值。
  • Datastream 不支持数据类型为 DATETIME、DATE 或 TIMESTAMP 的列中的零值 (0000-00-00 00:00:00)。零值会被替换为 NULL 值。
  • Datastream 不支持复制在 JSON 列中包含以下值的行：DECIMAL、NEWDECIMAL、TIME、TIME2、DATETIME、DATETIME2、DATE、TIMESTAMP 或 TIMESTAMP2。包含此类值的事件会被舍弃。
  • Datastream 不支持二进制日志事务压缩。
  • Datastream 不支持大于 4 GiB 的二进制日志文件。 由于 MySQL 会将每个事务写入单个二进制日志文件，因此请将单个事务保持在 4 GiB 以下，以便二进制日志文件不超过此限制。
  • Datastream 不支持源 MySQL 连接配置文件中的 SSL 证书链。仅支持单个 x509 PEM 编码证书。
  • Datastream 不支持级联操作：ON UPDATE CASCADE 和 ON DELETE CASCADE。此类事件不会写入二进制日志，因此不会传播到目标位置。作为权宜解决方法，您可以使用数据库触发器替换级联操作。
  • Datastream 不支持 DROP PARTITION 操作。此类操作仅为元数据操作，不会被复制。其他事件不受影响，数据流会成功运行。
  • 复制 FEDERATED 表时，您可能会遇到连接问题。如果发生这种情况，请从源数据库配置中移除所有 FEDERATED 表，并增加 connect_timeout、net_read_timeout 和 max_allowed_packet 参数的值，以缓解回填期间的超时问题。
  • Cloud SQL 企业 Plus 版实例必须使用基于 GTID 的复制，因为它们需要进行近乎零停机时间的维护。基于二进制日志的复制会在故障切换时中断，因此我们建议在高可用性应用场景中使用基于 GTID 的复制。
  • 对于 MySQL 8.0 及更高版本，binlog_row_value_options 变量必须设置为空值。对于大多数版本，这是默认设置，但对于某些版本（例如 Oracle Cloud Infrastructure [OCI] 上的 MySQL 来源），您必须明确设置。如需了解详情，请参阅配置自行管理的 MySQL 数据库。
  • MariaDB 限制：
    • MariaDB 不支持基于 GTID 的复制。您必须将 MariaDB 流配置为使用基于 binlog 的复制。
    • 对于 MariaDB 11.4 至 12.2 版本，您必须在源数据库上启用 binlog_legacy_event_pos 系统变量，以确保与 Datastream 兼容。
    • Datastream 不支持 UUID 数据类型（在 MariaDB 10.7 中引入）。您必须从数据流配置中排除 UUID 数据类型的列。

基于 GTID 的复制的其他限制

  • 只有在使用 Datastream API 时，才能恢复使用基于 GTID 的复制的数据流。
  • 不支持使用 CREATE TABLE ... SELECT 语句从其他表创建表。
  • Datastream 不支持带标记的 GTID。
  • 如需了解适用于基于 GTID 的复制的 MySQL 限制，请参阅 MySQL 文档。

后续步骤