ctubbsii commented on issue #3097: URL: https://github.com/apache/accumulo/issues/3097#issuecomment-1333333610
> Would this be more appropriate as a manual - post install step? @EdColeman Short answer: No. Users wouldn't be able to delete the replication table, because they can't delete stuff in the builtin accumulo namespace. Unless we bake in special exceptions for replication, which contrasts with the goal of removing it. Trying to relocate the table to user space is one option, but it is fraught with issues, starting with potential name collisions, the fact that the table ID doesn't match the same base-36 number format as other user tables, and also that you don't know which configuration that might be set on the built-in namespace that needs to be copied over to the new table or namespace on relocation. But also, the information in this table is very heavily contextualized to the current state of Accumulo and its write ahead logs and garbage collection, which have already been stripped of any relevant code that would be affected by this metadata. So any information in this table isn't going to be up-to-date with the state of Accumulo's WALs anyway... not to mention that there's little to no documentation about the structure of this table that an administrator could use to make sense of its contents. > If someone was using replication - they would need to ensure that the replication queue was fully drained before performing the upgrade. We could abort the upgrade if we can determine that a) replication is active and b) data remains that has not been replicated - this would be similar to they way that we refuse to upgrade if any FATE transactions exist because we do not handle FATE conversions. It would be enough to just check that the replication table is marked offline in ZK before proceeding. If it's marked as online in ZK, then we could abort. I don't think it's worth doing anything beyond that to investigate the state of replication during the upgrade process. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
