[jira] [Commented] (CASSANDRA-14622) Run compaction on cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-14622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569863#comment-16569863
]
Wasil Shaikh commented on CASSANDRA-14622:
--
You mean, i should draft the concerns & mail it.
> Run compaction on cluster
> --
>
> Key: CASSANDRA-14622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14622
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: CentOS Linux release 7.1.1503 (Core)
>Reporter: Wasil Shaikh
>Priority: Major
> Labels: Cassandra
>
> Dear Team,
> I have setup a cassandra cluster for 3 m/c.
> [root@ip-172-31-21-222 ~]# nodetool status
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID Rack
> UN 172.31.21.223 4.01 TB 256 ? 9d2a408a-264f-423f-8af2-e1d4cb608998 rack1
> UN 172.31.21.222 4.5 TB 256 ? c3d24437-3e03-41d7-a2af-2ed53bcf2dfc rack1
> UN 172.31.21.221 4.26 TB 256 ? aaf4fbaf-837b-44e2-98ba-5eb2b3e6b62b rack1
> Note: Non-system keyspaces don't have the same replication settings,
> effective ownership information is meaningless
> [root@ip-172-31-21-222 ~]#
>
> Now i have deleted around 40-45 GB data but space seems is not vacant.
> I'm using SizeTieredCompactionStrategy and below is my table defination.
>
> CREATE TABLE test.att_103 (
> md5 text PRIMARY KEY,
> arcsize int,
> att_str blob,
> attsize int,
> udate timestamp
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = '\{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = \{'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
> AND compression = \{'sstable_compression':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> I have dumped data using sstable2json command to verify whether my column
> data is deleted or not.
> e.g
> {"key": "9b7937de43aa22fc3bf18ec72d86140b",
> "cells": [["att_str",1533305633,1533305633552000,"d"],
> ["udate","2018-08-03 14:13Z",1533305633552000]]}
>
> Now can you help me here regarding how to run compaction manually instead of
> waiting for 10 days of grace period.
>
> Thanks
> Wasil.
>
--
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-14622) Run compaction on cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-14622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wasil Shaikh updated CASSANDRA-14622:
-
Labels: Cassandra (was: )
> Run compaction on cluster
> --
>
> Key: CASSANDRA-14622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14622
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: CentOS Linux release 7.1.1503 (Core)
>Reporter: Wasil Shaikh
>Priority: Major
> Labels: Cassandra
> Fix For: 2.2.1
>
>
> Dear Team,
> I have setup a cassandra cluster for 3 m/c.
> [root@ip-172-31-21-222 ~]# nodetool status
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID Rack
> UN 172.31.21.223 4.01 TB 256 ? 9d2a408a-264f-423f-8af2-e1d4cb608998 rack1
> UN 172.31.21.222 4.5 TB 256 ? c3d24437-3e03-41d7-a2af-2ed53bcf2dfc rack1
> UN 172.31.21.221 4.26 TB 256 ? aaf4fbaf-837b-44e2-98ba-5eb2b3e6b62b rack1
> Note: Non-system keyspaces don't have the same replication settings,
> effective ownership information is meaningless
> [root@ip-172-31-21-222 ~]#
>
> Now i have deleted around 40-45 GB data but space seems is not vacant.
> I'm using SizeTieredCompactionStrategy and below is my table defination.
>
> CREATE TABLE test.att_103 (
> md5 text PRIMARY KEY,
> arcsize int,
> att_str blob,
> attsize int,
> udate timestamp
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = '\{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = \{'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
> AND compression = \{'sstable_compression':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> I have dumped data using sstable2json command to verify whether my column
> data is deleted or not.
> e.g
> {"key": "9b7937de43aa22fc3bf18ec72d86140b",
> "cells": [["att_str",1533305633,1533305633552000,"d"],
> ["udate","2018-08-03 14:13Z",1533305633552000]]}
>
> Now can you help me here regarding how to run compaction manually instead of
> waiting for 10 days of grace period.
>
> Thanks
> Wasil.
>
--
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-14622) Run compaction on cluster
Wasil Shaikh created CASSANDRA-14622:
Summary: Run compaction on cluster
Key: CASSANDRA-14622
URL: https://issues.apache.org/jira/browse/CASSANDRA-14622
Project: Cassandra
Issue Type: Bug
Components: CQL
Environment: CentOS Linux release 7.1.1503 (Core)
Reporter: Wasil Shaikh
Fix For: 2.2.1
Dear Team,
I have setup a cassandra cluster for 3 m/c.
[root@ip-172-31-21-222 ~]# nodetool status
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 172.31.21.223 4.01 TB 256 ? 9d2a408a-264f-423f-8af2-e1d4cb608998 rack1
UN 172.31.21.222 4.5 TB 256 ? c3d24437-3e03-41d7-a2af-2ed53bcf2dfc rack1
UN 172.31.21.221 4.26 TB 256 ? aaf4fbaf-837b-44e2-98ba-5eb2b3e6b62b rack1
Note: Non-system keyspaces don't have the same replication settings, effective
ownership information is meaningless
[root@ip-172-31-21-222 ~]#
Now i have deleted around 40-45 GB data but space seems is not vacant.
I'm using SizeTieredCompactionStrategy and below is my table defination.
CREATE TABLE test.att_103 (
md5 text PRIMARY KEY,
arcsize int,
att_str blob,
attsize int,
udate timestamp
) WITH bloom_filter_fp_chance = 0.01
AND caching = '\{"keys":"ALL", "rows_per_partition":"NONE"}'
AND comment = ''
AND compaction = \{'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
AND compression = \{'sstable_compression':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
I have dumped data using sstable2json command to verify whether my column data
is deleted or not.
e.g
{"key": "9b7937de43aa22fc3bf18ec72d86140b",
"cells": [["att_str",1533305633,1533305633552000,"d"],
["udate","2018-08-03 14:13Z",1533305633552000]]}
Now can you help me here regarding how to run compaction manually instead of
waiting for 10 days of grace period.
Thanks
Wasil.
--
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
