hi @Erick,
Actually this timestamp *1614575293790 *is equivalent to
*GMT: Monday, 1 March 2021 05:08:13.790*
that stands for
*GMT+1: Monday, 1 March 2021 06:08:13.790* (my local
timezone).
This is consistent with the other logs time in the cluster.
Thank yo
or if that's not possible, wait for at least 30 seconds between two schema
> changes and make sure you aren't restarting any node at the same time.
>
> On 01/03/2021 14:04, Marco Gasparini wrote:
>
> actually I found a lot of .db files in the following directory:
>
>
t; Since you don't yet have a full backup, I strongly recommend you to make a
> backup, and ideally test restoring it to a different cluster, before
> attempting to do this.
>
>
> On 01/03/2021 11:48, Marco Gasparini wrote:
>
> here the previous error:
>
> 2021-02-28
") to describe the process of removing snapshots. May I ask how did
> you delete the snapshots? Was it "nodetool clearsnapshot ...", "rm -rf ..."
> or something else?
>
>
> On 01/03/2021 11:27, Marco Gasparini wrote:
>
> thanks Bowen for answering
>
>
I'd check is the server log. The log may contain vital
> information about the cause of it, and that there may be different ways to
> recover from it depending on the cause.
>
> Also, please allow me to ask a seemingly obvious question, do you have a
> backup?
>
>
> On 0
hello everybody,
This morning, Monday!!!, I was checking on Cassandra cluster and I noticed
that all data was missing. I noticed the following error on each node (9
nodes in the cluster):
*2021-03-01 09:05:52,984 WARN [MessagingService-Incoming-/x.x.x.x]
IncomingTcpConnection.java:103 r
asons, is
> definitely not part of 'best practices' around Cassandra imho.
>
> C*heers,
> ---
> Alain Rodriguez - al...@thelastpickle.com
> France / Spain
>
> The Last Pickle - Apache Cassandra Consulting
> http://www.thelastpickle.com
>
> Le mer. 16 oct. 2019 à
hi all,
I was wondering if it is recommended to perform a rolling restart of the
cluster once in a while.
Is it a good practice or necessary? how often?
Thanks
Marco
imited (Australia)
> and Instaclustr Inc (USA).
>
> This email and any attachments may contain confidential and legally
> privileged information. If you are not the intended recipient, do not copy
> or disclose its content, but please reply to this email immediately an
, do not copy
> or disclose its content, but please reply to this email immediately and
> highlight the error to the sender and then immediately delete the message.
>
>
> On Mon, 29 Apr 2019 at 17:57, Marco Gasparini <
> marco.gaspar...@competitoor.com> wrote:
>
>> Hi
Hi all,
I'm using Cassandra 3.11.3.5.
I have just noticed that when I perform a query I get 0 result but if I
launch that same query after few seconds I get the right result.
I have traced the query:
cqlsh> select event_datetime, id_url, uuid, num_pages from
mkp_history.mkp_lookup where id_url=
around the cluster (each at the
> requested consistency level!)
> - pull it all back together and send it out
>
> In extreme cases, this can flood internode messaging and make things
> look slow even when the system is near idle.
>
> On Fri, Mar 8, 2019 at 9:27 PM Marco Gaspar
Hi all,
I cannot understand why I get the following logs, they appear every day at
not fixed period of time. I saw them every 2 minutes or every 10 seconds, I
cannot find any pattern.
I took this very example here during an heavy workload of writes and reads
but I get them also during a very littl
hi everyone,
I have activated DEBUG mode via nodetool setlogginglevel, now system.log
shows me slow queries (slower than 500ms) but the log is showing me the
wrong query. My query is composed like this:
SELECT pkey, f1, f2, f3 FROM mykeyspace.mytable WHERE pkey='xxx' LIMIT 3000;
but MonitoringTa
t 32 GB RAM as a minimum on the hosts.
>
>
>
> Spinning disks are a problem, too. Can you tell if the IO is getting
> overwhelmed? SSDs are much preferred.
>
>
>
> Read before write is usually an anti-pattern for Cassandra. From your
> queries, it seems you have a partitio
Hello everyone,
I need some advise in order to solve my use case problem. I have already
tried some solutions but it didn't work out.
Can you help me with the following configuration please? any help is very
appreciate
I'm using:
- Cassandra 3.11.3
- java version "1.8.0_191"
My use case is compo
ing too many
> tombstones. I try to design my data partitions so that deletes are for a
> full partition. Then I won’t be reading through 1000s (or more) tombstones
> trying to find the live data.
>
>
>
>
>
> Sean Durity
>
>
>
> *From:* Marco Gasparini
> *Sen
to write it to Cassandra
again. This way I can store almost all my data, but when the problem is the
read I don't apply any Retry policy (but this is my problem)
Thanks
Marco
Il giorno ven 21 dic 2018 alle ore 17:18 Durity, Sean R <
sean_r_dur...@homedepot.com> ha scritto:
&
hello all,
I have 1 DC of 3 nodes in which is running Cassandra 3.11.3 with
consistency level ONE and Java 1.8.0_191.
Every day, there are many nodejs programs that send data to the cassandra's
cluster via NodeJs cassandra-driver.
Every day I got like 600k requests. Each request makes the server
19 matches
Mail list logo
