[jira] [Updated] (CASSANDRA-9191) Log and count failure to obtain requested consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-9191: - Status: Awaiting Feedback (was: Open) > Log and count failure to obtain requested consistency > - > > Key: CASSANDRA-9191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9191 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination, Legacy/Observability >Reporter: Matt Stump >Priority: Minor > Labels: lhf > Attachments: patch_CASSANDRA-9191_trunk, patch_CASSANDRA-9191_v3.11.3 > > > Cassandra should have a way to log failed requests due to failure to obtain > requested consistency. This should be logged as error or warning by default. > Also exposed should be a counter for the benefit of opscenter. > Currently the only way to log this is at the client. Often the application > and DB teams are separate and it's very difficult to obtain client logs. Also > because it's only visible to the client no visibility is given to opscenter > making it difficult for the field to track down or isolate systematic or node > level errors. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9191) Log and count failure to obtain requested consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16786386#comment-16786386 ] Shaurya Gupta commented on CASSANDRA-9191: -- Hi, I have uploaded patches for trunk and 3.11.3 branches (will change to 3.11.x if required). Please have a look. I'm a bit new to Cassandra code base, please bear with me if I made some rookie mistake. Thanks [~mstump], [~slebresne] > Log and count failure to obtain requested consistency > - > > Key: CASSANDRA-9191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9191 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination, Legacy/Observability >Reporter: Matt Stump >Priority: Minor > Labels: lhf > Attachments: patch_CASSANDRA-9191_trunk, patch_CASSANDRA-9191_v3.11.3 > > > Cassandra should have a way to log failed requests due to failure to obtain > requested consistency. This should be logged as error or warning by default. > Also exposed should be a counter for the benefit of opscenter. > Currently the only way to log this is at the client. Often the application > and DB teams are separate and it's very difficult to obtain client logs. Also > because it's only visible to the client no visibility is given to opscenter > making it difficult for the field to track down or isolate systematic or node > level errors. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-9191) Log and count failure to obtain requested consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-9191: - Attachment: patch_CASSANDRA-9191_v3.11.3 patch_CASSANDRA-9191_trunk > Log and count failure to obtain requested consistency > - > > Key: CASSANDRA-9191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9191 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination, Legacy/Observability >Reporter: Matt Stump >Priority: Minor > Labels: lhf > Attachments: patch_CASSANDRA-9191_trunk, patch_CASSANDRA-9191_v3.11.3 > > > Cassandra should have a way to log failed requests due to failure to obtain > requested consistency. This should be logged as error or warning by default. > Also exposed should be a counter for the benefit of opscenter. > Currently the only way to log this is at the client. Often the application > and DB teams are separate and it's very difficult to obtain client logs. Also > because it's only visible to the client no visibility is given to opscenter > making it difficult for the field to track down or isolate systematic or node > level errors. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10273) Reduce number of data directory scans during startup
[
https://issues.apache.org/jira/browse/CASSANDRA-10273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shaurya Gupta updated CASSANDRA-10273:
--
Status: Awaiting Feedback (was: Open)
> Reduce number of data directory scans during startup
>
>
> Key: CASSANDRA-10273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10273
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Robert Stupp
>Assignee: Giampaolo
>Priority: Minor
> Labels: lhf
> Attachments: patch_CASSANDRA-10273_trunk
>
>
> ATM we scan each data directory four times. We could easily reduce that to at
> least two, maybe to one.
> # pre-flight (startup tests) scrub
> # pre-flight (startup tests) sstable min version
> # {{ColumnFamilyStore.createColumnFamilyStore}}
> # {{ColumnFamilyStore.}} (if {{loadSSTables==true}})
> First two pre-flight tests could be combined to one and 3+4 could also be
> combined, as both appear at pretty related code paths.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10273) Reduce number of data directory scans during startup
[
https://issues.apache.org/jira/browse/CASSANDRA-10273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16781546#comment-16781546
]
Shaurya Gupta commented on CASSANDRA-10273:
---
Hi,
Could you please assign this issue to me, since the current assignee may not be
interested in this issue as there has not been any activity on this issue from
a long time.
I have uploaded a patch for merging 3rd and 4th scans. Please have a look.
Since I am just starting with Cassandra code base it could be very wrong.
Please point out the mistakes if any. As part of verification I verified by
starting Cassandra Daemon and then running a few commands.
For merging 1st and 2nd: It appears that 1st is about visiting each file in
data directory and ensuring correct version. 2nd is about visiting each
keyspace directory and then removing all the "un required" files.
scrubDataDirectories takes as input the cfm obtained from keyspace name.
Merging these two will entail that I figure out the keyspace from the data
directory path which looks a bit "dirty".
Merging these two will any way require that I do these operations for system
keyspace separately.
If the above method of merging 1st and 2nd scans looks fine, then I can go
ahead with it.
However, I think we can skip merging 1st and 2nd for the above reasons. Please
point out if I am missing something.
Thanks
[~snazy], [~jjirsa]
> Reduce number of data directory scans during startup
>
>
> Key: CASSANDRA-10273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10273
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Robert Stupp
>Assignee: Giampaolo
>Priority: Minor
> Labels: lhf
> Attachments: patch_CASSANDRA-10273_trunk
>
>
> ATM we scan each data directory four times. We could easily reduce that to at
> least two, maybe to one.
> # pre-flight (startup tests) scrub
> # pre-flight (startup tests) sstable min version
> # {{ColumnFamilyStore.createColumnFamilyStore}}
> # {{ColumnFamilyStore.}} (if {{loadSSTables==true}})
> First two pre-flight tests could be combined to one and 3+4 could also be
> combined, as both appear at pretty related code paths.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10273) Reduce number of data directory scans during startup
[
https://issues.apache.org/jira/browse/CASSANDRA-10273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shaurya Gupta updated CASSANDRA-10273:
--
Attachment: patch_CASSANDRA-10273_trunk
> Reduce number of data directory scans during startup
>
>
> Key: CASSANDRA-10273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10273
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Robert Stupp
>Assignee: Giampaolo
>Priority: Minor
> Labels: lhf
> Attachments: patch_CASSANDRA-10273_trunk
>
>
> ATM we scan each data directory four times. We could easily reduce that to at
> least two, maybe to one.
> # pre-flight (startup tests) scrub
> # pre-flight (startup tests) sstable min version
> # {{ColumnFamilyStore.createColumnFamilyStore}}
> # {{ColumnFamilyStore.}} (if {{loadSSTables==true}})
> First two pre-flight tests could be combined to one and 3+4 could also be
> combined, as both appear at pretty related code paths.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-11418: -- Status: Awaiting Feedback (was: Open) > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Priority: Minor > Labels: lhf > Fix For: 4.x > > Attachments: cassandra-11418-trunk > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-11418: -- Attachment: cassandra-11418-trunk > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Priority: Minor > Labels: lhf > Fix For: 4.x > > Attachments: cassandra-11418-trunk > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-11418: -- Attachment: cassandra-11418 > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Priority: Minor > Labels: lhf > Fix For: 4.x > > Attachments: cassandra-11418 > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16774984#comment-16774984 ] Shaurya Gupta commented on CASSANDRA-11418: --- Hi, I have uploaded a patch for this improvement. Since I am just starting with Cassandra code base it could be very wrong. Please point me to some related documentation in case it is conceptually wrong. Could you please assign this issue to me. Thanks [~jkni], [~KurtG] > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Priority: Minor > Labels: lhf > Fix For: 4.x > > Attachments: cassandra-11418 > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-11418: -- Attachment: (was: cassandra-11418) > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Priority: Minor > Labels: lhf > Fix For: 4.x > > Attachments: cassandra-11418-trunk > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771705#comment-16771705 ] Shaurya Gupta commented on CASSANDRA-9633: -- Hi [~jasobrown] Will this be included in 4.x release? Thanks > Add ability to encrypt sstables > --- > > Key: CASSANDRA-9633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9633 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core >Reporter: Jason Brown >Priority: Major > Labels: encryption, security, sstable > Fix For: 4.x > > > Add option to allow encrypting of sstables. > I have a version of this functionality built on cassandra 2.0 that > piggy-backs on the existing sstable compression functionality and ICompressor > interface (similar in nature to what DataStax Enterprise does). However, if > we're adding the feature to the main OSS product, I'm not sure if we want to > use the pluggable compression framework or if it's worth investigating a > different path. I think there's a lot of upside in reusing the sstable > compression scheme, but perhaps add a new component in cqlsh for table > encryption and a corresponding field in CFMD. > Encryption configuration in the yaml can use the same mechanism as > CASSANDRA-6018 (which is currently pending internal review). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14996) Incremental backups can fill up the disk if they are not being uploaded
[ https://issues.apache.org/jira/browse/CASSANDRA-14996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753678#comment-16753678 ] Shaurya Gupta edited comment on CASSANDRA-14996 at 1/28/19 3:50 AM: I have attached a patch which gives the basic idea of what I am suggesting. If you find it broadly fine then I can work further on this task. was (Author: shaurya1): I have attached a patch which gives the basic idea of what I am suggesting. If you find it broadly fine then I can work further on this issue. > Incremental backups can fill up the disk if they are not being uploaded > --- > > Key: CASSANDRA-14996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14996 > Project: Cassandra > Issue Type: Improvement >Reporter: Shaurya Gupta >Priority: Major > Attachments: patch_CASSANDRA-14996 > > > This creates a major problem if the script which uploads the snapshots is > triggered via some API and the application triggering it is somehow down and > is not able to hit the API. This affects Cassandra and slowly one or more > Cassandra nodes go down. > There could be a check in Cassandra that before creating a snapshot it checks > that the disk has some sufficient (configurable via cassandra.yaml and jmx) > disk space. > This could be achieved by making change in > public void maybeIncrementallyBackup(final Iterable sstables) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14996) Incremental backups can fill up the disk if they are not being uploaded
[ https://issues.apache.org/jira/browse/CASSANDRA-14996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753678#comment-16753678 ] Shaurya Gupta commented on CASSANDRA-14996: --- I have attached a patch which gives the basic idea of what I am suggesting. If you find it broadly fine then I can work further on this issue. > Incremental backups can fill up the disk if they are not being uploaded > --- > > Key: CASSANDRA-14996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14996 > Project: Cassandra > Issue Type: Improvement >Reporter: Shaurya Gupta >Priority: Major > Attachments: patch_CASSANDRA-14996 > > > This creates a major problem if the script which uploads the snapshots is > triggered via some API and the application triggering it is somehow down and > is not able to hit the API. This affects Cassandra and slowly one or more > Cassandra nodes go down. > There could be a check in Cassandra that before creating a snapshot it checks > that the disk has some sufficient (configurable via cassandra.yaml and jmx) > disk space. > This could be achieved by making change in > public void maybeIncrementallyBackup(final Iterable sstables) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14996) Incremental backups can fill up the disk if they are not being uploaded
[ https://issues.apache.org/jira/browse/CASSANDRA-14996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-14996: -- Attachment: patch_CASSANDRA-14996 > Incremental backups can fill up the disk if they are not being uploaded > --- > > Key: CASSANDRA-14996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14996 > Project: Cassandra > Issue Type: Improvement >Reporter: Shaurya Gupta >Priority: Major > Attachments: patch_CASSANDRA-14996 > > > This creates a major problem if the script which uploads the snapshots is > triggered via some API and the application triggering it is somehow down and > is not able to hit the API. This affects Cassandra and slowly one or more > Cassandra nodes go down. > There could be a check in Cassandra that before creating a snapshot it checks > that the disk has some sufficient (configurable via cassandra.yaml and jmx) > disk space. > This could be achieved by making change in > public void maybeIncrementallyBackup(final Iterable sstables) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14996) Incremental backups can fill up the disk if they are not being uploaded
[ https://issues.apache.org/jira/browse/CASSANDRA-14996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-14996: -- Description: This creates a major problem if the script which uploads the snapshots is triggered via some API and the application triggering it is somehow down and is not able to hit the API. This affects Cassandra and slowly one or more Cassandra nodes go down. There could be a check in Cassandra that before creating a snapshot it checks that the disk has some sufficient (configurable via cassandra.yaml and jmx) disk space. This could be achieved by making change in public void maybeIncrementallyBackup(final Iterable sstables) was: This creates a major problem if the script which uploads the snapshots is triggered via some API and the application triggering it is somehow down and is not able to hit the API. This affects Cassandra and slowly one or more Cassandra nodes go down. There could be a check in Cassandra that before creating a snapshot it checks that the disk has some sufficient (configurable via cassandra.yaml and jmx) disk space. This could be achieved by making change in public void maybeIncrementallyBackup(final Iterable sstables) > Incremental backups can fill up the disk if they are not being uploaded > --- > > Key: CASSANDRA-14996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14996 > Project: Cassandra > Issue Type: Improvement >Reporter: Shaurya Gupta >Priority: Major > > This creates a major problem if the script which uploads the snapshots is > triggered via some API and the application triggering it is somehow down and > is not able to hit the API. This affects Cassandra and slowly one or more > Cassandra nodes go down. > There could be a check in Cassandra that before creating a snapshot it checks > that the disk has some sufficient (configurable via cassandra.yaml and jmx) > disk space. > This could be achieved by making change in > public void maybeIncrementallyBackup(final Iterable sstables) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14996) Incremental backups can fill up the disk if they are not being uploaded
[ https://issues.apache.org/jira/browse/CASSANDRA-14996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-14996: -- Description: This creates a major problem if the script which uploads the snapshots is triggered via some API and the application triggering it is somehow down and is not able to hit the API. This affects Cassandra and slowly one or more Cassandra nodes go down. There could be a check in Cassandra that before creating a snapshot it checks that the disk has some sufficient (configurable via cassandra.yaml and jmx) disk space. This could be achieved by making change in public void maybeIncrementallyBackup(final Iterable sstables) was: This creates a major problem if the script which uploads the snapshots is triggered via some API and the application triggering it is some how down and is not able to hit the API. There could be a check in Cassandra that before creating a snapshot it checks that the disk has some sufficient (configurable) disk space. > Incremental backups can fill up the disk if they are not being uploaded > --- > > Key: CASSANDRA-14996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14996 > Project: Cassandra > Issue Type: Improvement >Reporter: Shaurya Gupta >Priority: Major > > This creates a major problem if the script which uploads the snapshots is > triggered via some API and the application triggering it is somehow down and > is not able to hit the API. This affects Cassandra and slowly one or more > Cassandra nodes go down. > There could be a check in Cassandra that before creating a snapshot it checks > that the disk has some sufficient (configurable via cassandra.yaml and jmx) > disk space. > This could be achieved by making change in > public void maybeIncrementallyBackup(final Iterable sstables) > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14996) Incremental backups can fill up the disk if they are not being uploaded
[ https://issues.apache.org/jira/browse/CASSANDRA-14996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaurya Gupta updated CASSANDRA-14996: -- Status: Awaiting Feedback (was: Open) > Incremental backups can fill up the disk if they are not being uploaded > --- > > Key: CASSANDRA-14996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14996 > Project: Cassandra > Issue Type: Improvement >Reporter: Shaurya Gupta >Priority: Major > > This creates a major problem if the script which uploads the snapshots is > triggered via some API and the application triggering it is some how down and > is not able to hit the API. > There could be a check in Cassandra that before creating a snapshot it checks > that the disk has some sufficient (configurable) disk space. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14996) Incremental backups can fill up the disk if they are not being uploaded
Shaurya Gupta created CASSANDRA-14996: - Summary: Incremental backups can fill up the disk if they are not being uploaded Key: CASSANDRA-14996 URL: https://issues.apache.org/jira/browse/CASSANDRA-14996 Project: Cassandra Issue Type: Improvement Reporter: Shaurya Gupta This creates a major problem if the script which uploads the snapshots is triggered via some API and the application triggering it is some how down and is not able to hit the API. There could be a check in Cassandra that before creating a snapshot it checks that the disk has some sufficient (configurable) disk space. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14682) AXAAS-12296 changes the message for RF=1 only, it should display correct message for other RF values also
Shaurya Gupta created CASSANDRA-14682: - Summary: AXAAS-12296 changes the message for RF=1 only, it should display correct message for other RF values also Key: CASSANDRA-14682 URL: https://issues.apache.org/jira/browse/CASSANDRA-14682 Project: Cassandra Issue Type: Bug Reporter: Shaurya Gupta CASSANDRA-12296 changes the message for RF=1 only, it should display correct message for other RF values also. Encountered the message: Exception: Unable to find sufficient sources for streaming range (8586721931686955021,8587189655497704775] in keyspace testlcl_v12val2b when I tried to rebuild a keyspace from a DC which didn't have the replicas. It should display a more explanatory message as displayed as part of CASSANDRA-12296. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
