问题标签 [pt-online-schema-change]

我正在尝试更新一分钟前工作正常的表，但现在我遇到了一个过去遇到的错误，这非常不方便。

有没有什么选项可以让我忽略这些警告？毕竟这只是一个警告，所以 MySQL 仍然有能力继续前进并复制行。

其他解决方案也可以，比如找到表格中的违规值，或者删除无效部分，或者只是为了让我可以改变我的表格，这将是惊人的。

我在谷歌上搜索如何在 MySQL 中查找/替换损坏的 utf8 序列给我带来了这些链接（这不是很有帮助）

• https://dba.stackexchange.com/questions/77101/how-to-find-non-utf8-data-in-mysql/77154
• 在 MySQL 中检测 utf8 损坏的字符

我什至尝试搜索十六进制包含无效序列的所有列，但仍然不知何故没有运气

MySQL 版本为 5.7.18-15-57-log 和 pt-online-schema-change 3.0.8

更奇怪的是，我决定自娱自乐并搜索所有列（不仅仅是 utf8mb4 列），我得到了行！但我得到的唯一行来自我的二进制列？为什么在二进制列中有无效的 utf8 序列很重要？现在我认为这可能是该工具的错误

我对 MySQL (5.5.59) 有一个奇怪的问题：

我有一个日志数据库（我存储供应商请求的原始数据）。此表已压缩：

我的目标是通过删除旧记录并重建表来清理这张表。因为它是一张大桌子，所以我使用了 pt-online-schema-change 和 Oak-chunk-update 来完成这项工作。

我使用https://shlomi-noach.github.io/openarkkit/oak-chunk-update.html删除了所有去年的旧记录

然后我执行表的重建以释放可用空间（启用了 innodb_file_per_table

（重点是 --alter 语句）

所以现在，我有 2 张桌子：

• 日志（原始的）
• __new_logs 新日志（优化）

但它们在结构上并不相同：

返回此结果：

Why the table __new_logs is flagged "compact" and not compressed, but still has "create options" set to row_format=COMPRESSED KEY_BLOCK_SIZE=8

A show create table of the __new_logs table shows:

So it is still marked as compressed.

Last strange thing, the table __new_logs is bigger than the original logs table... I feel like the compression is not really done on this new table...

我最近一直在做一些数据库维护，偶然发现了一些很奇怪的东西。在标准程序清理过程中，我发现运行 pt-online-schema-change 之前的行数远低于运行 pt-online-schema-change 之后的行数。最初我认为这是一个显示错误并尝试重新连接。但是，行数保持不变。

在运行我的数据库维护之前，我从一个有 26.000.000 行的表中删除了 10.000.000 行。在此之后，我下降到 16.000.000 行。然后我运行 pt-online-schema-change 来添加一列。2 小时后完成后突然显示 18.000.000 行。所有这些都是在此表中几乎没有活动的时间段内进行的。& 进一步的挖掘表明，在 pt-online-schema-change 运行时只增加了大约 11.000 行。

所以。如何解释这一点？难道仅仅是因为 MySQL 的行数在大规模删除后变得不准确吗？因为这是我自己能想到的唯一合理解释，因为 pt-online-schema-change 创建了一个新表并迁移数据。这意味着该表上的行数是新的。

我使用 Sequel Pro，它似乎用来SHOW TABLE STATUS LIKE '...';读取行数。

有没有人在运行 pt-online-schema-change 后对行数跳跃有任何经验？

pt-online-schema-change 无法更改表。它在将行从原始表复制到新表的步骤中失败并抛出错误：复制行导致 MySQL 错误 1048：级别：警告代码：1048 消息：列“trans_datetime”不能为空

trans_datetime来自 show create table >> datetime DEFAULT NULL的“trans_datetime”列定义

这清楚地表明它可以有空值。实际上，我试图更改的表中的所有行都为“trans_datetime”为空

我正在运行以下 pt-osc 命令：

如果您需要更多信息，请告诉我。对此的任何帮助将不胜感激

我需要在现有 MySQL 表中添加一个新列，并填充从另一列计算的值。有没有办法做到这一点pt-online-schema-change？

谢谢

我正在运行 pt-online-schema-change，在该表的列上创建索引。

同时，我正在使用 for 循环脚本执行 write slap test 100 插入查询 100 次。

在这种情况下，在写入正常执行后的前 2 到 4 分钟，我们会遇到频繁的死锁。                                                  

在这种情况下的任何想法或建议

