[jira] [Commented] (HBASE-20530) Composition of backup directory containing namespace when restoring is different from the actual hfile location
[
https://issues.apache.org/jira/browse/HBASE-20530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468509#comment-16468509
]
maxwellguo commented on HBASE-20530:
I also meet this question ,and i have fixed this bug on my own code ,also i do
some tests of backup and restore on hdfs and other fs. it looks like good. I
just change the copy dest path of hfile (covered from wal ). after write some
unit test ,i will attached the path latter.
> Composition of backup directory containing namespace when restoring is
> different from the actual hfile location
> ---
>
> Key: HBASE-20530
> URL: https://issues.apache.org/jira/browse/HBASE-20530
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Vladimir Rodionov
>Priority: Critical
>
> Here is partial listing of output from incremental backup:
> {code}
> 5306 2018-05-04 02:38
> hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/table_almphxih4u/cf1/5648501da7194783947bbf07b172f07e
> {code}
> When restoring, here is what HBackupFileSystem.getTableBackupDir returns:
> {code}
> fileBackupDir=hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/default/table_almphxih4u
> {code}
> You can see that namespace gets in the way, leading to inability of finding
> the proper hfile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-12259) Bring quorum based write ahead log into HBase
[ https://issues.apache.org/jira/browse/HBASE-12259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359814#comment-16359814 ] maxwellguo edited comment on HBASE-12259 at 2/11/18 7:52 AM: - [~stack] sorry, I mean ,why this project was abandoned,because i think this feature can ipmrove the availability of HBase 's write and the when read throug raft ,we the data can not be stale.:D was (Author: maxwellguo): sorry, I mean ,why this project was abandoned,because i think this feature can ipmrove the availability of HBase 's write and the when read throug raft ,we the data can not be stale.:D > Bring quorum based write ahead log into HBase > - > > Key: HBASE-12259 > URL: https://issues.apache.org/jira/browse/HBASE-12259 > Project: HBase > Issue Type: Improvement > Components: wal >Affects Versions: 2.0.0 >Reporter: Elliott Clark >Priority: Major > Attachments: Architecture for HydraBase (5).pdf, > RaftProtocolImplementationDesignDoc.pdf > > > HydraBase ( > https://code.facebook.com/posts/32638043166/hydrabase-the-evolution-of-hbase-facebook/ > ) Facebook's implementation of HBase with Raft for consensus will be going > open source shortly. We should pull in the parts of that fb-0.89 based > implementation, and offer it as a feature in whatever next major release is > next up. Right now the Hydrabase code base isn't ready to be released into > the wild; it should be ready soon ( for some definition of soon). > Since Hydrabase is based upon 0.89 most of the code is not directly > applicable. So lots of work will probably need to be done in a feature branch > before a merge vote. > Is this something that's wanted? > Is there anything clean up that needs to be done before the log > implementation is able to be replaced like this? > What's our story with upgrading to this? Are we ok with requiring down time ? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-12259) Bring quorum based write ahead log into HBase
[ https://issues.apache.org/jira/browse/HBASE-12259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359814#comment-16359814 ] maxwellguo commented on HBASE-12259: sorry, I mean ,why this project was abandoned,because i think this feature can ipmrove the availability of HBase 's write and the when read throug raft ,we the data can not be stale.:D > Bring quorum based write ahead log into HBase > - > > Key: HBASE-12259 > URL: https://issues.apache.org/jira/browse/HBASE-12259 > Project: HBase > Issue Type: Improvement > Components: wal >Affects Versions: 2.0.0 >Reporter: Elliott Clark >Priority: Major > Attachments: Architecture for HydraBase (5).pdf, > RaftProtocolImplementationDesignDoc.pdf > > > HydraBase ( > https://code.facebook.com/posts/32638043166/hydrabase-the-evolution-of-hbase-facebook/ > ) Facebook's implementation of HBase with Raft for consensus will be going > open source shortly. We should pull in the parts of that fb-0.89 based > implementation, and offer it as a feature in whatever next major release is > next up. Right now the Hydrabase code base isn't ready to be released into > the wild; it should be ready soon ( for some definition of soon). > Since Hydrabase is based upon 0.89 most of the code is not directly > applicable. So lots of work will probably need to be done in a feature branch > before a merge vote. > Is this something that's wanted? > Is there anything clean up that needs to be done before the log > implementation is able to be replaced like this? > What's our story with upgrading to this? Are we ok with requiring down time ? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (HBASE-12259) Bring quorum based write ahead log into HBase
[ https://issues.apache.org/jira/browse/HBASE-12259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated HBASE-12259: --- Comment: was deleted (was: why? [~stack] ) > Bring quorum based write ahead log into HBase > - > > Key: HBASE-12259 > URL: https://issues.apache.org/jira/browse/HBASE-12259 > Project: HBase > Issue Type: Improvement > Components: wal >Affects Versions: 2.0.0 >Reporter: Elliott Clark >Priority: Major > Attachments: Architecture for HydraBase (5).pdf, > RaftProtocolImplementationDesignDoc.pdf > > > HydraBase ( > https://code.facebook.com/posts/32638043166/hydrabase-the-evolution-of-hbase-facebook/ > ) Facebook's implementation of HBase with Raft for consensus will be going > open source shortly. We should pull in the parts of that fb-0.89 based > implementation, and offer it as a feature in whatever next major release is > next up. Right now the Hydrabase code base isn't ready to be released into > the wild; it should be ready soon ( for some definition of soon). > Since Hydrabase is based upon 0.89 most of the code is not directly > applicable. So lots of work will probably need to be done in a feature branch > before a merge vote. > Is this something that's wanted? > Is there anything clean up that needs to be done before the log > implementation is able to be replaced like this? > What's our story with upgrading to this? Are we ok with requiring down time ? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-12259) Bring quorum based write ahead log into HBase
[ https://issues.apache.org/jira/browse/HBASE-12259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359721#comment-16359721 ] maxwellguo commented on HBASE-12259: why? [~stack] > Bring quorum based write ahead log into HBase > - > > Key: HBASE-12259 > URL: https://issues.apache.org/jira/browse/HBASE-12259 > Project: HBase > Issue Type: Improvement > Components: wal >Affects Versions: 2.0.0 >Reporter: Elliott Clark >Priority: Major > Attachments: Architecture for HydraBase (5).pdf, > RaftProtocolImplementationDesignDoc.pdf > > > HydraBase ( > https://code.facebook.com/posts/32638043166/hydrabase-the-evolution-of-hbase-facebook/ > ) Facebook's implementation of HBase with Raft for consensus will be going > open source shortly. We should pull in the parts of that fb-0.89 based > implementation, and offer it as a feature in whatever next major release is > next up. Right now the Hydrabase code base isn't ready to be released into > the wild; it should be ready soon ( for some definition of soon). > Since Hydrabase is based upon 0.89 most of the code is not directly > applicable. So lots of work will probably need to be done in a feature branch > before a merge vote. > Is this something that's wanted? > Is there anything clean up that needs to be done before the log > implementation is able to be replaced like this? > What's our story with upgrading to this? Are we ok with requiring down time ? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-18745) HBase PerformanceEvaliation tools 's scan test just get the first value and return
maxwellguo created HBASE-18745:
--
Summary: HBase PerformanceEvaliation tools 's scan test just get
the first value and return
Key: HBASE-18745
URL: https://issues.apache.org/jira/browse/HBASE-18745
Project: HBase
Issue Type: Bug
Components: scan, test
Affects Versions: 1.1.12, 1.2.6
Environment: centos 6.8;
java 1.8.0_102;
Reporter: maxwellguo
Priority: Minor
Fix For: 2.0.0
h5. we use HBase PerformanceEvaluation tools to test HBase,when using scan
interface to test ,we found that scanTest said that it read all row ,but after
read the source code ,we foud it just read the the first row and return .and
after making a comparison with randomSeekScanTest,it read all row ,so we think
it is a bug .
void testRow(final int i) throws IOException {
if (this.testScanner == null) {
Scan scan = new Scan(format(opts.startRow));
scan.setCaching(opts.caching);
if (opts.addColumns) {
scan.addColumn(FAMILY_NAME, QUALIFIER_NAME);
} else {
scan.addFamily(FAMILY_NAME);
}
if (opts.filterAll) {
scan.setFilter(new FilterAllFilter());
}
this.testScanner = table.getScanner(scan);
}
Result r = testScanner.next();
updateValueSize(r);
}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
