WAF's questions

背景

我有一个目录，其中包含运行 MongoDB 3.4.x 的 mongod 上.gz生成的文件，我正在使用. 除了一个之外，所有的都被正确加载。它们都需要 1 到 3 个小时来加载数据，然后再花费 2 到 4 个小时来重建索引。有问题的文件在下面的步骤之前挂起，我通常在大约一天后从外部终止该进程。我已经将场景重现了 4 或 5 次。mongodumpmongorestore ... --numInsertionWorkersPerCollection 8 --drop --nsFrom ... --nsTo ...

finished restoring database.collection (N documents) 

在这段时间内，该mongorestore进程仍然可以从 shell 中看到，但在 中没有相应的条目db.currentOp()，并且数据库的大小没有增加。

这些错误是在日志行“从元数据恢复集合数据库的索引。集合”之前返回的：

2017-03-13T09:30:04.218-0400    demux namespaceHeader: {database collection true 726142452659775357}
2017-03-13T09:30:04.218-0400    demux checksum for namespace database.collection is correct (726142452659775357), 54599167880 bytes
2017-03-13T09:30:04.218-0400    demux finishing (err:corruption found in archive; I/O error reading length or terminator ( gzip: invalid header ))

我发现了一些关于 mongorestore 挂起的报告（例如），以及一些关于/旧版本命名空间中 s 问题的文档（例如），但是我还没有找到关于我的情况的描述。

问题

现在我发现自己有一些迹象表明我加载的文件可能已损坏，或者至少有一个损坏的标题。向相关集合及其索引发出实际查询会返回看起来合理的结果。我怎样才能明确地检测或排除这种类型的“腐败”？在这种情况下，“腐败”究竟意味着什么？我可以期望在数据库中找到它，还是只能在 zip 文件中找到它？

更新：在@mustaccio 的建议下，我运行gzip -t了有问题的文件，它报告了“尾随垃圾”。这是否足以将 MongoDB 报告的问题固定在错误的输入上并停止在数据库中查找损坏？

如果从 MySQL 命令行执行查询，然后KILL在它运行时对其进行编辑，查询及其部分结果*是否会在查询缓存中并可用于相同查询的后续运行？

为简单起见，假设这是一个SELECT没有子查询的普通查询。

此页面上的排除列表涵盖查询不会被缓存的情况，例如查询表在执行之间更改，以及某些本质上不相同的操作，但我没有在任何地方看到中断或终止的查询。被杀死的查询一定不能被视为与运行完成的查询相同，但如果它满足所有其他缓存条件，它在被杀死之前就已经被缓存*，所以我想知道接下来会发生什么。

MySQL 5.6

_{*我在这里做了几个假设。}

MySQL 5.5.32，甲骨文 11g

mod()对于涉及非整数模数的查询，MySQL 会返回奇怪的结果。为什么是这样？

我有一个这样定义的列：

+--------+--------------+------+-----+---------+-------+
| Field  | Type         | Null | Key | Default | Extra |
+--------+--------------+------+-----+---------+-------+
| col    | double(15,6) | YES  |     | NULL    |       |
+--------+--------------+------+-----+---------+-------+

我从该列中选择了一个已知值用于测试 - 5850。如果我查询表，测试该列的整数，我得到这些结果：

mysql> SELECT thing_id,name FROM table WHERE col=5850 AND mod(col,1) != 0;
Empty set (1.07 sec)

这是意料之中的。但这不是：

mysql> SELECT thing_id,name FROM table WHERE col=5850 AND mod(col,.1) != 0;
+-----------+-----------+
| thing_id  | name      |
+-----------+-----------+
|   4444444 | some      |
|   4444445 | names     |
...
|  55555555 | go        |
|  55555556 | here      |
+-----------+-----------+
416 rows in set (1.07 sec)

替换的结果相同col MOD .1，col % .1因此它与计算而不是语义有关。

将此与 Oracle 的行为（如果重要，则使用 SQL Developer）进行比较，其中的类型col是NUMBER：

SELECT thing_id,name FROM table WHERE col=5850 AND mod(col,.1) != 0;
thing_id    name
[NO RECORDS]

MySQL 列的精度似乎造成了这种差异，但我不明白如何。从概念上讲，不应该integer_value % .1 = 0吗？

MySQL 5.6.23，InnoDB

我正在使用LOAD DATA INFILEcommnd 从字符分隔的文本文件中加载表格，并且我希望每个带有 a 的字段（此设置\N中的NULL字符）都将 aNULL放在表格中。一些数字类型有这种行为，而另一些则放置一个0. 我正在使用FIELDS TERMINATED BY并且某些列确实可以正确获取NULL值，因此它不是固定行格式问题。

这些是我在测试时观察到的类型：

• INT插入NULLs
• DECIMAL(x,0)插入NULLs
• DECIMAL(x,y)插入0.0s
• FLOAT插入0s
• DOUBLE(x,y)插入0.0s
• DOUBLE插入0s

所有有问题的列都用 定义DEFAULT NULL。我知道各种函数可以将这些0s 转换为NULLs。问题是是否存在可以处理小数精度并且还会NULL在加载时插入 s 的数据类型。

此外，我看到一大堆与误解字符串、空字符串和空值之间的区别有关的问题。（示例 示例 ）这不是问题，因为当我将其重新定义为 DECIMAL(x,0) 时，s 存在并正确加载到同一列中，然后在定义为 DECIMAL(x,3) 时不正确。NULL