replication contrib
building at J-D's request... he wants to update replication to match this patch
himself.
Thanks for the patch Kannan.
> row level atomicity
>
>
> Key: HBASE-2283
> URL: https://issues.apache.org/ji
n't meet the marker with HLog.Reader then
those edits won't be replayed?
> row level atomicity
>
>
> Key: HBASE-2283
> URL: https://issues.apache.org/jira/browse/HBASE-2283
> Project: Hadoop HBase
>
the refactoring, other we could satisfy a read
request from an uncommitted transaction. So, my above comment is not applicable.
> row level atomicity
>
>
> Key: HBASE-2283
> URL: https://issues.apache.org/jira/browse/HBASE-2283
&g
yet worked out).
> row level atomicity
>
>
> Key: HBASE-2283
> URL: https://issues.apache.org/jira/browse/HBASE-2283
> Project: Hadoop HBase
> Issue Type: Bug
>Reporter: Kannan Muthukka
eems like all edits for a row (including any start/end
txn markers) should in fact happen in *one* call to WAL append; otherwise, you
can have interleaved edits in the log coming from multiple transactions. Agreed?
> row level atomicity
>
>
>
nded option.
Was the thought that if we went with "shutting down the server" option, we
could punt on Issue #2? My guess is the refactoring required for Issue #1 will
make it easy to fix #2 also as part of the changes.
> row level atomicity
>
>
>
emstore should happen after the sync rather than
>before.
A related question is : what should the region server do if a write/sync to the
Hlog fails? A simple option would be to shut itself down. Another option would
be to roll the logs?
> row le
[
https://issues.apache.org/jira/browse/HBASE-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-2283:
-
Fix Version/s: 0.21.0
0.20.4
Moving into 0.20.4.
> row level atomic
the WAL appending up
in the HRegionServer, add all edits for a row to WAL before proceeding per
column family to add edits per MemStore.
> row level atomicity
>
>
> Key: HBASE-2283
> URL: https://issues.apache.org/jir
he Put[] could be going to different Region Servers.
> So, is this important to preserve with a single Region Server?
>
> regards,
> Kannan
> -Original Message-
> From: jdcry...@gmail.com [mailto:jdcry...@gmail.com] On Behalf Of
> Jean-Daniel Cryans
> Sent: Wednesday,
complete transactions during recovery.
Ryan wrote: <<< But as you said, what happens if hlog append fails? The
obvious thing would be to remove the additions from the memstore. But how to
accomplish this easily?>>>
Wouldn't moving all the me
row level atomicity
Key: HBASE-2283
URL: https://issues.apache.org/jira/browse/HBASE-2283
Project: Hadoop HBase
Issue Type: Bug
Reporter: Kannan Muthukkaruppan
Priority: Blocker
The flow
che.org
Subject: Re: row level atomicity
> (i) It looks like make several calls to this.write.append()
> which in turn does a bunch of individual out.write (to the DFSOutputStream),
> as opposed to just one interaction with the underlying DFS. If so, how do we
> guar
On Wed, Mar 3, 2010 at 2:11 PM, Jean-Daniel Cryans wrote:
>> (i) It looks like make several calls to this.write.append()
>> which in turn does a bunch of individual out.write (to the DFSOutputStream),
>> as opposed to just one interaction with the underlying DFS. If so, how do w
> (i) It looks like make several calls to this.write.append()
> which in turn does a bunch of individual out.write (to the DFSOutputStream),
> as opposed to just one interaction with the underlying DFS. If so, how do we
> guarantee that all the edits either make it to HDFS or no
The flow during a HRegionServer.put() seems to be the following. [For now,
let's just consider single row Put containing edits to multiple column
families/columns.]
HRegionServer.put() does a:
1) HRegion.put()
2) syncWal() (the HDFS sync call).
HRegion.put() does a:
For each colu
16 matches
Mail list logo
