[
https://issues.apache.org/jira/browse/HBASE-6158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288890#comment-13288890
]
Aditya Kishore commented on HBASE-6158:
---------------------------------------
> Is this change incompatible for rolling upgrade?
I don't think so. These are temporary work folders which get cleaned up
routinely and particularly at Region Server (re)start for each region through
HRegion.initialize().
However, a possible side effect could be that "merges" and "splits" folders
created by pre-upgrade code (which somehow did not get cleaned up during a
shutdown) may continue to exist on the file system as the cleanup code would no
longer be looking for them. But this is better fixed in the upgrade scripts by
deleting these folders if they are found to be a work folder instead of a CF
container folder.
> Data loss if the words 'merges' or 'splits' are used as Column Family name
> --------------------------------------------------------------------------
>
> Key: HBASE-6158
> URL: https://issues.apache.org/jira/browse/HBASE-6158
> Project: HBase
> Issue Type: Bug
> Components: master, regionserver
> Affects Versions: 0.94.0
> Reporter: Aditya Kishore
> Assignee: Aditya Kishore
> Fix For: 0.92.2, 0.94.1
>
> Attachments: HBASE-6158_94.patch, HBASE-6158_trunk.patch
>
>
> If a table is creates with either 'merges' or 'splits' as one of the Column
> Family name it can never be flushed to the disk even though the table
> creation (and data population) succeeds.
> The reason for this is that these two are used as temporary directory names
> inside the region folder or merge and splits respectively and hence conflicts
> with the directories created for CF with same name.
> A simple fix would be to uses ".merges' and ".splits" as the working folder
> (patch attached). This will also be consistent with other work folder names.
> An alternate fix would be to declare these words (and other similar) as
> reserve words and throw exception when they are used. However, I do find the
> alternate approach as unnecessarily restrictive.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
