phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3165) System table integrity check and repair tool
Date Mon, 12 Mar 2018 18:19:00 GMT


Andrew Purtell commented on PHOENIX-3165:

We have a need for something that finds orphan rows in syscat and removes them. It could
be an interesting occasion to start development of this tool. For the moment the orphan check
and repair could be the first and only function. More to be added later. 

I vote for calling this tool "phck"

It can be pronounced as "pee-haich-cee-kay" or ... some other way... per your personal preference. Maybe
a bit on the nose but amusing nonetheless.

> System table integrity check and repair tool
> --------------------------------------------
>                 Key: PHOENIX-3165
>                 URL:
>             Project: Phoenix
>          Issue Type: New Feature
>            Reporter: Andrew Purtell
>            Priority: Critical
> When the Phoenix system tables become corrupt recovery is a painstaking process of low
level examination of table contents and manipulation of same with the HBase shell. This is
very difficult work providing no margin of safety, and is a critical gap in terms of usability.
> At the OS level, we have fsck.
> At the HDFS level, we have fsck (integrity checking only, though)
> At the HBase level, we have hbck. 
> At the Phoenix level, we lack a system table repair tool. 
> Implement a tool that:
> - Does not depend on the Phoenix client.
> - Supports integrity checking of SYSTEM tables. Check for the existence of all required
columns in entries. Check that entries exist for all Phoenix managed tables (implies Phoenix
should add supporting advisory-only metadata to the HBase table schemas). Check that serializations
are valid. 
> - Supports complete repair of SYSTEM.CATALOG and recreation, if necessary, of other tables
like SYSTEM.STATS which can be dropped to recover from an emergency. We should be able to
drop SYSTEM.CATALOG (or any other SYSTEM table), run the tool, and have a completely correct
recreation of SYSTEM.CATALOG available at the end of its execution.
> - To the extent we have or introduce cross-system-table invariants, check them and offer
a repair or reconstruction option.

This message was sent by Atlassian JIRA

View raw message