pt-online-schema-change 版本：3.0.11
Mysql 版本：5.7.25
环境：AWS RDS

pt-online 架构无法连接从服务器以监控副本滞后，使用以下命令并出现错误。

错误：

找到 1 个奴隶：

ip-175-02-1-69 -> dbops-replica01.adfghc.ap-southeast-1.rds.amazonaws.com:3306 无法连接到 MySQL：DBI connect(';host=1;mysql_read_default_group=client',' dbops_usr',...) 失败：无法在 /usr/bin/pt-online-schema-change 第 2345 行连接到“1”(22) 上的 MySQL 服务器。

我有一个运行 MySQL 5.5.46 的 RDS 实例，它有一个主键的表int，它目前有 19 亿条记录，接近 21 亿条限制和约 425GB 的大小。我正在尝试使用 pt-osc 将列更改为bigint.

我能够在测试服务器 (m3.2xlarge) 上成功测试更改，虽然完成大约需要 7 天，但它确实成功完成。该测试服务器没有额外的负载。（旁注：7 天似乎很长）。

对于生产环境，不存在复制/从属（但有多可用区），为了帮助解决资源争用和加快速度，我使用了 r3.8xlarge 实例类型。

两次尝试后，生产迁移将达到 50% 左右，还剩 1 天，然后 RDS 似乎会停止接受连接，迫使 pt-osc 两次回滚或彻底失败，因为 RDS 需要重新启动。

我在 RDS 控制台或日志中没有看到任何明显的信息来帮助说明发生这种情况的原因，我觉得实例类型应该能够处理大量连接/负载。

在我现在第三次尝试期间查看 CloudWatch 指标，数据库服务器本身似乎没有承受太多负载：5% CPU、59 个数据库连接、45GB 可用内存、写入 IOPS ~2200-2500。

想知道是否有人遇到过这种情况，如果有，对连接问题有什么帮助？

如果有人对如何加快整个过程有建议，我很想听听。我正在考虑尝试更长的chunk-size下班时间，但不确定这最终会如何影响应用程序。

我们的主要项目从一开始就一直使用现在非常古老的 Flyway 版本。(v3.2.1)

• 多年来，Flyway 进行了大量改进，v6+ 似乎为我们的 MySQL 模式包含了许多有趣的特性。
• 尝试支持的升级路径时，我遇到了一些问题——例如，我们的 .sql 迁移拒绝从头到尾迁移；Flyway v3.2.1 认为我们所有的 SQL 迁移都是有效的，但 v4+ 会因一些奇怪的注释语法而窒息。自然地，文件修复以使迁移工作会产生不同的校验和，这是安全升级的障碍。我很清楚 v5 中的模式表名称更改；这不是不可克服的。
• 我也在关注 Liquibase 与在线模式迁移工具；FB、Percona 和 GitHub 的 OST (gh-ost) 看起来很有趣，但我们使用外键，而且我们需要更多的副本，所以我们现在可能不会这样做。

目前，我对带有 Flyway v7 beta 或切换工具的新基线感兴趣。如果您在 k8s 上部署 SaaS 并有任何通用建议——我会接受，但我对一件事特别感兴趣：

人们如何克服新版本的 Flyway 不再接受现有 SQL 迁移的问题。或者，有没有人“放弃”并刚刚创建了一个新的基线，而不是进行漫长的升级路径？（或者，从 Flyway 切换到另一个具有类似优点的工具）

目前使用 AWS DMS 将数据从我们的 Aurora MySQL 数据库复制到 S3。这产生了一个低延迟的数据湖，我们可以使用它来获取所有发生的变化的沿袭，并从中构建额外的数据管道。但是，当通过 pt-online-schema-change 脚本进行更改时，修改后的表将完全停止复制。有什么理由会发生这种情况吗？

运行更改后，日志显示源表的架构不再符合 DMS 的预期，并且跳过了 CDC 更改。唯一可能的原因是 DMS 没有正确跟踪 DML 语句。

1. 使用 percona 触发的表更改（在这种情况下，添加列）
2. AWS DMS 同步的新表
3. 触发器在 AWS DMS 中添加了不支持的抛出警告
4. 表已重命名
5. 表列数不匹配，忽略多余的列。
6. 表列大小不匹配，跳过。

值得注意的是，AWS DMS 和 S3 支持 Percona 使用的所有 DML 语句（外部触发器）作为目标。有没有其他人对这种情况或工具组合有任何经验？

编辑：

下面是使用 Percona 进行这些更改的命令示例：