[
https://issues.apache.org/jira/browse/PHOENIX-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15517364#comment-15517364
]
Samarth Jain commented on PHOENIX-3326:
---------------------------------------
I am looking at the comments on the snapshot API and this is what it says:
{code}
/**
* Take a snapshot and wait for the server to complete that snapshot
(blocking).
* <p>
* Only a single snapshot should be taken at a time for an instance of HBase,
or results may be
* undefined (you can tell multiple HBase clusters to snapshot at the same
time, but only one at a
* time for a single cluster).
* <p>
* Snapshots are considered unique based on <b>the name of the snapshot</b>.
Attempts to take a
* snapshot with the same name (even a different type or with different
parameters) will fail with
* a {@link SnapshotCreationException} indicating the duplicate naming.
* <p>
* Snapshot names follow the same naming constraints as tables in HBase. See
* {@link
org.apache.hadoop.hbase.TableName#isLegalFullyQualifiedTableName(byte[])}.
* <p>
{code}
Looks like creating snapshots concurrently isn't advised.
> Restoring SYSTEM.CATALOG from snapshot causes clients to run into
> UpgradeInProgressException
> --------------------------------------------------------------------------------------------
>
> Key: PHOENIX-3326
> URL: https://issues.apache.org/jira/browse/PHOENIX-3326
> Project: Phoenix
> Issue Type: Bug
> Reporter: Samarth Jain
> Assignee: Samarth Jain
>
> We create a snapshot of the SYSTEM.CATALOG table only after the client is
> able to successfully acquire a distributed mutex of sorts. This means the
> snapshot also ends up containing the row that serves as the mutex. Now when
> restoring the table from snapshot, this rows is still present which causes
> clients to throw UpgradeInProgress exception.
> I can think of a couple of ways to fix this:
> 1) Do the checkAndPut for the UPGRADE_MUTEX after creating the snapshot. I am
> not too sure though how about HBase handles concurrent snapshot requests. Do
> clients get an exception? Also we potentially could end up creating more
> snapshots than we really need to.
> 2) Do the checkAndPut for the UPGRADE_MUTEX in a different table (possibly
> SYSTEM.SEQUENCE). This way the restored snapshot won't have the row. We would
> need to delete the row from SYSTEM.SEQUENCE after the upgrade is done
> (successfully or unsuccessfully).
> [~jamestaylor] - WDYT?
> FYI, [~lhofhansl] - this is probably a blocker for 4.8.1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
