phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoffrey Jacoby (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-4229) Parent-Child linking rows in System.Catalog break tenant view replication
Date Thu, 05 Oct 2017 20:32:00 GMT


Geoffrey Jacoby commented on PHOENIX-4229:

Thanks, [~jamestaylor], that's really helpful. 

I'm not trying to create new cells in the SystemCatalogWALEntryFilter and add them to the
WALEdit to be replicated -- that seems risky since those synthetic cells wouldn't exist in
any WAL. 

HBase replication is giving me a collection of all Cells written to System.Catalog on cluster
A. For each Cell, I need to make an independent judgement about whether it's a part of a tenant
view's metadata or not. If it is, it gets replicated to cluster B. The rest don't.

Every row in the original tenant view definition has the tenant_id in the first column of
the PK, so I can evaluate each Cell individually and make that call. What makes the parent
- child link trickier is that here, the criteria is based on a column qualifier, not the row
key, and there are *two* Cells that need to be replicated (LINK_TYPE and PARENT_TENANT_ID,
according to the MetadataClient upsert you mention). 

Do all parent/child view links have the same LINK_TYPE that is used only for parent/child
view links?

> Parent-Child linking rows in System.Catalog break tenant view replication
> -------------------------------------------------------------------------
>                 Key: PHOENIX-4229
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.11.0, 4.12.0
>            Reporter: Geoffrey Jacoby
>            Assignee: Geoffrey Jacoby
> PHOENIX-2051 introduced new Parent-Child linking rows to System.Catalog that speed up
view deletion. Unfortunately, this breaks assumptions in PHOENIX-3639, which gives a way to
replicate tenant views from one cluster to another. (It assumes that all the metadata for
a tenant view is owned by the tenant -- the linking rows are not.) 
> PHOENIX-3639 was a workaround in the first place to the more fundamental design problem
that Phoenix places the metadata for both table schemas -- which should never be replicated
-- in the same table and column family as the metadata for tenant views, which should be replicated.

> Note that the linking rows also make it more difficult to ever split these two datasets
apart, as proposed in PHOENIX-3520.

This message was sent by Atlassian JIRA

View raw message