[jira] [Comment Edited] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652521#comment-17652521
]
Paulo Motta edited comment on CASSANDRA-16418 at 12/28/22 3:22 PM:
---
Nice work [~linzuro]! The approach and test looks mostly good to me, added a
few comments to the PR.
Can you add a similar regression test for bootstrap so we can detect if this is
ever broken in the future? The test should fail when the bootstrap safeguard is
removed. I think you can find some bootstrap dtest examples on
{{{}org.apache.cassandra.distributed.test.ring.BootstrapTest{}}}.
I have submitted a preliminary CI run for your branch on:
* [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2151/]
was (Author: paulo):
Nice work [~linzuro]! The approach and test looks mostly good to me, added a
few comments to the PR.
Can you add a similar regression test for bootstrap? The test should fail when
the bootstrap safeguard is removed. I think you can find some bootstrap dtest
examples on \{{org.apache.cassandra.distributed.test.ring.BootstrapTest}}.
I have submitted a preliminary CI run for your branch on:
* https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2151/
> Unsafe to run nodetool cleanup during bootstrap or decommission
> ---
>
> Key: CASSANDRA-16418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16418
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: James Baker
>Assignee: Lindsey Zurovchak
>Priority: Normal
> Time Spent: 20m
> Remaining Estimate: 0h
>
> What we expected: Running a cleanup is a safe operation; the result of
> running a query after a cleanup should be the same as the result of running a
> query before a cleanup.
> What actually happened: We ran a cleanup during a decommission. All the
> streamed data was silently deleted, the bootstrap did not fail, the cluster's
> data after the decommission was very different to the state before.
> Why: Cleanups do not take into account pending ranges and so the cleanup
> thought that all the data that had just been streamed was redundant and so
> deleted it. We think that this is symmetric with bootstraps, though have not
> verified.
> Not sure if this is technically a bug but it was very surprising (and
> seemingly undocumented) behaviour.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Mentor: Paulo Motta Status: Changes Suggested (was: Review In Progress) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Reviewers: Paulo Motta, Paulo Motta (was: Paulo Motta) Paulo Motta, Paulo Motta (was: Paulo Motta) Status: Review In Progress (was: Patch Available) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652521#comment-17652521
]
Paulo Motta commented on CASSANDRA-16418:
-
Nice work [~linzuro]! The approach and test looks mostly good to me, added a
few comments to the PR.
Can you add a similar regression test for bootstrap? The test should fail when
the bootstrap safeguard is removed. I think you can find some bootstrap dtest
examples on \{{org.apache.cassandra.distributed.test.ring.BootstrapTest}}.
I have submitted a preliminary CI run for your branch on:
* https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2151/
> Unsafe to run nodetool cleanup during bootstrap or decommission
> ---
>
> Key: CASSANDRA-16418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16418
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: James Baker
>Assignee: Lindsey Zurovchak
>Priority: Normal
> Time Spent: 20m
> Remaining Estimate: 0h
>
> What we expected: Running a cleanup is a safe operation; the result of
> running a query after a cleanup should be the same as the result of running a
> query before a cleanup.
> What actually happened: We ran a cleanup during a decommission. All the
> streamed data was silently deleted, the bootstrap did not fail, the cluster's
> data after the decommission was very different to the state before.
> Why: Cleanups do not take into account pending ranges and so the cleanup
> thought that all the data that had just been streamed was redundant and so
> deleted it. We think that this is symmetric with bootstraps, though have not
> verified.
> Not sure if this is technically a bug but it was very surprising (and
> seemingly undocumented) behaviour.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17650837#comment-17650837 ] maxwellguo edited comment on CASSANDRA-18061 at 12/28/22 8:07 AM: -- [~smiklosovic]Thanks very much. Sorry for offline these days , I think what I did was inappropriate ,next time I should contact you after modifying the code and passing the test,not immediately after the modification. I have already fix the exception what occurs at java-jvm-dtest. My ci test is ok at this test case in upgrade tests for java8 preommit :https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/355/workflows/5e9a984a-3dd1-43a3-8347-832918a0f1c1 commit pr: https://github.com/apache/cassandra/pull/2047/commits was (Author: maxwellguo): [~smiklosovic]Thanks very much. Sorry for offline these days , I think what I did was inappropriate ,next time I should contact you after modifying the code and passing the test,not immediately after the modification. I have already fix the exception what occurs at java-jvm-dtest. My ci test is ok at this test case in upgrade tests for java8 preommit :https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/355/workflows/5e9a984a-3dd1-43a3-8347-832918a0f1c1 > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
