Jianfeng Jia created ASTERIXDB-2113:
---------------------------------------
Summary: A large (58G) component is generated when use correlated
policy
Key: ASTERIXDB-2113
URL: https://issues.apache.org/jira/browse/ASTERIXDB-2113
Project: Apache AsterixDB
Issue Type: Bug
Components: STO - Storage
Environment: 0.9.2-SNAPSHOT
"git.commit.time": "07.08.2017 @ 09:54:02 PDT",
Reporter: Jianfeng Jia
Assignee: Chen Luo
The symptom of the problem is that AsterixDB generates a 58G component on disk
that the filtering technique cannot speed up the query anymore.
The source of the bug is ASTERIXDB-2081 which prevented the recovery after the
restart. Then we remove the log files on the failed-to-recover nodes to skip
the recovery. When the failed node restart from a clean history it somehow
decide to merge a large number of historical components into a huge one. Though
the system is already in an inconsistent state, I wonder if it is possible that
we operate some defensive check to prevent generating this huge component?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
