You are viewing a plain text version of this content. The canonical link for it is here.

Posted to notifications@asterixdb.apache.org by "Jianfeng Jia (JIRA)" <ji...@apache.org> on 2017/09/28 21:38:00 UTC

[jira] [Created] (ASTERIXDB-2113) A large (58G) component is generated when use correlated policy

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)