[ 
https://issues.apache.org/jira/browse/CASSANDRA-15402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978911#comment-16978911
 ] 

maxwellguo commented on CASSANDRA-15402:
----------------------------------------

Thank you so much for you reply. 
{quote}
    I don't have time to do a full review of this, but I did scan through it.  
I don't see a single test, and there's close to zero comments.  I'm afraid 
anyone looking to review this thoroughly is going to have the same initial 
thoughts.  Given this patch affects a critical feature (backups), to me it's 
mandatory that any new code be thoroughly documented and functionality proven 
correct via tests.
{quote}
I forget to post the link of my ut test ,latter i will post one . But for my 
modification are through nodetool , latter I will try to add some ut for 
nodetool. Also the code comment is needed. 

{quote}
Lastly, I don't like the implementation details of this being a run time only 
setting without any sort of persistence across restarts.  The right way to do 
this is to make the setting per-table, and part of the schema.  Once we get 
into system schema modifications we start to drift further into more complexity 
(since now we also have to handle the upgrade path) and I again point to the 
trunk feature freeze to hold off on the work here.
{quote}
 In the beginning when I start the work, I have though to put the configuration 
to each table ,part of the schema. But at last i give up ,for the feature to 
turn on incremental backup just set from cassandra.yaml.
And if set this in system table such as system_schema for the table. when I 
turn on the feature through nodetool then it takes time for all the node to 
feel the change to turn on the backup, some times the time is unkonw. And I 
think this may add a burden to the system connunication for gossip if the 
feature is add to a non-replicate-system table . So i made an easy way just 
make a simple cache here to do backup filter. 
And I also want to make a change to yaml file that can set keyspace/table .The 
keyspace/table will not be backup. every time when node restart we can load 
this to the cache .  



> Make incremental backup configurable per keyspace and table
> -----------------------------------------------------------
>
>                 Key: CASSANDRA-15402
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15402
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Local/Other, Tool/nodetool
>            Reporter: maxwellguo
>            Assignee: maxwellguo
>            Priority: Normal
>              Labels: pull-request-available
>             Fix For: 4.x
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> We know that when we do backup for cassandra, we can do full bakcup with 
> snapshot, when we need to backup incremental data , incremental_backup can do 
> some help . 
> For snapshot we can just make snapshot for some keyspace/table. but 
> incremental backup will do all data backup(make hard link for all sstable 
> that flush from memtable or streaming ). we also know that commitlog's replay 
> can do some keyspace /table 's filter. 
> So  I think for incremental backup we also need some filter for it.After all 
> not all keyspace/table is so important to do backup.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to