[
https://issues.apache.org/jira/browse/HBASE-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139121#comment-13139121
]
stack commented on HBASE-4377:
------------------------------
We want this?
{code}
+ } catch (Exception e) {
+ // Do nothing.
+ }
{code}
Why not let the test fail if we can't delete the table?
I see we do this deleteTable in a few places w/ above ignore of IOE (the
deleteTable method is same in two places)
Nit: Belwo is a little wonky. No biggie.
{code}
+ HTableDescriptor[] htbls = // new HBaseAdmin(conf).listTables();
+ TEST_UTIL.getHBaseAdmin().listTables();
{code}
Nit: No biggie. Rewrite below if new patch made:
{code}
+ * This testing base class provides create a minicluster and testing table
table
+ * and shutsdown the cluster afterwards. It provides methods to wipes out meta,
+ * inject errors into meta and the file system.
{code}
This define is repeated:
{code}+ protected final static byte[][] splits = new byte[][] {
Bytes.toBytes("A"),
+ Bytes.toBytes("B"), Bytes.toBytes("C") };
{code}
Then there is : + byte[] splits = { 'A', 'B', 'C', 'D' };
Should we be looking for the missing region in the filesystem if we find a hole
in meta before we go ahead and create a region to plug the hole? Do we do that?
FYI, for future, I think there is utility in HRegion to do the below (with
defines for .regioninfo) and for writing it (Maybe there is a reason you did
the below manually?):
{code}
+ Path p = new Path(rootDir + "/" + htd.getNameAsString(),
+ hri.getEncodedName());
+ fs.mkdirs(p);
+ Path riPath = new Path(p, ".regioninfo");
{code}
FYI, there is utility in MetaReader to do this;
{code}
+ protected int scanMeta() throws IOException {
+ int count = 0;
+ HTable meta = new HTable(conf, HTableDescriptor.META_TABLEDESC.getName());
+ ResultScanner scanner = meta.getScanner(new Scan());
+ LOG.info("Table: " + Bytes.toString(meta.getTableName()));
+ for (Result res : scanner) {
+ LOG.info(Bytes.toString(res.getRow()));
+ count++;
+ }
+ return count;
+ }
{code}
Do we need setTableName? Should below be moved into HRI?
{code}
+ if (getTableName() == null || getTableName().length == 0) {
+ byte [] newTableName = HRegionInfo.getTableName(this.getRegionName());
+ LOG.debug(Bytes.toString(newTableName)+": .regioninfo doesn't have
tableName value, but we are getting it from regionName :)");
+ this.setTableName(newTableName);
+ }
{code}
This will be ok? We'll have perms to go here? If we don't we will just fail
which should be fine.
{code}
+ Path backupDir = new Path(rootDir.getParent(), rootDir.getName() + "-"
+ + now);
{code}
Next time, you could have made a method out of this and used it for meta and
root passing in 'root' or 'meta' and backupRoot -- its repeated code:
{code}
+ if (fs.exists(root)) {
+ fs.rename(root, backupRoot);
+ } else {
+ LOG.info("No previous -ROOT- exists. Continuing.");
+ }
{code}
Should you test the result of fs.rename? It returns a boolean true if it
succeeds and false if not?
Thats enough for now.
> [hbck] Offline rebuild .META. from fs data only.
> ------------------------------------------------
>
> Key: HBASE-4377
> URL: https://issues.apache.org/jira/browse/HBASE-4377
> Project: HBase
> Issue Type: New Feature
> Affects Versions: 0.92.0
> Reporter: Jonathan Hsieh
> Assignee: Jonathan Hsieh
> Attachments:
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90-v4.patch,
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.0.90.v3.patch,
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.patch,
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data-.trunk.v3.patch,
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v1.patch,
> 0001-HBASE-4377-hbck-Offline-rebuild-.META.-from-fs-data.0.92.v2.patch,
> EXT_AC.regioninfo, EXT_ATU_05f84d32cbc0bdabf00e00bc2f3570f0.regioninfo,
> hbase-4377-trunk.v2.patch, hbase-4377.trunk.v3.txt, hbase-4377.trunk.v4.txt,
> hbase-4377.trunk.v5.txt
>
>
> In a worst case situation, it may be helpful to have an offline .META.
> rebuilder that just looks at the file system's .regioninfos and rebuilds meta
> from scratch. Users could move bad regions out until there is a clean
> rebuild.
> It would likely fill in region split holes. Follow on work could given
> options to merge or select regions that overlap, or do online rebuilds.
--
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
