On Sat, Oct 14, 2023 at 9:41 AM Vincent Russell
wrote:
>
> Christopher,
>
> I don't remember configuring anything with regards to commons-vfs. How do
> I disable this?
There's some VFS stuff enabled by default, for backwards
compatibility. There isn't an explicit way to disable it. It's being
Christopher,
I don't remember configuring anything with regards to commons-vfs. How do
I disable this?
After continuously hitting refresh on either monitor they just continuously
say the manager is down.
I"ll dig some more on Monday.
Thanks for the response.
-Vincent
On Fri, Oct 13, 2023 at
I am not sure what's up with the VFS error. I generally recommend
against using commons-vfs, because of the lack of any known good
versions, and the fact that most of what it is used for can be done
better in other ways. We have taken steps in recent versions to make
sure that the classloader
Christopher,
I have run through an upgrade with a bit more data than I did previously
and monitors with high availability just don't seem as consistent as they
were with 2.0.1.
After upgrading both accumulo monitors are reporting "Manager is Down" and
I was only able to achieve that after
I'm not sure about the monitor behavior. I've never had a reason to
run more than one, and I don't think we have any well-defined behavior
for trying to run more than one (I could see an argument for both). It
would be weird if one incorrectly reported "Master[now Manager] is
down" because another
Thank you Christopher,
I did neglect to update the log4j2 files.
One thing that is weird is that the monitors appear to work differently
with high availability.
With 2.0.1 the accumulo monitors both work and you can hit them both (one
just says 'Master is down'; however, with 2.1.1, it appears
I do not know about the error message you saw. StatusConsoleListener
is not an Accumulo class, but it looks like it's a log4j one. My best
guess is that during your upgrade, you did not migrate your log4j
config files over to be based on the log4j2 ones we have as an example
in the 2.1 tarball.
Thank you Christopher,
Don't worry. I definitely planned on testing an upgrade on a test
cluster. :)
I just upgraded a test cluster and everything appeared to go smoothly
except for one thing.
I am able to login to the accumulo shell and I can see the table that I
created before the upgrade
My understanding is that the upgrade of ZK is pretty easy... but I
would consult the ZooKeeper community for advice on that, since they
are the experts. For Accumulo's part, I believe 2.0 worked fine with
newer versions of ZK (3.5+), so you should be able to update ZK first
if you didn't want to
Thank you Christopher.
Does there exist some documentation for upgrading zookeeper from 3.4.14 to
3.8.1? Is there a preferred upgrade path?
Also...Is there any documentation on how this affects hadoop when using
high availability? We are using hadoop 3.3.1. I want to upgrade to
hadoop
The correct link seems to be
https://accumulo.apache.org/docs/2.x/troubleshooting/zookeeper#zookeeper-acls
It looks like both `bin/accumulo dump-zoo` and `bin/accumulo-util
dump-zoo` will do the same thing. It was originally a disconnected
utility that existed for convenience, but was
Also the link to:
https://accumulo.apache.org/docs/2.x/troubleshooting/ZooKeeper#ACLs
is not resolving.
What needs to be done at this step?
Thanks,
Vincent
On Thu, Aug 24, 2023 at 10:36 AM Vincent Russell
wrote:
> Hello,
>
> I'm practicing going to the upgrade instructions from 2.0.1 to
12 matches
Mail list logo
