问题标签 [tokudb]

尽管硬盘驱动器上有一些空间，但使用 tokuDB 存储引擎对表进行任何插入都会失败并出现以下错误：

错误代码：1021。磁盘已满（）；等待某人释放一些空间...（错误号：189“磁盘已满”）

其他存储引擎（例如 innodb ）上的插入仍在工作。

查看输出时遇到此错误

这是状态输出的摘录：

配置：

Master - Mysql 5.6.x // 有错误的表有 ENGINE=InnoDB

副本 - Percona 5.6.x // 有错误的表有 ENGINE=TokuDB

主服务器和复制服务器上的列定义完全匹配：

我需要在一个表上创建超过 64 个索引，但遇到了“指定的键太多；最多允许 64 个键”错误。是否有一些解决方法可以让我将 MariaDb / TokuDB 的这个限制增加到 1000 以上？或者有理由为什么这个限制是必要的？

（我已经看到这个问题被问到/回答了 MySQL - 答案是将 --with-max-indexes=256 传递给 ./configure，或者在编译时修改其中一个头文件中的 MAX_KEY。不幸的是，这些答案似乎不适用于 MariaDB）

附言。由于典型的响应是“如果您需要这么多索引，那么您做错了”，我将解释我为什么要这样做，如果这是最好的“解决方法”，我将不胜感激有关修改设计的任何建议。

我的数据存储在 2 个表中：

table1存储 5 列：（唯一键 x_position int、column1 string、column2 float、column3 int、column4 tinyint） ——它可以大到 1 亿行

table2在概念上可以表示为 4 列： (外键 x_position int, sample_id string, value1 tinyint, value2 float) - 因为可能有多达 5000 个唯一的 sample_id 值，并且每个 (x_position, sample_id) 对存在不同的 value1 ，最大行数为 1 亿 x 5000 = 5000 亿行

我需要做的查询是：

相反，我认为对 table2 进行透视会更有效，这样它的列是：（ 外键 x_position，sample_id1_value1 tinyint，sample_id1_value2 float，sample_id2_value1 tinyint，sample_id2_value2 float，...）

然后根据将一起查询这些列中的哪些列的特定于域的详细信息，在 (sample_id1_value1, sample_id1_value2, .. ) 列的小子集上创建复合索引。该表将有 1 亿行 x 10,000 列（拆分为多个表以避免列限制），这似乎比 5000 亿行要好。此外，它还将消除查询中对“或”和“分组依据”子句的需求，允许将查询重写为：

不幸的是，“太多键”错误阻碍了这一点。

我使用 mariadb 10.0.20 创建了两个带有 tokudb engine 的表。

我试图使用 JDBC 从 table2 插入到 table1

我有数百个表，例如 table2，每个表中有数百万条记录，当我有时在后端看到 show process list 的输出时，我看到“处理事务中止，34752 中有 11264 个”我不明白是否我的插入是否成功完成，有时它会进入死锁情况，它正在重新启动事务并失败。

请让我知道上述错误消息的原因

提前致谢

背景
昨天，我们遇到了一个（至少在我看来）像僵局一样的情况。已发出截断表（针对非竞争表运行），其状态为“查询已完成”，但从未从进程列表中清除。此外，与该架构中不相关的表的用户连接无法连接到“等待元数据锁定（或类似的，没有得到屏幕截图）”。

第一次尝试终止截断查询，然后挂起的查询导致它们的状态更改为“已终止”，但从未让它们从进程列表中消失。

此时，即使是超级用户也无法登录（之前打开的监视器显示连接为 -- 等待元数据锁定）。

尝试了有序关闭，但经过一段时间后，看起来操作系统 kill -9'd mysql。由于一堆记忆意外地似乎被固定住了，重新启动似乎是有序的并且完成了。

现在，在过去的 24 小时内，Percona 似乎要么重播（--非常---缓慢地）许多我无法想象的交易，要么处于某种重播循环中。为了让您了解日志消息：

