-
Notifications
You must be signed in to change notification settings - Fork 445
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cloning metadata table does not work and can be dangerous #1309
Comments
Below are some possible ways to fix this..
|
I think it should be simple enough for the GC to check for candidates in use by all sources. Would that be sufficient? |
Conceptually it seems simple and I can not think of any gotchas at the moment. I don't think the code change would be simple. |
Would not want to do this for 1.9. I am leaning twoards throwing an error in 1.9 if an attempt to clone the metadata table is made. |
👍 This is the current behavior in 1.9 for the root table. |
Wow, this is a good catch. Should we send out a warning on user and dev? |
Yes, that's a good idea. |
The following is a much simpler situation that could lead to deleting metadata table files.
The compaction of the clone causes |
If you have cloned the metadata table in the past I would recommend compacting the metadata table. This will cause it to have a new set of files different from the clone.
After the compaction above the files referenced in |
After the changes in #1309 cloning of metdata table is no longer allowed. TabletStateChangeIteratorIT relied on cloning and was changed to copy instead. Also the test was very sensitive to concurrent chnages in the metadata table. Suspect that cloning used to introduce a delay that hid this. The change from cloning to copying caused the test to fail often because of these timing issues. To avoid this, the test was refactored to tolerate concurrent changes to the metadata table.
Accumulo supports cloning the metadata table. This will create a user table that points to the the metadata table files. When the Accumulo GC processes the root table, it does not look for file references in the metadata table. Therefore the files of the metadata table clone will eventually be deleted by the Accumulo GC, making the clone unusable.
When a clone of the metadata table is deleted, it will normally have no effect on the metadata files it references. However this is not always true. Its very hard to create, but there is a reverse situation where cloning the metadata table could cause metadata files to be deleted. The following Accumulo shell commands illustrate one way this could happen.
Below shows the output of scanning the metadata table after running the commands above. The
~del
entries for/accumulo/tables/!0/default_tablet/A000008z.rf
and/accumulo/tables/!0/table_info/A0000094.rf
are quite worrisome. These two files are whereaccumulo.metadata
is currently storing its data and sinceaccumulo.metadata
does not reference them they will be deleted.Below is scan of the root tablet showing that
accumulo.metadata
is using the two files that have been scheduled for deletion.The files were eventually deleted by Accumulo GC leaving Accumulo in a very bad state.
I noticed this behavior while working on #936
The text was updated successfully, but these errors were encountered: