ClickPipes for MySQL 常见问题
MySQL ClickPipe 是否支持 MariaDB？
是的，MySQL ClickPipe 支持 MariaDB 10.0 及以上版本。其配置与 MySQL 非常相似，默认使用 GTID 复制。
MySQL ClickPipe 是否支持 PlanetScale、Vitess 或 TiDB？
不支持，这些系统不支持 MySQL 的 binlog API。
复制是如何管理的？
我们同时支持 GTID 和 FilePos 复制。与 Postgres 不同，这里没有用于管理偏移量的 slot。相应地，您必须将 MySQL 服务器配置为具有足够的 binlog 保留期。如果我们在 binlog 中的偏移量失效（例如管道暂停时间过长，或在使用 FilePos 复制时数据库发生故障切换），则需要重新同步该 pipe。请务必根据目标表优化物化视图，因为低效查询会减慢摄取速度，导致落后于保留期。
对于不活跃的数据库，也有可能在尚未允许 ClickPipes 推进到更近期偏移量之前就轮换日志文件。您可能需要设置一个带有定期更新的心跳表。
在初始加载开始时，我们会记录一个 binlog 偏移量作为起始位置。为了让 CDC 能够继续推进，在初始加载完成时该偏移量必须仍然有效。如果您正在摄取大量数据，请务必配置合适的 binlog 保留期。在设置表时，可以在高级设置中为大型表配置 Use a custom partitioning key for initial load，以加速初始加载，从而使我们能够并行加载单个表。
连接到 MySQL 时，为什么会收到 TLS 证书验证错误？
连接到 MySQL 时，您可能会遇到诸如 x509: certificate is not valid for any names 或 x509: certificate signed by unknown authority 的证书错误。出现这些错误是因为 ClickPipes 默认启用 TLS 加密。
您可以通过以下几种方式解决这些问题：
-
设置 TLS Host 字段 - 当连接中的主机名与证书不一致时（在通过 AWS PrivateLink 的 Endpoint Service 连接时较为常见）。将 “TLS Host (optional)” 设置为与证书的 Common Name (CN) 或 Subject Alternative Name (SAN) 匹配。
-
上传 Root CA - 适用于使用内部证书颁发机构（CA）或在默认的每实例 CA 配置下运行的 Google Cloud SQL 的 MySQL 服务器。有关如何获取 Google Cloud SQL 证书的更多信息，请参阅此部分。
-
配置服务器证书 - 更新服务器的 SSL 证书，使其包含所有连接主机名，并使用受信任的证书颁发机构。
-
跳过证书验证 - 适用于自托管的 MySQL 或 MariaDB，其默认配置会生成我们无法验证的自签名证书（MySQL、MariaDB）。依赖此证书可以加密传输中的数据，但存在服务器被冒充的风险。我们建议在生产环境中使用由可信 CA 正式签发的证书，但该选项在一次性测试实例或连接到遗留基础设施时非常有用。
是否支持模式（schema）变更？
有关更多信息，请参阅 ClickPipes for MySQL: Schema Changes Propagation Support 页面。
是否支持复制 MySQL 外键级联删除 ON DELETE CASCADE？
由于 MySQL 处理级联删除的方式，这类操作不会写入 binlog。因此，ClickPipes（或任何 CDC 工具）都无法复制它们。这可能导致数据不一致。建议改用触发器来支持级联删除。
为什么我无法复制名称中包含点的表？
PeerDB 目前存在一个限制：源表标识符（即 schema 名称或表名）中包含点时，将不支持复制，因为在按点分割后，PeerDB 无法区分哪部分是 schema、哪部分是表名。 我们正致力于支持分别输入 schema 和表名，以绕过这一限制。
