Matt,
You can add replace/insert the key extents in which the hole exists. The
check simply looks at the prev end row key ( ~pr ) and ensure it matches
the actual last end row. You can insert the keys for that extent. I would
back up the table just in case. I thought there was a utility to fill i
more info
if needed if someone else does not fill in my holey phone responses.
On Mon, Feb 27, 2017 at 8:47 PM, Marc P. wrote:
> Matt,
> You can add replace/insert the key extents in which the hole exists. The
> check simply looks at the prev end row key ( ~pr ) and ensure it matche
Mike,
That's a good point. My thoughts on this are that we lack the utilities
to help since of the five largish instances I've seen recently have
required their maintainers to edit the metadata table manually. The
CheckForMetadataProblems could prompt the user with ways to fix certain
issues alon
Max,
Additionally, what are your max open files? If you are under heavy ingest
you may exceed this with compactions if they cannot keep up. Additionally,
how many files per compaction are you allowing?
On Thu, Mar 23, 2017 at 10:27 AM, Michael Wall wrote:
> Max,
>
> On you 3 node cluster, how
Adam,
Take a look at this archive [1], which discusses the gc.trash.ignore
flag.
[1]
http://apache-accumulo.1065345.n5.nabble.com/Accumulo-GC-and-Hadoop-trash-settings-td14895.html
On Wed, Aug 9, 2017 at 11:14 AM, Adam J. Shook wrote:
> Hello all,
>
> Has there ever been discussion of havin
Hi Chris S,
Thank you for that context. Based on my experience with gRPC my response
would change.
I can only speak for myself, but I don't believe the removal of Kerberos
would be a blocker since acceptable alternatives exist within the
ecosystem.
Thanks,
Marc
On Fri, Aug 23, 2024 at 3:38 PM
It may also serve you to extend the appropriate aggregator, thereby
setting your source iter to the batch scanner's iterator. You can then
iteratate over the aggregated result set ( if possible ).
I haven't actually tried this, but you would be limited by memory at
the client ( depending on the si
I should point out, I mean that depending on what your iterators do (
and more importantly, what they store ), you may be limited by memory.
It's dependent upon multiple factors, obviously.
---
Sent from my phone, may contain spelling wrrors
On Mon, Jun 11, 2012 at 4:52 PM, Marc P. wrote:
I'm sorry, I must be missing something.
Why does the schema matter? If you were to build keys from all
attributes and elements, you could, at any point, rebuild the XML
document. You could store the heirarchy, by virtue of your keys.
If you were to do that, the previous suggestions would be appli
Why are you using that accepts the thrift key and range? They're
internal communication objects within accumulo. I haven't looked the
code directly, but they're likely contracted to be set in a different
manner.
On Tue, Jun 26, 2012 at 8:56 AM, David Medinets
wrote:
> I did this:
>
> TKey tKey =
I realized that Mr Slacum and I addressed the concern of using thrift;
however, perhaps you are doing something internally. Have you tried
setting the stop key on the TRange just for S&Gs?
On Tue, Jun 26, 2012 at 9:03 AM, Marc P. wrote:
> Why are you using that accepts the thrift key an
or works fine.
>>
>> Is there any reasons why default values of "" should not be provided
>> for cf, cq, and visibility?
>>
>> On Tue, Jun 26, 2012 at 9:09 AM, Marc P. wrote:
>> > I realized that Mr Slacum and I addressed the concern of using thrif
Yes, +1 Because that bit me before :(
On Sat, Jul 28, 2012 at 7:54 PM, John Vines wrote:
> I believe you will have to restart after removing it from lib and placing it
> in lib/ext though.
>
> John
>
> On Fri, Jul 27, 2012 at 1:25 PM, Marc Parisi wrote:
>>
>> Bob, the jars will be dynamically re
Thanks for catching that! I did indeed write that down incorrectly. I
apologize. I'll fix that tonight.
Iterators are stacked based on their priority ( when you set them via
the scanner, for example ) or the input format's IteratorSetting.
The init method comment is a general suggestion, for exam
14 matches
Mail list logo