WALPlayer will look at the timestamp. Replaying an older edit that has since been overwritten shouldn't change anything.
On Sat, Jun 30, 2012 at 9:49 AM, Bryan Beaudreault <bbeaudrea...@hubspot.com > wrote: > They are all pretty large, around 40+mb. Will the walplayer be smart > enough to only write edits that still look relevant (i.e. based on > timestamps of the edits vs timestamps of the versions in hbase)? Writes > have been coming in since we recovered. > > On Sat, Jun 30, 2012 at 11:05 AM, Stack <st...@duboce.net> wrote: > > > On Sat, Jun 30, 2012 at 8:38 AM, Bryan Beaudreault > > <bbeaudrea...@hubspot.com> wrote: > > > 12/06/30 00:00:48 INFO wal.HLogSplitter: Got while parsing hlog > > > > > > hdfs://my-namenode-ip-addr:8020/hbase/.logs/my-rs-ip-addr,60020,1338667719591/my-rs-ip-addr%3A60020.1340935453874. > > > Marking as corrupted > > > > > > > What size do these logs have? > > > > > We are back to stable operating now, and in trying to research this I > > found > > > the hdfs://my-namenode-ip-addr:8020/hbase/.corrupt directory. There > are > > 20 > > > files listed there. > > > > > > > Ditto. > > > > > What are our options for tracking down and potentially recovering any > > data > > > that was lost. Or how can we even tell what was lost, if any? Does > the > > > existence of these files pretty much guarantee data lost? There doesn't > > > seem to be much documentation on this. From reading it seems like it > > might > > > be possible that part of each of these files was recovered. > > > > > > > If size > 0, could try walplaying them: > > http://hbase.apache.org/book.html#walplayer > > > > St.Ack > > >
