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

我想使用 pt-online-schema-change 来改变一个大表（~100M 记录）的模式，这个工具在运行时会影响 MySql 的性能吗？

我正在考虑使用表pt-online-schema-change的ALTER主键（将其从一列更改为复合主索引）。这样做有什么限制吗？该文件指出

在大多数情况下，除非表中存在 PRIMARY KEY 或 UNIQUE INDEX，否则该工具将拒绝操作。有关详细信息，请参阅 --alter。

我计划pt-online-schema-change在复制环境中的生产服务器上使用表更改工具。想了解pt-online-schema-change由于服务器工具而导致工具中止时执行的步骤。由于服务器负载而中止后是否可以恢复？它会删除临时表和它创建的触发器吗？我需要重新开始吗？

这是我可以使用 pt-online-schema-change 更改主键吗？.

目标：我想ALTER使用pt-online-schema-change. 具体来说，我想从单列主键迁移(a)到复合主键(a,b)（a两种情况下都是同一列）。

想法：我理解pt-online-schema-change当主键和唯一键都丢失时通常不起作用。为此，我的计划是：

1. 添加唯一键：pt-online-schema-change --alter "ADD UNIQUE tmp_unique_key(a)" D=mydb,t=mytable,u=root --execute
2. 修改主键：pt-online-schema-change --alter "DROP PRIMARY KEY, ADD PRIMARY KEY (a, b)" D=mydb,t=mytable,u=root --execute --check-alter. （--check-alter需要忽略DROP PRIMARY KEY错误）
3. 修改唯一键：pt-online-schema-change --alter "DROP KEY tmp_unique_key" D=mydb,t=mytable,u=root --execute.

实施：我已经在一个很小的本地表上测试了上述内容，并且没有出现故障。

问题：假设我有磁盘空间来保存临时唯一主键并且可以处理负载等，那么在大表上运行它有什么问题吗？

The production table I want to alter is around 700 Gb. I want to remove a FK from that table. Mysql version is 5.1.61-log.

I found following options:

pt-online-schema-change: alters a table’s structure without blocking reads or writes. This looks most efficient in terms alteration time. This also takes care of server load by dividing table copy into chunks and pauses data copy process in case of high load on the server.

The only problem with tool for me is available space on server is 450 GB and there is no room for another drive. This tool works on a copy of the table which is around 700 GB.

Upgrade to Mysql 5.6: With ONLINE DDL feature of 5.6, most of the ALTER types won’t block writes to a table that is being changed. Also it supports Add/Drop a foreign key constraint without the need of full table copy.

But I am not sure how it takes care of server load and how much time it going to take for alteration.

Is there any other option like pt-online-schema-change which doesn't have to copy table? Any experience/comments on ONLINE DDL of Mysql 5.6?

Thanks in advance!

我们已经使用Percona OSC一段时间了，在不锁定表的情况下更改我们的 mysql 模式并且效果很好，通常在几个内向“大型”innodb 表（约 380 万行）添加新列或索引小时。

然而，我尝试的最后一次更新在运行 7 小时后仅完成了 40%（一夜之间，在我们最安静的时期），估计还需要 11 小时才能完成（不断增加）。RedHat 服务器上所有 4GB 的可用内存都被使用了 - 32GB，我们最近从 16GB 升级。

那么这里发生了什么？为什么花费的时间会突然跳得这么高？我们是不是刚刚达到了某种percona/mysql/服务器无法应对的阈值？我们可以调整任何配置以提高性能吗？

该表有 32 列和 12 个索引（包括主键和 2 个其他唯一索引）。我知道这很多，但正如我所说，直到最近它表现还不错。

该表还有几个指向它的外键，我们设置为使用 drop_swap 方法进行更新。

我使用的完整命令是：

innodb_buffer_pool_size 当前设置为 2147483648 - 应该增加吗？如果是这样，多少？Web 服务器（apache/php/symfony）也在这个盒子上运行。

我对这个特定表所做的最后一次更改是将 1 个字段的排序规则更改为 utf8_bin（其他字段是 utf8_unicode_ci）——这会有所不同吗？

这是我在堆栈上的第一个问题，如果我做错了什么，请原谅我。我寻找一些可用于对数据库进行版本控制的工具。我为此找到了不错的程序，例如 Liquibase 或 Flyway，但听到开始我的问题。通常要对表进行更改，我使用命令行中的 pt-online-schema-change。这些工具都不支持命令行，所以我想问一下是否有人知道解决此问题的另一种方法，或者任何其他允许它的工具。

我有一个具有以下结构的复合主键的表：

CREATE TABLE field_name_test(
id_typevarchar(128) NOT NULL DEFAULT '',
descvarchar(128) NOT NULL DEFAULT '' ,
deletedtinyint(4) NOT NULL DEFAULT '0' ,
type_idint(10) unsigned NOT NULL ,
rev_idint(10) unsigned NOT NULL ,
langvarchar(32) NOT NULL DEFAULT '',
deltaint(10) unsigned NOT NULL,
fname_valuevarchar(255) DEFAULT NULL,
fname_formatvarchar(255) DEFAULT NULL,
PRIMARY KEY ( id_type, type_id, rev_id, deleted, delta, lang),
KEY id_type( id_type),
KEY desc( desc),
键deleted( deleted),
键type_id( type_id),
键rev_id( rev_id),
键lang( lang),
KEY fname_format( fname_format)
) 引擎=InnoDB 默认字符集=utf8

我正在运行 pt-osc 来更改表的排序规则，它与其他表一起工作正常，但是这个给出了以下错误：

没有找到奴隶。如果主机###### 有从机，请参见 --recursion-method。
未检查从属滞后，因为未找到从属并且未指定 --check-slave-lag。
操作，尝试，等待：
copy_rows, 10, 0.25
create_triggers, 10, 1
drop_triggers, 10, 1 swap_tables, 10, 1 update_foreign_keys
, 10, 1
Altering 。... 创建新表... 创建新表 db._field_name_test_new OK。 更改新表... 更改。好的。 2017-09-15T09:18:47 创建触发器... 2017-09-15T09:18:47 创建触发器正常。 2017-09-15T09:18:47 复制大约 3843064 行...
dbfield_name_test



db_field_name_test_new



2017-09-15T09:18:47 删除触发器...
2017-09-15T09:18:47 删除触发器 OK。
2017-09-15T09:18:47 删除新表...
2017-09-15T09:18:47 删除新表正常。
db. field_name_test没有改变。
2017-09-15T09:18:47 从db. field_name_test到
db. _field_name_test_new: 2017-09-15T09:18:47 在 db.field_name_test 的块 1 处复制行时出错，因为 MySQL 仅使用了 PRIMARY 索引的 390 字节而不是 497。有关更多信息，请参阅 --[no]check-plan 文档。

我在 Galera 3 节点集群中运行。

所以我对 pt-osc 有以下担忧：
1）对于上述情况，有哪些解决方案？
2) 是否可以在同一个数据库中运行并行 pt-osc ？

如果您需要任何其他输入，请告诉我。提前致谢。

如何使用 percona 修改表以允许空值。

我看到 --alter 但没有修改现有列。

我正在尝试使用 pt-online-schema-change 来更改我的数据库中某些表的架构。程序因以下 MySQL 错误而崩溃。我不需要抛出这种错误。我已经尝试将 disable-partition-engine-check 放在 MySQL 服务器的启动上。我正在使用 MySQL 版本 5.7.21

错误：