因此，虽然日志序列和 TokuFT 提交 xid 数字似乎保持不变，但扫描的检查点和完成百分比（总是 ~49-55%）会随着运行而变化。

目前尚不清楚这是否以某种方式展开了一些巨大的事务（用户正在进行一些大规模的表更新、DDL 更改等，我确信 autocommit=0）或者这是一个永远不会结束的循环。

有关如何继续或进一步排除故障的任何提示？

谢谢。

我有一个 TokuDB 表，由于某种原因缺少 ***_status.tokudb 文件。

我还不确定该文件是否由于 TokuDB 崩溃而丢失。

问题是：

• 有没有办法从主文件和关键文件中恢复或重新创建状态文件（我可以从 tokudb_file 映射中看到。）？
• 如何调试导致 tokuDB 状态文件被删除的原因？

这真的很常见还是已知的错误？ https://github.com/percona/tokudb-engine/wiki/Broken-tables-caused-by-non-transactional-table-operations#unexplained-inconsistency-problems-with-tokudb

在 MariaDB 社区版中如何使用 Tokudb 热备份？( https://github.com/percona/tokudb-backup-plugin )

我已经读到现在这个库包含在社区版中，但是这个 SQL 给出了错误：

未知变量。

10.1.9-MariaDB-日志：tokudb-7.5.7

虽然 TokuDB 提供了很好的压缩，但据我所知，它分配的空间比实际需要的多得多，从而浪费了很多空间。

我正在使用 information_schema 来获取大小，如下所示：

这是结果

如您所见size_allocated，基本上翻了一番。磁盘上的文件只是比 size_allocated 多一点，因此使用 information_schema 报告是很好的。

我尝试运行优化几次，但没有太大帮助，有时甚至会增加。似乎唯一可行的解​​决方案是运行ALTER TABLEtbl engine=tokudb，但这需要很长时间，因为它完全重建了表。

有谁知道如何恢复未使用的空间？

（在 percona mysql 服务器上运行 tokudb 5.6.27-76.0）

我已经将数据库的表从 InnoDB 转换为 TokuDB，我注意到使用 TokuDB，读取使用的 CPU 太多。为什么是这样？

更具体地说，具有 TokuDB 表的服务器是具有 InnoDB 的服务器的从属服务器，InnoDB 是 PXC 的一部分。从站只是使用普通的 percona 服务器而不是 PXC。但是奴隶似乎使用了太多的CPU，我不知道为什么？

下面是我的 my.cnf 配置：

当 tokudb_cache_size 最初设置为总 RAM 的 80% 时，我们的监控系统 xymon 报告了以下复制消息。

------有关运行 InnoDB 的主服务器和部分 PXC 的更多信息-----------

我们最近开始测试从 mySQL5.6 升级到 percona server 5.7 以及 tokuDB 表的使用。该数据库为我们的 PHP 5.5 应用程序提供服务，该应用程序使用 PDO 库进行参数化查询。

在将具有相同数据的 percona 加载到 tokudb 表中并将性能与现有生产进行比较后，我们立即注意到性能大幅下降（慢了 10 倍）。对于下面的查询，假设表有 1200 万行

我已经能够在 5.7 数据库中将这个问题缩小到执行以下查询时的事实：

其中 id 是列类型整数。这是我的印象，我的研究似乎证实，当比较的列是数字类型时，mySQL 应该将“12345”隐式转换为 12345，但是这似乎在 mySQL5.7/Percona 中没有发生。它发生在 mySQL5.6x

这里的问题是，对于这种行为，您需要使用 PDOStatement::bindParam （参考http://php.net/manual/en/pdostatement.bindparam.php）为每个变量显式设置类型！这样做会导致几乎全局重写所有准备好的语句，这些语句当前将参数数组传递给不支持显式类型设置的 PDOStatement:execute()！

所以 - 我的问题是 - mySQL 中发生了一些变化，所以在 5.7 中没有进行隐式转换，或者是 Percona 还是 tokuDB 表？我可以设置一个配置参数来重新打开它吗？