Last stored value metadata table
Hi, Short story: storing time series of measurements (key(name, timestamp), value). The problem: get the list of the last `value` of every `name`. Is there a Cassandra friendly solution to store the last value of every `name` in a separate metadata table? It will come with a lot of tombstones... any other solution? :) -- Bye, Auth Gábor
Re: SSTableloader questions
Thanks Erick, I will go through the posts and get back if I have any questions. On Mon, Nov 9, 2020 at 1:58 PM Erick Ramirez wrote: > A few months ago, I was asked a similar question so I wrote instructions > for this. It depends on whether the clusters are identical or not. The > posts define what "identical" means. > > If the source and target cluster are identical in configuration, follow > the procedure here -- https://community.datastax.com/questions/4534/. > > If the source and target cluster have different configurations, follow the > procedure here -- https://community.datastax.com/questions/4477/. Cheers! >
Re: SSTableloader questions
A few months ago, I was asked a similar question so I wrote instructions for this. It depends on whether the clusters are identical or not. The posts define what "identical" means. If the source and target cluster are identical in configuration, follow the procedure here -- https://community.datastax.com/questions/4534/. If the source and target cluster have different configurations, follow the procedure here -- https://community.datastax.com/questions/4477/. Cheers!
SSTableloader questions
Hello, I have few questions regarding restoring the data from snapshots using sstableloader. If i have a 6 node cassandra cluster with VNODEs(256) and I have taken snapshot of all 6 nodes and if I have to restore to another cluster 1. Does the target cluster have to be of the same size? 2. If 1 is true, does SSTableloader have to use each snapshot from the source cluster and map to the target nodes? source1 -> target1 source2 -> target2 source3 -> target3 source4 -> target4 source5 -> target5 source6 -> target6 3. if 1 is false, do I need to run sstableloader for all the 6 snapshots from source in 3 nodes in target? 4. Can I have a different schema(only keyspace name) between source and target clusters? eg: keyspace1 in source cluster but keyspace2 in target Thanks in advance.
Re: Anti Compactions while running repair
Thanks Alex On Mon, Nov 9, 2020 at 12:36 PM Alexander DEJANOVSKI wrote: > Only sstables at unrepaired state go through anticompaction. > > Le lun. 9 nov. 2020 à 07:01, manish khandelwal < > manishkhandelwa...@gmail.com> a écrit : > >> Thanks Alex. >> >> One more query, all are sstables (repaired + unrepaired ) part of >> anti-compaction? We are using full repair with -pr option. >> >> Regards >> Manish >> >> On Mon, Nov 9, 2020 at 11:17 AM Alexander DEJANOVSKI < >> adejanov...@gmail.com> wrote: >> >>> Hi Manish, >>> >>> Anticompaction is the same whether you run full or incremental repair. >>> >>> >>> Le ven. 6 nov. 2020 à 04:37, manish khandelwal < >>> manishkhandelwa...@gmail.com> a écrit : >>> In documentation it is given that while running incremental repairs, anti compaction is done which results in repaired and unrepaired sstables. Since anti compaction also runs with full repair and primary range repairs, I have the following question: Is anti compaction different in case of full repairs and incremental repairs? Regards Manish >>>
Re: Issue with anti-compaction while running full repair with -pr option
Pushpendra, Probably you can read all the data using spark with Consistency level ALL for repairing the data. Regards Manish On Mon, Nov 9, 2020 at 11:31 AM Alexander DEJANOVSKI wrote: > Hi, > > You have two options to disable anticompaction when running full repair: > > - add the list of DCs using the --dc flag (even if there's just a single > DC in your cluster) > - Use subrange repair, which is done by tools such as Reaper (it can be > challenging to do it yourself on a vnode cluster). > > You'll have to mark the sstables which are marked as repaired back to > unrepaired state. This operation requires to stop one node at a time, using > the sstablerepairedset tool (check the official Cassandra docs for more > info). > > FTR, Cassandra 4.0 will not perform anticompaction anymore on full repairs. > > Cheers, > > Alex > > Le lun. 9 nov. 2020 à 05:57, Pushpendra Rajpoot < > pushpendra.nh.rajp...@gmail.com> a écrit : > >> Hi Team, >> >> In Cassandra 3.x, Anti-compaction is performed after repair (incremental >> or full). Repair does not have any way to bypass anti-compaction (if not >> running sub range repair with -st & -et). Here is a jira ticket. >> >> https://issues.apache.org/jira/browse/CASSANDRA-11511 >> >> I am facing 100% disk utilization when running repair -pr after upgrading >> Cassandra from 2.1.16 to 3.11.2. I have a 2TB disk & 1.35TB is used. >> >> There are multiple keyspaces and each keyspace is having multiple tables. >> One of the sstable has huge data. Here is the details of it : Keyspace, >> tabel & SStable have 1.3TB, 730GB, 270 GB of data. >> >> I have following questions : >> >>1. Is there any way to disable anti-compaction after repair is >>completed ? >>2. After what stage, anti-compaction is performed after repair ? >>3. Any other suggestions? >> >> Regards, >> Pushpendra >> >
