phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-5034) Log all critical statements in SYSTEM.LOG table.
Date Wed, 05 Dec 2018 04:48:00 GMT


ASF GitHub Bot commented on PHOENIX-5034:

Github user karanmehta93 commented on a diff in the pull request:
    --- Diff: phoenix-core/src/it/java/org/apache/phoenix/end2end/ ---
    @@ -250,7 +250,103 @@ public void testWithLoggingOFF() throws Exception{
    +    @Test
    +    //DROP Table statement should be always logged.
    +    public void testDropTableStatement() throws Exception{
    --- End diff --
    Also can you test a scenario with multiple drop/alter statements issued together. What
happens if the RingBuffer is full and we are trying to add to it, does it block and wait OR
it drops it (in that case this is not complete)?

> Log all critical statements in SYSTEM.LOG table.
> ------------------------------------------------
>                 Key: PHOENIX-5034
>                 URL:
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Xu Cang
>            Assignee: Xu Cang
>            Priority: Minor
>         Attachments: PHOENIX-5034-4.x-HBase-1.3.001.patch, PHOENIX-5034-4.x-HBase-1.3.002.patch,
PHOENIX-5034-4.x-HBase-1.3.003.patch, PHOENIX-5034-4.x-HBase-1.3.004.patch, PHOENIX-5034-4.x-HBase-1.3.005.patch
> In production, sometimes engineers see table got dropped unexpectedly. It's not easy
to SCAN raw table from HBase itself to understand what happened and when the table get dropped.
> Since we already have SYSTEM.LOG query log facility in Phoenix that sampling query statement
(log 1% statement by default). It's good to always log critical statements such as "DROP"
or "ALTER" statements.

This message was sent by Atlassian JIRA

View raw message